Not necessarily. I seem to remember that HN used to be without pagination, all the comments were just listed on one page (without any JS to load more comments etc) but servers started to struggle when HN got more users which led to sometimes too many comments, so they added the pagination.
Somehow I associate this with the thread when Steve Jobs died, but not sure how accurate that is. My memory is kind of sucky.
What is endless about it? You’d assume there will be a finite amount of comments when you load the thread page, and the new implementation can just render that.
As with many things in "modern" web development, "endless-scroll" is not really endless (as nothing is endless). It's a technique similar to how Facebook, Twitter and others continue to automatically load content when you reach the bottom, giving the impression of "endless" content. Of course, even Facebook and Twitter would eventually run out of content to show, but somehow that pattern got the name "endless scroll".
See also: isomorphic, real-time, serverless and countless others examples of poorly named concepts in web development.
I know the feature they alluded to, thanks for the explanation. Comments on a thread are finite at any moment in time though, you wouldn't find "related content" as you were scrolling a specific thread page on HN. That was my point.
I was very surprised when I first found out FB would run out content. I had assumed that it would just go further back in time, even if the feed was not strictly chronological.
Oh I certainly didn't mean HN would do infinite scrolling. That'd be gross, too complicated, and would contradict the old-web style of the site. But if we can just generate entire pages quickly enough, I don't see why we wouldn't go back to doing that.
As a quick fix, can you add a hyperlink to the next pages at the top of the page [“Page 2”, “Page 3”], rather than just a single “More” hyperlink at the bottom of the page?
People frequently think that their comment has been deleted because it doesn't show up on the first page. We introduced it as a performance workaround, so if performance recovers, I'd rather stop. If rendering the whole page causes other trouble, we can reconsider the problem from scratch.
Why would pagination be a good idea? From my perspective, there's no downside (HN is exclusively text and fetching+rendering the entire first page of comments for this submission takes the same amount of time on my computer as rendering a no-comment submission) and several upsides (no need to open several tabs to see all comments, no need to make several more round trips and wait several more seconds per page of comments, no "attention cliff" where comments on the n+1th page are significantly less noticeable than those at the bottom of the nth page, allow pagination to be handled by user agent/browser instead of being enforced by server).
The downside is having to serve larger pages which consist primarily of content which will not be read. This site is running on some resource-limited hardware as I understand it, so limiting the maximum potential size of each page served means more pages can be served more quickly, especially if you just cache the first page of a thread (which is all most people will engage with) rather than the entire thread.
You're confusing cause and effect - most people only interact with the first page of comments because they're on the first page, and they don't want to click through. If you disable pagination, then suddenly far more people will read those comments that would be on the second page.
Additionally, request count matters more than data transferred. It's much easier to serve 1MB to each of 100 users than 1KB to each of 100K users. n people are already going to view the comment thread for a submission - a several-dozen-KB increase in the amount of data that you send each of them (assuming you're serving them statically) results in anywhere from "little" to "imperceptibly" additional CPU load.
If you're worrying about infinite scrolling, don't; we'd never.