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

61–70 of 328 posts

Re: Browsers are pretty good at loading pages

#61

Post by kccqzy »

petemill wrote: post #59
kccqzy wrote: post #52

Earlier quoted context omitted.

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

I certainly can. It was just not necessary because the people who are using the site didn't care.

Re: Browsers are pretty good at loading pages

#62

Post by efrafa »

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.

Its also really not that hard to make cmd click + back button to work properly with client side nav.

Re: Browsers are pretty good at loading pages

#63

Post by kevincox »

Ambroos wrote: post #44
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…

I think it's possible but it's hard to execute well. I tried 4.5 years ago with https://vivavlaanderen.radio2.be/ - disclaimer: the experience isn't great on mobile (design issue, not tech) and the JS/HTML is massive (it was my first JS project ever, so I messed a bit with Webpack etc). One of the tricks I used is partial rendering. If you click an artist page (the square/rectangular people photos with a name) and ha…

> with regular old elements that have those URLs as href.

This is the most common problem I have. I middle-click and nothing happens (or it loads in the same page)

That being said this is partially an API issue since the website needs to guess what a "regular click" is. It would be nice if there was an "onnavigate" event which would trigger for regular clicks (or other ways to follow a link in the same page) but not for things such as "open in new tap" shortcuts.

Re: Browsers are pretty good at loading pages

#64

Post by tiborsaas »

moron4hire wrote: post #51
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…

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 end result and blame the technologies, but this is superficial.

It's usually not the certain technology that's problematic (SPA, history api, react, angular, webassebmly...) but the use of them without understanding the problem first. That's why I find it funny when I constantly read general comments here like "SPA-s are the worst".

Re: Browsers are pretty good at loading pages

#65

Post by frereubu »

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…

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

Re: Browsers are pretty good at loading pages

#66

Post by zucker42 »

dustingetz wrote: post #7

He says the reason people code client-side navigations is to load pages more quickly. That's not the reason. Client-side navigation evolved from single page apps, where we use javascript to create dynamic content on the fly, for example a chat application. Now that you're a stateful single page app, we need to rebuild page navigation if our single-page-app has more than one "page". I understand that projects like Gat…

He claimed in the article that a MDN developer said that was the reason.

Re: Browsers are pretty good at loading pages

#67

Post by saagarjha »

efrafa wrote: post #62
kccqzy wrote: post #52

Earlier quoted context omitted.

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.

Its also really not that hard to make cmd click + back button to work properly with client side nav.

Can you support iOS's "peek" menu as well?

Re: Browsers are pretty good at loading pages

#68

Post by compumike »

(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], which is a free online electronics textbook that has interactive circuit simulations built in. Here's what I ended up with in the spirit of progressive enhancement:

1) Static site generated by Jekyll (with a few custom plugins) and hosted on S3+CloudFront with appropriate caching headers

2) No JS blocking initial page load

3) No custom CSS fonts to download

4) Prefetch and dns-prefetch headers

5) Tell browser to preload next page on link mouseover (instant.page)

6) Lazy-loading of schematic images (lozad / IntersectionObserver) when they're nearly within scroll range

7) Client-side instant search index (awesomplete + custom code)

8) Tooltips with section descriptions on internal navigation links (balloon.css)

There are heavier components to this too:

1) Equation rendering (MathJax) is heavy and slow but starts rendering the equations after initial page load, and prioritizes equations within the first few thousand vertical pixels first. (Sadly I need the full power of MathJax; the faster KaTeX engine can't handle all of my equations.)

2) The schematic editor / client-side circuit simulation engine is an entirely separate SPA. (But by modern standards it's probably a smaller payload than many sites today use for serving totally static content with a few forms.)

The result is a site that loads pretty darn fast -- maybe faster than a static page due to preloading and lazy-loading -- but packs in a lot of functionality appropriate to the problem. Any techniques I'm missing?

[1] https://ultimateelectronicsbook.com/

Re: Browsers are pretty good at loading pages

#69

Post by [deleted] »

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…

[deleted]

Re: Browsers are pretty good at loading pages

#70

Post by albedoa »

dustingetz wrote: post #7

He says the reason people code client-side navigations is to load pages more quickly. That's not the reason. Client-side navigation evolved from single page apps, where we use javascript to create dynamic content on the fly, for example a chat application. Now that you're a stateful single page app, we need to rebuild page navigation if our single-page-app has more than one "page". I understand that projects like Gat…

> He says the reason people code client-side navigations is to load pages more quickly. That's not the reason.

That was the reason given by MDN.

Post reply on HN