Hacker News Reader

Comment by hombre_fatal | Hacker News Reader

A media gallery website is a good example of a use-case for client-side routing.

I worked on a porn site that was basically an endless-scroll video gallery. Clicking a thumbnail opened the video in a modal overlay. All pages on the site were modal on top of the gallery in the background. You could deep link to a page and the gallery would load in behind it.

It worked really well and had great UX.

This generalizes to any website that has some sort of overall state between page transitions, like soundcloud.com playing a track as you click around.

View on HN

> I worked on a porn site that was basically an endless-scroll video gallery.

So, if you're a horny teenager, you scrool down for a huge amount of time to find "the video" that will get you off... and you hear your mom coming up the stairs, Control+w (close tab), and when she goes downstairs again, you press Control+shift+t (reopen last closed tab), you're back at the beginning, and have to search for that video again? That sucks.

Endless scrolling sucks. You go down and down and down, and something breaks (eg. bad wifi), and you lose your position, since refresh takes you back to top.

I hate infinite scroll with a passion. I've often been quite a way down someone's interesting Twitter feed and lost my place somehow, then just given up and gone somewhere else in frustration rather than trying to scroll down a few hundred tweets, waiting each however-many tweets for the next batch to load, just to get back to where I was.

Also the slowdown. Didn't matter whether I had 8, 12 or (currently) 32 GB of RAM; couple minutes scrolling down a Twitter or Facebook feed and the whole page slows down so noticeably that I simply give up.

Also: something breaks, you press F5, and now the feed is gone, or is in a completely different place than it was before refresh.

Infinite scroll should be labeled as dark pattern. Its only benefit is to the companies exploiting intermittent rewards; for users, it's just bad ergonomics and bad experience.

Funny. I agree with you that infinite scroll brings a bunch of UX issues.

But a dark pattern? Definitely not. I have had multiple projects this year where the feedback from UX workshops has overwhelmingly been to use infinite scroll. This is feedback from real users, customers, and clients.

We need to be careful to align the website UX to the correct target users. Are you building something for a very technical market or power users, such as software engineers? Sure, ensure you don't interfere with the experience.

However, if you're targetting business or social users, you need to base your decisions on their priorities. This means the optimal path for their primary use cases. This means optimizing for the 98% of the times the user just scrolls down the feed, not the 2% of the time they scroll a bit and refresh.

> you're back at the beginning, and have to search for that video again? That sucks.

and yet, that's the same behavior of the social media sites; you will spend more time (=more ads shown to you) there because you are searching for that damn video again

>you're back at the beginning, and have to search for that video again? That sucks.

1. browsers have some sort of cache[1] that allows them to restore closed/previously visited pages without doing a page reload. granted, it's not very reliable, but it'd probably work most of the time as long as you're not memory constrained or visiting too many pages in-between.

2. if the infinite load mechanism also updates the url (via the history api), then this wouldn't be an issue.

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...

Discourse has the only implementation of infinite scroll that I've ever seen consistently preserve state over a reload. Either everyone but them is incompetent, or it's much more difficult to do well than it seems.

(I still don't particularly like Discourse's implementation of infinite scroll because their custom scroll thing is awful to use.)

Media galleries (carousels) were client side things at least since the original xhr implementation in IE5. Maybe well before that if changing the src of a img let the browser load the new one from the server. I can't remember.

But sites were small and even loading all the page again was not that bad.

By the way, Rails Tutbolinks [1] are a way to get the same result with the server rendering only the html body and the js code in the browser swapping it with the current one.

[1] https://github.com/turbolinks/turbolinks

IIRC, Turbolinks work by loading pages in the background in response to a mouseover event - by the time a click has registered, the remote content has already been downloaded and just needs to be injected into the page. The speed-up comes from anticipating clicks, not from JavaScript tomfoolery.

I checked the README and it never mentions mouseover

> Turbolinks intercepts all clicks on <a href> links to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page using XMLHttpRequest, and then renders the HTML response.

I don't have a Turbolinks application to check but I found this https://github.com/turbolinks/turbolinks/issues/313

and this

https://www.mskog.com/posts/instant-page-loads-with-turbolin...

The behavior you describe is possible but it's not the default and requires adding other libraries.

I think you're thinking of https://instant.page/ , which is pretty much as simple as "when link is moused over, tell browser to load the page in the background".

What happened to http prefetch or server push? Does anyone use those things?

Reply on news.ycombinator.com