Browsers are pretty good at loading pages • Hacker News Board

Re: Browsers are pretty good at loading pages

#41

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

SilasX wrote: post #38

arethuza wrote: post #33

Earlier quoted context omitted.

HN uses the "old fashioned" approach of rendering everything server side and every link forces a page reload and I wouldn't describe the experience as "jarring and discontinuous". I'd rather have a fast full page reload than looking at a spinner while complex client side stuff does its stuff. [NB I really like React and when good SPAs are very very good - but a lot aren't].

Well, the up/downvote transition is client side, but otherwise, yes.

AFAIK it works without js as well :-)

Re: Browsers are pretty good at loading pages

#42

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

eitland wrote: post #41

SilasX wrote: post #38

Earlier quoted context omitted.

Well, the up/downvote transition is client side, but otherwise, yes.

AFAIK it works without js as well :-)

I occasionally suggest to people who complain on HN about the bad old days of table based layouts to do a "View Source" ;-)

Re: Browsers are pretty good at loading pages

#43

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

arethuza wrote: post #33

RandomInteger4 wrote: post #31

Earlier quoted context omitted.

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.

HN uses the "old fashioned" approach of rendering everything server side and every link forces a page reload and I wouldn't describe the experience as "jarring and discontinuous". I'd rather have a fast full page reload than looking at a spinner while complex client side stuff does its stuff. [NB I really like React and when good SPAs are very very good - but a lot aren't].

There's definitely parts that are awkward though. I can't see the context of your comment in my reply as it's on a completely different page for example. HN has never really been a great UI though, it used to be a massive set of nested tables that didn't render properly on a mobile, it has some tiny fonts and hard to click buttons, and has unliked comments just less accessible by lowering contrast.

It's good enough to read the content and the content is the vital part, but I wouldn't point to HN for a good user experience (beyond the content and lack of dark patterns).

Re: Browsers are pretty good at loading pages

#44

Post by Ambroos » Sun, Jul 21, 2019, 8:12 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…

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 have JS enabled it'll first only render the header, then add a few body items, then the rest of the body items. Since we used a horribly inefficient handmade Markdown to JS thing with a renderer in old naive React it took way too long to render them all at the same time, it'd easily lock up the browser for two seconds on a large page.

Another ridiculous thing was to preload enough data to render the top part of every single artist page while you're on the homepage. A complete waste of data, but otherwise navigation would need a request before being able to render something useful and that defeated the point.

I did pay a lot of attention to making it feel like real navigation though. Almost any meaningful interaction modifies the URL, and the site is practically fully functional without JS. Navigation and Cmd-clicking should all work perfectly. Including scroll positions handling. SEO worked really well too.

So for a classic website format, to make client side rendering work, you need:

- a URL for every view change, with regular old elements that have those URLs as href.

- server rendering that actually handles all of those URLs

- something that restores scroll positions on navigation

- phased/batched rendering on click if your initial new view doesn't render in say 100ms (basically faking progressive rendering)

The development experience was a bit frustrating back in the day, and I don't think it paid off. Which is why for the next project (https://www.klara.be) we decided to go back to server rendering, but using React on the server. Some parts of the page (like the coloured box top right on desktop) are rendered as a skeleton on the server, and then React on the client reuses the same exact code to make these parts interactive again. Partial universal React basically, and it worked very well. I think klara.be feels like a nice and snappy site and it was way easier to develop for.

Re: Browsers are pretty good at loading pages

#45

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

I remember once I had to access the benefits page (Workday) at my employer but I was in a remote location (the middle of the Greenland ice sheet) with a slow/high-latency connection and the required page just would not load properly (presumably the client-side navigation wasn't robust to a slow connection...). I had to VNC (slowly) to a computer in the US in order to fill out some shitty HR form.

Re: Browsers are pretty good at loading pages

#46

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

Client-side rendering/navigation makes sense when you have high ratio of markup to content, or fixed content to changing content. In the olden days people used frames for such fixed navigation stuff etc, but I think we can agree that it was not all that great of a solution.

Re: Browsers are pretty good at loading pages

#47

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

For many sites transferring HTML works fine. I'm surpirsed that MDN would be implemented with client-side-rendering.

On the other hand I've had the pleasure of working with both Meteor and Elm thae last few years. It was the first time I had fun implementing client-side code. The resulting apps cannot be reproduced with HTML generated on the server. Often page switches in those apps don't take a round-trip to the server because the data is already loaded and can be rendered right away. Meteor also does incremental rendering by design. So the parts of the data you already have client-side are displayed right away while the rest is being loaded.

It is more work to get it right because you have to reproduce functionality the browser would do for you. But often you just don't want to do a full page load and then fetching and patching the right HTML snippets to update parts of the site gets messy real quick.

Re: Browsers are pretty good at loading pages

#48

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

HTML needs to be split into two: A spec focused on dynamic applications using JS and components, and a spec specifically focused on documents, CSS and hypertext.

The fact that in 2019, we still don't have standard browser features that let us create rich text documents in a WYSIWYG interface is ridiculous.

We've ended up with a dozen editors all producing slightly different markup, workarounds like Markdown and AMP, and browser engines that are so complicated even a massive company like Microsoft finally gave up creating its own.

This isn't about technology at this point, it's about standardization. We need to have a simple tag which marks the beginning and end of textual information, with massive restrictions on what tags are used and the JS and CSS in that section, so that a simple, standard and ubiquitous editor can both read and write hypertext 100% the same while still including all the basic functionality of a common word processor, like fonts, colors and sizing.

This isn't a technical challenge on the level of WebGL, web sockets, HTTP/2, media extensions, etc. It's just a matter of specifying a subset of functionality for a specific use-case, standardized for the sake of simplicity and interoperability.

Re: Browsers are pretty good at loading pages

#49

Post by tiborsaas » Sun, Jul 21, 2019, 8:14 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…

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 with the history API and everybody is happy. If you were to navigate via links, you get the same behavior.

Of course shitty implementations exists and you only notice the bad ones. If done right, you don't notice that it's happening at all.

Lastly but most importantly, context matters! It's not a silver bullet, but it can be really useful.

Re: Browsers are pretty good at loading pages

#50

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

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. (It might actually be able to add the

tag, too. I'm not 100% on the details.)

A cool demo of this is https://harmless.herokuapp.com/main , a JavaScript-less chat app that works by holding the connection open (essentially never "finishing the page load") and sending new chat messages as they arrive.

> CSS in the head tag all has to be downloaded and parsed into the CSSOM before the browser can make smart decisions about what to render.

That's true, but in this case, the CSS is already present in the browser cache, so it doesn't need to be re-downloaded.