It's not the trendiest programming technique around these days but it's a useful tool in the toolkit of a good developer.
This comes up occasionally on HN. I've never seen anyone say anything positive about it.
It seems like a software detail that's unnecessary exposed to users. It doesn't make the site better, it makes it worse.
The count is the number of stories to skip, the after is the id of the last story on the previous page.
If Reddit were to use offset + limit, one would frequently visit page 2 only to see the same articles they were reading on page 1 five minutes before. A good example of this issue with offset + limit based pagination is 4chan, which is basically impossible to read in a linear or sane manner.
Reddit somewhat alleviates the problem by ensuring that posts after the last one you read are displayed - you'll occasionally see some of the same posts you were reading on page one, and occasionally miss posts that "jump" to page one while you're reading it, but it'll at least be usable, unlike 4chan.
the answer to the why is news.arc (what this site runs) is the pet example of Arc, which is pg's lisp dialect focused on making lisp web apps with continuation passing style
as such, the technical purity to the idea is more important than UX, as otherwise it would mean admitting that trying to implement pretty simple web app that passes around continuations like this is a fool's errand
(actually, arc and the ideas work great for rapid prototyping but just do not work well once you reach more than all but the smallest of scales)
pg, please fix this. It drives me batty that after a page is open for a little while the "more" link breaks. That should never, ever, ever happen.
I like to open and read interesting links in new tabs, and invariably the continuations have expired when I return to HN after reading another tab. I see the expiry error many times everyday. It is a terrible user experience, even if it's a interesting technical 'solution' to paging.
It's frustrating.
b) Someone would argue that using closures to represent page links is clever and forward thinking, even if the current implementation is broken.
But, yes, it is annoying and wish it could be fixed.
Given that:
- the ranking of HN stories likely is in constant flux ...
- and that some users might want a consistent view of stories across multiple pages ...
- and that having .../page1-, .../page2-, .../page3-style URLs might result in some user seeing the same story presented twice in their browsing, once on page1 and then again on page2 as its rank changes ... or worse, missing a story that got promoted to page1 from page2 during a session
... do the continuations as implemented on HN present a static view of the ranked stories with a non-changing ordering (as long as links don't expire)? To do this with straight URL's one would need to present different URL links at different times to different users to get different page-2 contents reflecting what was on page2 at the time they started their HN visit. If so, that would be a feature.
I agree with other commenters that the current way feels very broken. I get to see the "expired page" dozens of times a day because I always leave my HN tab open and follow stories in a new tab.
The JS will just fetch the initial n pages and allow easy navigation using the more button. It will be visually very similar to what we have now. If the community cares it can become much more richer in functionality. If PG refuses, at least there r enough HN users who are annoyed by this bug that we can create a Chrome plugin for HN that fixes this. I can probably write something like this myself. But probably the community can first formulate excatly what the plugin should/should not do. Does such a plugin already exist? Is it a bad idea to solve it this way? Would the additional burden on the servers be too high to be worth it?