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

121–130 of 328 posts

Re: Browsers are pretty good at loading pages

#121

Post by regecks »

saagarjha wrote: post #67
efrafa wrote: post #62

Earlier quoted context omitted.

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?

Yes, I tried it just now on a random website I built in Vue. Any sane implementation of client-side navigation uses the History API[1]. It is indistinguishable from "real" navigation in the browser UI, apart from how fast it is.

If on the other hand, if you encounter code like the abomination below (which breaks cmd+click, peek and forward/back), you should not (imo) conflate it with actual client-side navigation. I suspect that's what some comments here are referring to.

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

Re: Browsers are pretty good at loading pages

#122

Post by dehrmann »

peteforde wrote: post #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 i…

Facebook loads pretty slowly for me.

Re: Browsers are pretty good at loading pages

#123

Post by alasdair_ »

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…

>Because it's faster

Did you read the article? The entire point was that “its faster” isn’t actually true.

Re: Browsers are pretty good at loading pages

#124

Post by amelius »

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…

Curious, how would you implement Facebook's infinite scroll with only static pages?

Re: Browsers are pretty good at loading pages

#125

Post by dehrmann »

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

This doesn't work as well as you think once you consider multiple endpoints and round trips. You're better off with something like GraphQL or server-side making the API ship views to clients.

Re: Browsers are pretty good at loading pages

#126

Post by quazar »

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.

If the links are not highlighted by default, then tab navigation is basically non-existent since I cannot see where I'd be redirected and I personally bother to write custom CSS only for the websites I visit very often.

Is there an actual reason to disable highlighting? It lowers usability and accessibility, but I'm not sure what do you get in return?

Re: Browsers are pretty good at loading pages

#127

Post by Waterluvian »

peteforde wrote: post #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 i…

There's nothing wrong with react here. You just have to also use a router.

Re: Browsers are pretty good at loading pages

#128

Post by basch »

drdaeman wrote: post #37
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 believe the only upside is that site framing (headers, navbars, side menus, etc etc) doesn't flicker or jump around reflowing as you navigate across pages. Which is I think why almost every "webapp" out there does this - to provide visually continuous experience, even if this client-side intra-screen navigation is slower. Surely, on a fast-enough connections this flicker is essentially invisible, but if your connec…

I much prefer getting normal pages to behave more like spa, than spa trying to recreate the web browser experience. Probably most importantly, automatically degrading back to normal web behavior, if the transitions arent supported or js doesnt load.

like https://github.com/turbolinks/turbolinks

Re: Browsers are pretty good at loading pages

#129

Post by bscphil »

everydaypanos wrote: post #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 th…

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

I think this was pretty clearly supposed to be a joke. Author is probably American - the joke is that healthcare and free (very slow) internet are considered socialist by Americans.

Re: Browsers are pretty good at loading pages

#130

Post by gruez »

testis321 wrote: post #74
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…

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

>you're back at the beginning, and have to search for that video again? That sucks.

1. browsers have some sort of cache[1] that allows them to restore closed/previously visited pages without doing a page reload. granted, it's not very reliable, but it'd probably work most of the time as long as you're not memory constrained or visiting too many pages in-between.

2. if the infinite load mechanism also updates the url (via the history api), then this wouldn't be an issue.

[1] https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...

Post reply on HN