Complexities that the article doesn't mention: - Browser location: When you switch from basic pagination to infinite scroll, you either take full responsibilit

Complexities that the article doesn't mention: - Browser location: When you switch from basic pagination to infinite scroll, you either take full responsibility for the navigation controls that the browser would have handled, or you accept the loss of those features on behalf of your users. When the user scrolls, will you update a page parameter in the URL? Can a user share a link to a spot deep down the list with a friend? When someone follows that link, what happens if they scroll upward? What happens when they hit the home button? - Home button: Throw away everything and load the first page of the list. But don't forget to reuse those expensive elements. And even though you're no longer using the elements before the window position, you might as well keep them around if you expect the user to scroll downwards again. - Back button, after leaving the list: If a user follows a link from deep within the list, and then navigates back, where do you put their view in the list? If you ignore the problem, will some browsers try to scroll to the user's last scroll position at this URL (Firefox will, and it will get it wrong if you're removing elements as the user scrolls down). - Back button, within the list: Is this just going to scroll the user upwards a bunch of times, which is consistent with classic pagination, or will it take them to wherever they were before they entered the list, which makes sense when you consider the entire list of be a single "page"? - Ctrl-F to find: can we still do this? Are you going replace it with a search bar? Is there any text that is shown to users, but not indexed by your search implementation? Are you searching outwards from the current position, or from the top of the list? - Scroll bar: Are we just giving up on these, or can we agree that they are common in applications because they are actually valuable from a UX perspective? Should it accurately represent the position of the viewport in the whole list, which requires the application to know the length of the list and the size of each item, or are we going to settle for just showing the view's position within the current subset of the list, which is not nearly as useful? - What happens when the scrollbar jumps our from under the mouse on various platforms, as elements are recycled from one end of the list to the other? Do we need to prevent that from happening? - Should we preallocate a large number of elements with placeholder content, so that we can create DOM elements only once, if we do not have enough recyclables for the next page of content? - What is the optimal number of elements to keep around? What about on a mobile device or a crappy web-tv with 1GB ram? On a desktop with 16gb ram? Does it vary greatly depending on the DOM rendering engine? How does the latency / bandwidth ratio affect the optimal page size? - Do your users move around much, or do they normally only browse forward, slowly, and then leave? Are the rare users who do move around alot likely to be significantly more valuable to you than the simple users? - API request caching headers: if the user scrolls back, do they actually need to make another HTTP request for content that they just saw recently? If they do make that request, what happens when there is a new item to insert in the list? TL;DR Do not take it for granted that infinite scroll is even a good idea for your content. I've built a bunch of these over past decade, not just on web, and now I cringe a little when a client quips "oh, and let's make it infinite-scroll, not paginated, ok?"