Live data from Hacker News

Browsers are pretty good at loading pages

carter.sande.duodecima.technology

101–110 of 328 posts

Re: Browsers are pretty good at loading pages

#101

I don't get client side navigation. It's a worse experience in every way. It's slow, often doesn't support things like command-click, it usually breaks the back button, and even if it doesn't it breaks the restoration of the scroll position. The only thing worse is a custom scroll UI. Why do people try to reinvent the most basic features of a webbrowser? And if they do, why do they always only do a half-assed job at…

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the tag, update the URL wi…

> Because it's faster.

The whole point of the article is that it's not true. It's not the only article that disproves it, and honestly, it's not difficult to notice it. Just go to any blog running off a static site generator; loading times of pure HTML webpages on good connection are so fast they whole thing outruns client-side page switches even if the page is already in memory.

Re: Browsers are pretty good at loading pages

#102

Earlier quoted context omitted.

> 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 agai…

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.

Re: Browsers are pretty good at loading pages

#103
He lost me when he described Canada using a dictionary-like wording but also adding some pretty personal perspective. Describing an entire country as Socialist seems super opinionated to me.

Client-side navigation is quite tricky to get right - since there is no definition of right. Browser back buttons and scroll positions between back and fourth page loads are not standards-based things and the only way to study them is by just using the browser.

The only fashion that I have come to hate in client side navigation is endless scrolling on product pages. In my view it is completely pointless and hitting the back button NEVER returns you to the exact point you were. On product pages I think page-based pagination is the only way to go. Amazon does that. I think only feeds are a use-case where infinite scrolling makes sense.

P.S. I wonder if client-side ajax calls are GZIP compressed🧐

Re: Browsers are pretty good at loading pages

#104

Earlier quoted context omitted.

Because page reloads are jarring and discontinuous experiences. They run counter to a good user experience. That's not to say that every SPA is a good user experience, but just that a page reload is not part of the recipe for a good user experience.

HN uses the "old fashioned" approach of rendering everything server side and every link forces a page reload and I wouldn't describe the experience as "jarring and discontinuous". I'd rather have a fast full page reload than looking at a spinner while complex client side stuff does its stuff. [NB I really like React and when good SPAs are very very good - but a lot aren't].

On that note, it means HN supports for free one feature too-often forgotten about in single-page apps: middle-click, or, right-click-open-in-new-tab.

Re: Browsers are pretty good at loading pages

#105
post #57

Earlier quoted context omitted.

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the tag, update the URL wi…

Do you have an example of a site which does it well?

The blog of Svelte, the framework/compiler that was featured on HN some time ago works really well in my opinion: https://svelte.dev/blog

Re: Browsers are pretty good at loading pages

#106
post #92

Earlier quoted context omitted.

The idea exists but it's clearly not true, except perhaps in specific, niche uses like re-rendering a continuously refreshed graph. Even for your image gallery, it makes for confusion. Back button does what? Shift-refresh does what? Just let the browser do what it does. If you want the images to render fast, use HTML 2. Writing a web app with server side pages forces you to think about where the state lives. This is…

Google Maps would be the classic example of client-side refresh working so well that it's now the universal choice. At the time, it was a revelation, as the Mapquest-ish predecessors (if I recall) required a click and server-side refresh to scroll or zoom the map. Of course the revelation here was that tags weren't what we needed to move a map, but rather a click-and-drag plus scroll-wheel behavior to explore a huge…

I think this can be generalized as: if you need to break out of "click and wait a moment and see a changed screen" paradigm, for something like a continuously scrolling map or a smoothly flowing server load graph, then you can make good use of client-side loading.

If you are just trying to re-create it, don't.

Re: Browsers are pretty good at loading pages

#107
The current generation of less-experienced developers tends to default to building every project in React, even if there's no tangible benefit to accepting this complexity. It's unpopular to express, but the truth is that many junior devs don't know how to do it any other way. I don't blame them for this, because they literally haven't been doing it long enough to have mastered multiple techniques.

Managers go with it because it's still hip and easy to hire for. If things go wrong, well, it was good enough for Facebook.

Re: Browsers are pretty good at loading pages

#108
post #41

Earlier quoted context omitted.

AFAIK it works without js as well :-)

I occasionally suggest to people who complain on HN about the bad old days of table based layouts to do a "View Source" ;-)

The "bad old days of table based layouts" weren't really that bad, as evidenced by every generation of web developers reinventing tables in weird new ways. From "semantic" div soups through flexbox to CSS grid, it seems to me that most of layouting work is just building tables without using the tag ;).

Re: Browsers are pretty good at loading pages

#109

Earlier quoted context omitted.

Because it's faster. If you don't have to download all the content again, force the browser to re-render everything, then by design you just get the new content from the server faster, if you have to download anything at all. The idea exists since the introduction of AJAX. Furthermore, you don't lose state, which makes things much more simple. Imagine a simple image gallery. You just update the tag, update the URL wi…

> Because it's faster. The whole point of the article is that it's not true. It's not the only article that disproves it, and honestly, it's not difficult to notice it. Just go to any blog running off a static site generator; loading times of pure HTML webpages on good connection are so fast they whole thing outruns client-side page switches even if the page is already in memory.

Case in point, navigation on my site is pretty fast (to me, at least) and doesn't use much JS at all: https://www.stavros.io

(I promise I'll reply to your email soon)

Re: Browsers are pretty good at loading pages

#110

He lost me when he described Canada using a dictionary-like wording but also adding some pretty personal perspective. Describing an entire country as Socialist seems super opinionated to me. Client-side navigation is quite tricky to get right - since there is no definition of right. Browser back buttons and scroll positions between back and fourth page loads are not standards-based things and the only way to study th…

>Describing an entire country as Socialist seems super opinionated to me.

Not to mention the fact he's wrong; contrary to popular belief, "socialism" has been described as many things but the simple fact of offering healthcare, market regulations and some amount of free Internet access(?) - Socialism is a mode of production in which means of production are operated and managed (and some would say "owned") collectively by the workers, i.e. the majority of the adult population. This is also a form of society in which abstract labour is not valorized. A modern nation with money, capital, rent, predominant wage labour, and capital accumulation is in no way "socialist" - never mind by Marx's term with which he considered "socialism" and "communism" to be one and the same thing.

Post reply on HN