[ChrisMarshallNY]

This is true.

But applications can be small and performant.

It takes skill, time, and work; a hard sell, these days.

Nowadays, we can throw together two or three massive dependencies, and get a really high-tone app.

That waddles like an overfed walrus.

[Karrot_Kream]

I think it's worth asking why, which I guess is less fun than complaining. Are the frameworks too fat? Do they encourage wasteful network requests? Are things not being compressed? Do developers not understand how to incrementally ask for data?

[josephg]

Part of it is the obsession with SPAs. If your site is an application, it makes sense to ship a javascript blob to the browser and have that render everything. But 90% of websites aren’t apps. They’re news sites. They’re blogs. They’re project pages on GitHub or npm.

I think the frameworks are mostly so obsessed with the problem of complex applications that they miss having good support for the simple case of server rendering with little-to-no javascript in the browser. If your website looks like a blog, it will work better if the server ships html to the browser. And maybe, only html. Web browsers handle html really well.

Because you can make content websites using hundreds of kilobytes of react, people do because that’s what they learned at their coding bootcamp. React lets you do server side rendering, but it’s seen as some advanced feature, not as the default for how we should be building the web. (In fairness, SSR is quite complex if you also want to re-hydrate in the browser).

Most websites should be using tools which do server rendering by default.

[hutzlibu]

"Most websites should be using tools which do server rendering by default. "

Meaning the server sends html, or the server sends an image?

edit: html, at least with react

[josephg]

Yes, HTML.

HTML is faster to load on all devices, usually smaller over the wire, trivially cacheable at every level. Its easier to debug, easier to archive or backup, and it plays nicely with screen readers, search engines and reader mode. The back button always works and does what the user expects. And it looks web-native everywhere.

I wrote a 9000 word blog post a couple years ago covered in diagrams. The page renders near-instantly on all browsers I've tried, and scrolling is buttery smooth. How did I do that? Its simple. When users open the webpage, I send them an HTML file.

[lmm]

Everything's downstream from the incentives. What kind of users do you attract by making your website faster/more efficient? People who can't afford a new phone, and whiny boomer nerds. Both of those demographics are more trouble than they're worth.

[ChrisMarshallNY]

Speaking as a "whiny boomer nerd," I can say that another demographic is people that need the types of services we provide, and can't afford squat, because they are destitute, physically or mentally challenged, rebuilding shattered lives, or dealing with serious IRL challenges.

That's the demographic that this "whiny boomer nerd" Serves, and they matter to me. I'm quite aware that many non-whiny-boomer-nerds feel as if these people should not exist, but they do exist, and mass murder is not an option, so some of us whiny boomer nerds actually care enough to try helping them.

Also, it's kinda fun, helping folks that can't make non-whiny-boomer-nerds rich, simply because it upsets non-whiny-boomer-nerds to see these “not worth the trouble” folks experiencing better Quality, Security, and performance, than the non-whiny-boomer-nerds do.

I know that it’s kind of immature, but I've always had a bit of a rebellious streak, and I’m easily amused.