The friction occurs when people building a website for web documents think they should be building a web app, so you end up with a scaffolding that requires heavy JS just to serve what essentially is just text + maybe one or two images. The additional JS doesn't really save the user any time or pain, it just makes everything larger and harder to consume.
Honestly, you don't judge a back-end by how much code it's built with or what platform it's hosted on. I don't get the obsession people have with JavaScript used on websites. Websites with terrible UX often abuse JavaScript yes, but correlation != causation.
They can go in the inspector and see “oh wow so many MBs of JS”, but they can’t see the backend.
There is a good point to that: this data that is downloaded is an end user resource. Over a mobile network etc it’ll matter. But the days where it mattered at home/office are long, long gone, at least for the audience of the websites that adopt this strategy.
The obsession I believe is a remnant of these old days. There was a transitionary period still a decade ago (when hn was already not that young) where users would spend time loading a website, then complain about the amount of js on the page and how that is unnecessary. The connections got upgraded but nothing strikes down a habit…
I have no issues at all with this website. It's awesome. I mean it's a bit slow but that's probably because it's on the front page on HN right now - yet it still works pretty well. The design is delightful. Incredibly well done. One of the coolest websites I've seen. Who cares how much JS it takes, it's obviously worth it.
