Browsers are pretty good at loading pages • Hacker News Board

Re: Browsers are pretty good at loading pages

#51

Post by moron4hire » Sun, Jul 21, 2019, 8:18 PM 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…

It's probably not the network round trip or the actionable content making reloading the site so slow. It's almost certainly tracking scripts, unoptimized database queries, and unoptimized assets.

Re: Browsers are pretty good at loading pages

#52

Post by kccqzy » Sun, Jul 21, 2019, 8:19 PM 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…

For a company I worked for, we tested client side navigation and non-client (traditional) navigation for the admin interface. And then we asked the admins who use the site in question: all of them loved the client side navigation.

So you see, I suspect most users are not like the HN crowd and don't really care about command-click or the back button.

Re: Browsers are pretty good at loading pages

#53

Post by hedora » Sun, Jul 21, 2019, 8:21 PM UTC

sword_smith wrote: post #36

The biggest advantage of using modern SPAs is that it forces the developer to build the backend as an API with which you can interact programmatically

The API between the SPA and the server is an internal implementation detail that doesn’t need to support interoperability or backwards compatibility.

I see no reason to believe interacting with it directly is easier than scraping an HTML page. (In fact, I’d expect it to actually be much harder and more fragile than scraping html in practice)

Re: Browsers are pretty good at loading pages

#54

Post by yazboo » Sun, Jul 21, 2019, 8:21 PM UTC

csande17 wrote: post #50

yazboo wrote: post #40

> A big one we’re seeing here is called progressive rendering: browsers download the top part of the page first, then show it on the screen while the rest of the page finishes downloading I question your reasoning here -- I don't think this is how progressive rendering works in browsers. The browser has to download the entire document to construct the DOM, and CSS in the head tag all has to be downloaded and parsed i…

> The browser has to download the entire document to construct the DOM Actually, the browser can construct the DOM for the first part of the page while it's waiting for the rest of it to download. Like, if the browser starts downloading a page and it sees this: My Cool Website Hello there ...it can add the element to the DOM, since no matter what comes after this in the HTML code, the will always be first on the page…

That's very cool, thanks for the info.

Re: Browsers are pretty good at loading pages

#55

Post by hombre_fatal » Sun, Jul 21, 2019, 8:25 PM 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…

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.

Re: Browsers are pretty good at loading pages

#56

Post by jimmaswell » Sun, Jul 21, 2019, 8:25 PM UTC

marcosdumay wrote: post #39

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…

> And if they do, why do they always only do a half-assed job at it? Oh, that's the easy one. It's half-assed because it's hard as hell to do a good job replacing the browser navigation. It shouldn't be surprising, since browsers are huge pieces of software made basically for displaying content and navigation, it's not reasonable to expect every web page to competently replace half of that job.

Just use the history state pushing API and it's not that hard. Put state information in the url and load the right content on refresh.

Re: Browsers are pretty good at loading pages

#57

Post by bloaf » Sun, Jul 21, 2019, 8:25 PM 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…

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

Re: Browsers are pretty good at loading pages

#58

Post by saagarjha » Sun, Jul 21, 2019, 8:26 PM UTC

kevingadd wrote: post #25

saagarjha wrote: post #23

Strongly agree with the premise, but > it just isn’t possible for a highly dynamic language like JavaScript to run as fast as the C++ code in browsers With modern tracing JITs, this isn’t always true ;)

As far as I know, no production browser uses tracing anymore. The only modern tracing implementation I'm aware of is LuaJIT.

Yes, most browsers have moved away from tracing JITs, but I think PyPy still uses it in addition to LuaJIT. The reason I brought it up was because tracing JITs, as far as I am aware, can give very good performance in the best case where your trace actually works (which is of course a bit of a dirty trick, but when you're up against C++ it's hard to play fair…)

Re: Browsers are pretty good at loading pages

#59

Post by petemill » Sun, Jul 21, 2019, 8:27 PM UTC

kccqzy wrote: post #52

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…

For a company I worked for, we tested client side navigation and non-client (traditional) navigation for the admin interface. And then we asked the admins who use the site in question: all of them loved the client side navigation. So you see, I suspect most users are not like the HN crowd and don't really care about command-click or the back button.

But you can support both with client side navigation

Re: Browsers are pretty good at loading pages

#60

Post by JulianMorrison » Sun, Jul 21, 2019, 8:28 PM 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…

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 a beneficial discipline.