Hacker News Reader

Comment by xorcist | Hacker News Reader

It also breaks the find button.

The item you wanted to search might get unloaded, or not loaded yet, in some bizarre attempt at optimization when the javascript library resposible is an order of magnitude larger than the actual content anyway.

My phone has gigabytes of memory. If you want to present five hundred items in a web shop, just list them and do not bother with any type of pagination, invisible or otherwise.

View on HN

It also breaks the “back” button.

If you click on an item after significant scrolling, view the item, then click back, where are you? almost never where you were. Usually just at the top of the list.

Jira goes one better. Issues in some lists are paginated into 50s. Change to "page 2", use the back button and you'll be back on the page you were on before looking at the list, because the URL hasn't changed. Go forward again and you're back at the first page. Argh!

Gah! Breaking basic navigation functionality, along with the clipboard, on page search functionality (i.e., basic application and OS level stuff), keyboard navigation, and common keyboard shortcuts and mouse/touch gestures, are amongst the absolute cardinal sins of web applications. These ought to be acceptance criteria for every single "story" implemented that impacts the client-side. Does anybody do it? Well, some, but very few.

yeah the nielsen article calls this 'pogo sticking'

The back button problem is fixable. Discourse (which you’ll see on discuss.python.org and users.rust-lang.org) uses the history API to keep track of your location. You can create a URL that points at any individual post, and the page will appear “pre-scrolled” to it, so you can not only use the back button to return to your location in the infinite scroll, you can even bookmark your location in the infinite scroll.

The scroll bar and find function can be mitigated, but not as elegantly.

The real problem is that, when you load a page in the middle, it’s easy to scroll down, but scrolling UP is glitchy. That one can’t be fixed. https://meta.discourse.org/t/scroll-jank-when-scrolling-up/1...

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.

That is not how browsers work. The browser will render the viewport immediately, long before the page has loaded. It will also load the visible thumbnails first, unless made impossible by complicated markup of course. Otherwise surfing the web on dialup in 1996 would have been intolerable.

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 because technology constraints necessitated it or that it was a good user experience.

Just have JS track where the user is?

Sooner or later you have to unload content or the browser crashes. There's an upper limit to how many DOM elements browsers can handle, even with modern optimizations.

Deferring rendering of the images seems like an easy enough thing to do if your alternative is infinite scrolling. Pre-load the text and layout but leave the images and video until they're close to the viewport.

the lack of not being able to find something not yet loaded or recently unloaded is infuriating to me. I file shitty pagination systems with no Show All in the same category.

The “find” thing is something I hadn’t considered. Yes it’s annoying when you cant search content “below the fold”

I do think it depends.

I love infinite scrolling for random content. There is no “position” so to speak. And there is no concept of “find” since you don’t know what you’re looking for. “Back” continues to work as long as your browser cached the previous page state.

Sometimes you really do want to simulate an infinite list of 4,000,000 entries!

An example: https://wikiscroll.blankenship.io

I find spotify is really bad with unloading ui, to the point where you have to stop and wait to see song titles if you are scrolling even moderately fast

In fairness, without unloading, it will be slow. Really slow. I never added unloading to a long list in my app, and for lists with thousands of items, Chrome will take seconds to paint on my MBP if you do any vigorous scrolling. It's not about memory use, it's about practical browser performance.

Idk if this would be better or worse, but there should be a "find on page" js API. Like how the history api is used for SPA's.

Reply on news.ycombinator.com