171–175 of 175 posts
Not when you have a footer that you want people to be able to click. Can't stand when infinite scrolls make footers impossible to interact with!
Earlier quoted context omitted.
In what contexts do you prefer it? As others have said it breaks findability, default browser nav (back then forward again you have to start over or watch it gracelessly attempt to autoscroll back down 600 posts and often fail), renders the scrollbar visually near-meaningless, detrimental to performance, and seems to largely be utilized just to maximize scroll time on visibility driven ad platforms, like all popular…
I would prefer my main feed on Twitter to be infinite scroll. Pagination can be "weaponized" too -- note the awful publishers such as WebMD who break articles up into a billion pages, to increase pageviews and hence ad impressions. Incidentally I prefer pagination for taxonomy pages and search-results pages, because it puts navigation more in my hands.
Good point, hadn't considered that.
Earlier quoted context omitted.
Gigabytes of memory yes but there is load time and render time too. And rendering a 120mb payload of items and their thumbnails before I can even view the top of the page seems… not the best user experience. I don’t think there is an easy answer here. All options have some trade offs.
Typically when I serialize data for #index endpoints I return much slimmer payloads than I do in #show endpoints. I recognize that 120mb was an extreme, but you should be able to serialize lists of 500+ items into well under 1mb, with enough data to render your list view thumbnails/links. I always thought the infinite scroll pattern was designed for analytics purposes. So that you can track user engagement. Not becau…