It also breaks the "virtual scrollbar". if you reload the page you have to start all over
Heck—maybe it’s not even browsers, but websites. I’m pretty sure a website could change the URL as you scroll, so if the page is reloaded (or bookmarked, etc) you’re brought back to where you left off. I usually dislike it when websites mess with URLs, but this seems like an excellent use case!
Reddit used to struggle with this back in the day. The way they did pagination was to say "show the next page after id postId=xyz123". Since the algorithm kept re-sorting the posts on the front page, the content moved around quite a lot and you'd see the same things re-appearing on page after page, and sometimes post xyz123 was deleted and then everything broke.
It’s one of the reasons that the “I can build XYZ app in a weekend” crowd sounds so silly. I bet Reddit spent dozens of not hundreds of man-months nailing their scrolling behavior. It probably took many iterations of UX, product and engineering to get it right. And even now I bet they have a pile of JIRA tickets buried in their backlog relating to the pagination system.
In my experience there is a non linear relation between the more seemless and “easy” something appears and the amount of work that went into it. Things seem “easy” because the developers poured a pile of fit & finish on the system.
Although Reddit's design decisions are almost certainly to accomodate their much larger scale.
Hacker News being designed to display trees sorted by karma also makes it difficult, you would have to re-sort the entire page to re-rank every new subtree within the current display.
Apparently, this also makes pagination difficult, since pagination is implicitly chronological - what people want from pagination is to easily find the latest items - which karma sort doesn't allow.
The latter point is relevant to a variety of UX decisions across many products and services. Making it easy, efficient, and pleasant for the user to do what the user wants may not be the overriding concern in the design.
Which is all fun and games until the “page” is actually a mutable and constantly changing list. With a mutable list there is no concept of “where you left off”.
More specifically it's caused by offset pagination. The kind of pagination where you track "user is 90 items deep into the list" or "user is 3 pages into list and each page is 30 items"
Alternatively, index based pagination works by going "the last item the user viewed was id=12345". With this model refreshing the view won't cause a change, but the downside is you lose an easy way to tell the user how many "pages" deep they are. Even though "pages" is a flawed metaphor in a dynamic stream of data, users still like to see "you're on page 3 of 1 million"
Also this is only considering "append-only" style lists. Like comments sorted by time, or a list of versions of software, etc. If your list is dynamic, like the pages of Hacker News, where isn't ordered consistently but is instead a dynamic order or has mutable items, pagination will still be inconsistent.
The web was designed from the ground up to display documents, so we would have to resort to URL hacks.
HTML can stick around indefinitely for legacy websites and truly static pages, but browsers should introduce a new standard DOCTYPE optimized for what we actually want the web to do.
There’s nothing magical about this that a “real app framework” gives you.
This user certainly does, and, unless there is strong evidence otherwise, I’d go out on a limb and assume that most users would dislike having to “re-scroll” to the point they were in the list.