Given most of the infinite scroll implementations - better use traditional pagination.

As lolptdr wrote - if infinite scroll implemented in a way that changes URL of the page with PushState and loads data correctly after refresh then it's just fine.

Nevertheless, any time I can I implement traditional pagination. It is easier to use and shows clearly where user is located, can allow user to jump straight to the last page.

Infinite scroll is usually terrible with browser navigation. If you can assume that the user stays within your page and doesn't need to navigate back and forth, it may be a reasonable option.

But for something like Tumblr or Pinterest, it's awful. When the user sees an interesting post, she clicks on it to open the page. Then she navigates back to the main page. But wait -- the infinite scroll's contents have been lost on reload. Now the page shows the top of the scroll, rather than the position where the user actually was when she clicked a link. It may be a long, long way to scroll back to where she was, with numerous loading progress indicators along the way...

Depends. If you intend to show results that could be referenced by a hard link that the user may share (such as search results or blog entries), then pagination is better. Transactions (like bank statements) or lists of lots of similar looking data are better suited for infinite scroll.

If you aiming for performance, it depends on how much data you need to request and if you can shunt or lazy load the data.

Recently implemented pagination for the skeleton of a large meteor/angular application that will target both mobile and web. I'll likely split it and have infinite scrolling on the mobile interface and keep the current pagination on the web version. Fortunately Meteor makes this rather easy.

TLDR it depends.

As someone who's often struggled to find a piece of content because the only link to it was about ten pages down a list that you can only add more items to via infinite scroll... I'd say pagination is usually the better options. At least with pagination, you can think 'okay, then it's page 10 that has the article I want'. You can then just click on page number 10.

If it's infinite scroll, you either have to manually mess around with the URL (best case scenario) or just scroll through everything again (common worst case scenario).

This is also while you should probably (at least in my opinion) have some form of page number, as well as a clear and somewhat quick to modify URL scheme (like page/10 instead of date=01/01/1990&before_date=01/02/1992&cat=test&session=123456789 etc).

Pagination on screen sucks, but is sometimes better than badly implemented scrolling. This being said, scrolling should be the default option, because it's much more natural and usable on screen. One should only fallback for pagination for very big content masses (long historical archive etc) and still keep the page size big enough (scrolling inside page is not bad thing).

Good scroll implementation uses lazy-loading content (if needed) and placeholder elements to keep page height always correct (assuming the height is reasonable), so that scrollbar works as intented as visual indicator about position. So called "infinite scrolling" where you have to first scroll to end, then wait for spinner for more content, is typically bad ux.

I've yet to see an infinite scroll implementation that doesn't slow my browser to a crawl after a while of scrolling.