Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Browsers are pretty good at loading pages

carter.sande.duodecima.technology

Post reply on HN
Print view View original

71–80 of 328 posts

Re: Browsers are pretty good at loading pages

#71

Post by zucker42 »

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.

Not every project is the same. I suspect there are many applications where an SPA is a much better experience than a traditional website. In my opinion, a documentation site is not one of them.

Re: Browsers are pretty good at loading pages

#72

Post by ryacko »

tiborsaas wrote: post #64
moron4hire wrote: post #51

Earlier quoted context omitted.

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.

Sure, web performance is an afterthought at many places and the more people work on a certain project the worse it gets because each team has its own motivation, but they all have the same target to shoot at. I think there's a connection between the organizational structure and the bad frontend experiences and this is almost always overlooked in these discussions. This is no surprise of course, we only see the crappy…

CSS doesn’t require javascript, and allows for nearly all the features of a SPA.

Re: Browsers are pretty good at loading pages

#73

Post by moron4hire »

tiborsaas wrote: post #64
moron4hire wrote: post #51

Earlier quoted context omitted.

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.

Sure, web performance is an afterthought at many places and the more people work on a certain project the worse it gets because each team has its own motivation, but they all have the same target to shoot at. I think there's a connection between the organizational structure and the bad frontend experiences and this is almost always overlooked in these discussions. This is no surprise of course, we only see the crappy…

Yes, but equally so, replying to this email comments with "but page loads are slow" is not helpful.

Re: Browsers are pretty good at loading pages

#74

Post by testis321 »

hombre_fatal wrote: post #55
tiborsaas wrote: post #49

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…

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…

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

Re: Browsers are pretty good at loading pages

#75

Post by daxterspeed »

frereubu wrote: post #65
tiborsaas wrote: post #49

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…

"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 completely re-rendering the page. These systems tend to rely on heuristics though, and I don't think there's any documentation for these, but even when these fail the browser tend to be more competent than even the best JavaScript solutions.

Re: Browsers are pretty good at loading pages

#76

Post by kowdermeister »

bloaf wrote: post #57
tiborsaas wrote: post #49

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?

There are many good ones, but after a quick bookmark search, this shop is done really well, imho: https://www.shopflamingo.com/

Re: Browsers are pretty good at loading pages

#77

Post by cousin_it »

compumike wrote: post #68

(Disclosure: I'm Carter's desk-neighbor at Triplebyte.) I think there's actually a middle ground where you can utilize some of the more modern techniques to actually do better than the pure static pages approach, while still using normal browser-based page navigation. As a personal challenge, I wanted to see what could be done about performance for a recently-launched side project: the Ultimate Electronics Book [1],…

Loads about as fast as I'd expect from a static site.

Hover is a bit messy. When I move my mouse down the table of contents, the tooltip obscures the next chapter title, and sometimes grabs the click as well.

Back button handling seems to be buggy. If I click from the table of contents to a chapter, then hit back, then click to another chapter, then hit back again and do that a few times, the history becomes filled with many instances of table of contents.

Also something weird happens when I click a chapter link. Like, the whole table of contents scrolls for an instant and then I see the chapter.

Edit: if I disable JS, all these problems go away and the site feels just as fast. So good job on that :-)

Re: Browsers are pretty good at loading pages

#78

Post by mintplant »

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…

All major browsers cache the relevant assets (images, CSS, JS) in-memory between navigations in the same frame/tab and origin (at least).

Re: Browsers are pretty good at loading pages

#79

Post by kowdermeister »

JulianMorrison wrote: post #60
tiborsaas wrote: post #49

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…

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…

The back button would do the same as it would do after you click a [next image] link :)

Not sure about your point, the history API improves UX if you do it right:

https://developer.mozilla.org/en-US/docs/Web/API/History_API

It does everything as hand written, pure HTML page would, just do it faster.

Re: Browsers are pretty good at loading pages

#80

Post by mintplant »

jimmaswell wrote: post #56
marcosdumay wrote: post #39

Earlier quoted context omitted.

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

Scroll restoration is very difficult to reproduce perfectly. Particularly when content changes between navigating from one page to another and then navigating back, or when the user closes and re-opens the tab/browser.
Post reply on HN