> The irony is also that it would be way cheaper for people to develop websites as basic, old-school, reliable HTML pages with forms. Literal children were learning the "frontend" skills necessary to do that in the late 90s. HTML is designed to be easy to learn in a few minutes.
Cheaper to develop but who are you developing for? You won't have any customers. Customers demand JS-heavy sites by virtue of the features/interactions they ask for.
Devs don't care? No, users don't care and they will not reward you for making a HTML-only form website, no matter how they have complained about sluggish/bloated websites, they will continue to use them, even with alternatives available.
As an example, I recently had to pay for parking with a website because the card reader on the machine was busted. So I scanned the QR code and loaded up the site, had to fiddle to enable some of the scripts, and make my payment. After I was done, I saw it had used over 25 MB--4% of my data for the month--to collect roughly 30 bytes of information from me, assuming a naive encoding (16 digit CC, 3 digit CV2, 8 digit license plate #, 2 digit state). Maybe it also needed the billing address, so another 30 bytes or whatever. Point is the TLS handshake should've been 95% of the traffic.
If anything, I almost left to go look elsewhere because it was too much of a pain to get it to work on my phone and I didn't want to use up all of my data fiddling with it. No one is demanding a JS heavy site here. Customers are not demanding anything. It's a near certainty that no one has ever provided feedback to the parking lot owner about their payment form. I did actually leave digikey's store because I literally could not figure out how to get their payment form to work without blanket enabling all scripts (and they have a ton of third-party tracking scripts).
Sites that are for services that actually matter (e.g. banks, governments, utilities) also don't need to be flashy. You don't need to sell me on filing for my paternity leave or filing taxes or making a bank transfer or paying a bill. Just present the form. The absolute ideal website in such cases is a transcription of the paper form it replaces with a tiny bit of javascript to check constraints/field validation. The free tax filing website for the US is a decent inspiration for this: from a UX perspective it's just electronic versions of the paper forms with some ability to auto-calculate some fields.
Cheaper to develop but who are you developing for? You won't have any customers. Customers demand JS-heavy sites by virtue of the features/interactions they ask for.
Devs don't care? No, users don't care and they will not reward you for making a HTML-only form website, no matter how they have complained about sluggish/bloated websites, they will continue to use them, even with alternatives available.