[lmm]

I still render Markdown on the client. My blog is probably "slow" by 2000s standards, but it's far faster and more lightweight than a typical news website in 2020.

Every page involves the browser doing rendering work. HTML is neither fish nor fowl; it's not particularly easy to write by hand, but it's not particularly easy for the browser to parse either. I'm not convinced there are any good use cases for it, and certainly not for CSS.

If partial prerendering on the server-side meaningfully speeds up your site for end users then by all means do it. But I would follow "make it work, then make it work right, then make it work fast". Dropping in a single tag to do client-side rendering is more than enough for the 90% case.

[chrismorgan]

Wow, your page goes through about five rendering forms on first load. First it appears in plain monospaced text, then it gets rendered to unstyled HTML, then one stylesheet loads that mostly just makes the text bigger (strapdown.min.css), and then another stylesheet loads that handles the rest of the layout and vanishes the header (readable.min.css), and then finally the header appears again as the Raleway font loads. That’s pretty major content- and layout-shifting, and not at all pleasant to behold. And all subsequent pages go through at least two forms (plain monospaced text, then fully rendered).

> Every page involves the browser doing rendering work.

Well yeah, but HTML, CSS and JavaScript are different beasts.

The browser can optimise HTML and CSS in various fascinating ways to provide a smooth experience and cope with loading problems in generally-useful ways; your site, if the JavaScript execution was effectively done in advance, would load faster, and skip at least the first three forms, going straight to fully-rendered-except-for-the-header or fully-rendered, depending on how quickly Raleway arrives. Subsequent page loads would go straight to the correct rendering.

JavaScript, on the other hand, is the most likely to not work, perhaps because it was disabled (including most spiders—client-side rendering is still decidedly bad for SEO, even if Google specifically has mitigated most of that for Google search inclusion), perhaps because it failed to load due to network conditions, perhaps because the browser is old or some such thing. Depending on JavaScript does make a site much less reliable. Sometimes that’s warranted, but I don’t think it is on regular content websites, ever.

By using JavaScript in the way you have done, you’ve guaranteed that it will render badly to begin with, that stylesheet loading will not be done smoothly, and that the site is less reliable and accessible. It’s… probably not a big deal, I begrudgingly acknowledge, but it does matter. It may still be faster than most news sites, but you hardly set a high bar there.

[lmm]

Heh, I used to use an explicit `display:hidden` to hide everything until it was actually rendered, but HN people complained about not being able to see anything with JavaScript turned off.

[chrismorgan]

Thank you for removing it—as a disable-JavaScript-by-default person, I do prefer to see it as plain text than to see nothing.

A better compromise here is to hide it by default only when JavaScript is present: e.g. add style="display:none" to the root element in an inline script before any external scripts, and then remove that when you’re done, or onerror, or after a few seconds have elapsed. You’ll still run into the stylesheet loading issues, though—if you want to make it work as smoothly as the browser, you’ll need various onload/onerror handlers on <link> elements and the likes. Browsers do a lot of heavy lifting like this that is impossible, hard or fiddly to implement in JavaScript.

Another compromise that some have used is a timed animation so that if the code hasn’t finished loading and executing within a certain time frame, what’s visible is rendered anyway. Google’s AMP used this approach, and made a serious mess of it in its first release, hiding stuff for up to 8 seconds. This approach is fairly uniformly inferior to the previous paragraph’s approach.