Browsers are pretty good at loading pages • Hacker News Board

Re: Browsers are pretty good at loading pages

#201

Post by manigandham » Mon, Jul 22, 2019, 2:25 AM UTC

tiborsaas wrote: post #49

jakobegger wrote: post #3

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…

HN is very fast. Stackoverflow is very fast. Lots of other well engineered sites are very fast. As the article shows, browsers are well optimized and really don't download all the content again. In most cases it's just the HTML, which is streamed and rendered as it comes in. All the assets are cached, and scripts are even stored in compiled state to skip reparsing.

Some sites might be slow at generating that HTML but then they would be equally slow at generating whatever JSON/API responses used in a SPA, along with loading all the heavy JS in the first place to render it all.

Re: Browsers are pretty good at loading pages

#202

Post by nmjenkins » Mon, Jul 22, 2019, 2:27 AM UTC

delinka wrote: post #174

sangnoir wrote: post #161

Earlier quoted context omitted.

> The whole point of the article is that it's not true. Only for the narrow condition of loading a whole page. A lot of Web apps make async request much smaller than loading the whole page: imagine deleting one record in a list of 50 items; the async response could be the HTTP 200 header alone. I think it would be useful for developers to separate web applications from web sites and consciously make trade-offs (such…

Web apps making async requests should be making much smaller requests than loading the whole page - but they're not. They're loading a page and parsing out the "less than the page" bit to stick into the current page; or they're loading a JSON blob bigger than the current page to update the three visible elements on the page. Imagine Software Engineers that actually engineered solutions - the use of small async reques…

> the use of small async requests would be a boon to everyone! But no one's doing this.

Some of us are! RFC8620 is purpose-designed for building network efficient APIs: https://tools.ietf.org/html/rfc8620

Re: Browsers are pretty good at loading pages

#203

Post by [deleted] » Mon, Jul 22, 2019, 2:29 AM UTC

OkGoDoIt wrote: post #145

JulianMorrison wrote: post #106

Earlier quoted context omitted.

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.

Exactly. But why a blog platform or news site or other content-focused website would feel the need to do that is beyond me. Not everything on the internet needs to be an app.

[deleted]

Re: Browsers are pretty good at loading pages

#204

Post by cottsak » Mon, Jul 22, 2019, 2:31 AM UTC

jakobegger wrote: post #3

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…

Dude! #scrollhijacking is the worst!

Re: Browsers are pretty good at loading pages

#205

Post by delinka » Mon, Jul 22, 2019, 2:48 AM UTC

nmjenkins wrote: post #202

delinka wrote: post #174

Earlier quoted context omitted.

Web apps making async requests should be making much smaller requests than loading the whole page - but they're not. They're loading a page and parsing out the "less than the page" bit to stick into the current page; or they're loading a JSON blob bigger than the current page to update the three visible elements on the page. Imagine Software Engineers that actually engineered solutions - the use of small async reques…

> the use of small async requests would be a boon to everyone! But no one's doing this. Some of us are! RFC8620 is purpose-designed for building network efficient APIs: https://tools.ietf.org/html/rfc8620

I apologize for the hyperbolic “no one.” I was rushing...

Re: Browsers are pretty good at loading pages

#206

Post by manigandham » Mon, Jul 22, 2019, 3:08 AM UTC

daxterspeed wrote: post #75

frereubu wrote: post #65

Earlier quoted context omitted.

"You don't have to download all the content again" is also true if you version your assets and use a CDN with far-future expiry headers. If you need an HTTP connection to download a section of HTML for a new part of an SPA it won't be that much different from a full page of HTML, presuming you compress the transfer as you should. "Of course shitty implementations exist" is true of a non-SPA setup too.

While it's true that the browser won't have to download the content again, it will have to re-instantiate various resources (eg execute all JavaScript over again..., restart gifs). If implemented correctly, JavaScript navigation should seamlessly appear like normal navigation. Not supporting streamed requests is a serious drawback. Of course browsers have actually gotten pretty good at AJAX-like loading instead of co…

JS is cached in its compiled state in modern browsers. There is no download or parsing step for repeated loads.

Re: Browsers are pretty good at loading pages

#207

Post by manigandham » Mon, Jul 22, 2019, 3:11 AM UTC

RandomInteger4 wrote: post #31

hoorayimhelping wrote: post #28

Earlier quoted context omitted.

I have no idea. I do a lot of front end work in React, and the assumption that an SPA is a better experience for people because you don't have to do a page reload to see a new page is really baffling to me. It's widespread too - across industries and disciplines and age ranges, as if the people suggesting these things have never used SPAs.

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.

Page reloads are not jarring, they are expected, well understood, and often add that subtle hint that something has indeed changed. People want reliability and familiarity over speed, and speed from the lack of heavy JS and wonky click handling is a bonus.

Compare the site you're on right now (HN) to Reddit's new SPA frontend. Which one is faster to browse?

Re: Browsers are pretty good at loading pages

#208

Post by ComputerGuru » Mon, Jul 22, 2019, 3:19 AM UTC

StavrosK wrote: post #109

TeMPOraL wrote: post #101

Earlier quoted context omitted.

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

Yeah, but you force me to stare at blank spaces while your webfont downloads [0]. I guess I should be thankful you’re not using that font for the body text, too (most sites do!).

[0]: https://imgur.com/a/FAX6BDW

Re: Browsers are pretty good at loading pages

#209

Post by yc12340 » Mon, Jul 22, 2019, 3:20 AM UTC

TeMPOraL wrote: post #114

jspash wrote: post #111

Earlier quoted context omitted.

I'll admit it is pretty fast. Assuming you are using a mouse. But keyboard navigation is non-existent. So you have to ask yourself is it worth it to go against decades of effort put in to standard web navigation for what gain? Obviously only you can answer that for your blog. I'm not having a go. But I will give you credit for the fact that it does work with Lynx!

By "keyboard" I assume you mean TAB-key-based navigation (I don't know of any other included in the browsers)? If so, it looks to me that links are in fact TAB-stops, but they're not being highlighted. It's something that should be solvable with a CSS adjustment.

...also known as "directional navigation" — widely used by screen readers and browsers on Android TV or some Android Auto devices.

Re: Browsers are pretty good at loading pages

#210

Post by giaour » Mon, Jul 22, 2019, 3:24 AM UTC

pmontra wrote: post #97

hombre_fatal wrote: post #55

Earlier quoted context omitted.

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…

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…

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.