Hacker News Reader

Comment by dang | Hacker News Reader

If you want to reply about pagination, do so here.

If you're worrying about infinite scrolling, don't; we'd never.

Please don’t make it infinite scroll instead. Begging you. Please.

I believe the implementation is learning towards sticking all the comments on one page, but of course I'm not the one designing this ;)

I fully agree. Especially on a site that literally only has comments.

Never. Be at peace.

(We intend to get rid of pagination once the next implementation of Arc is ready.)

So you are adding endless-scroll? One of the Web UI things that the HN community regularly complain about on other sites?

Please make it optional. :)

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 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.

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.

AI will generate new comments as you scroll... :)

> So you are adding endless-scroll?

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.

Pardon me; nothing is further from my mind. See replies elsewhere in this subthread.

> We intend to get rid of pagination

Please don't. Or just make it optional. Infinite scrolling is evil.

Strong agree here. Infinite scrolling is painful. I would rather be given an ENTIRE page to scroll as I see fit.

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.

Why would it be infinite? Just load all the comments at once! Show me everything.

Modern caching strategies mean it wouldn't be any database load or concerning computational overhead? I'm no expert on HN-scale sites though.

Anyway, my 2 cents is I'd prefer everything loaded at once, no pagination, no infinite scroll.

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?

>We intend to get rid of pagination once the next implementation of Arc is ready.

Why? Pagination seems like a good idea for really long threads.

This was my first interpretation (and question), too

I'm assuming that what he means is that they'll replace the need to click on a link with the 'infinite scrolling' that you see on Fb, etc.

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.

Reply on news.ycombinator.com