Edit: by the replies what I understood is that people that dislike JS think the web is a medium exclusively to read? Apps should be desktop executables. Fair enough. It's a good thing this is a negligible % of internet users.
Edit: by the replies what I understood is that people that dislike JS think the web is a medium exclusively to read? Apps should be desktop executables. Fair enough. It's a good thing this is a negligible % of internet users.
The web is a document-centric medium. I load a URL, I want to look at the document presented at that page.
Things I likely don't want to do is deal with banners, pop-overs or other code grabbing my attention (if you don't show me a cookie banner you've done the right thing: not use cookies that aren't strictly necessary, thanks!). I probably don't want infinite scroll, "funky" animations or other stuff that tries to break the document medium.
I think the only exception is if I'm looking at a document that wants to use an interactive chart, that's fine. Form validation might be helpful, but do you really need anything other than built-in HTML client-side validation?
JS code is usually run by people I don't necessarily trust, for interests other than my own.
What we need is a distinction of “low JS”, which is really what we had before we somehow grew an industry of JS framework mania. JS with fallbacks is a very useful and pleasant thing, JS powering the entire experience is - in most cases - not.
A consequence of Rice's Theorem is that there can never be a useful, enforced distinction between the garbagepile that we have right now and anything more than "no JS".
Before WHATWG hijacked the web we had apps on the internet -- Flash, Java applets, etc. They had slightly more friction than ordinary webpages, which forced publishers to think hard about hey do I really need an app or can I do this with static HTML? Now maybe Flash and Java-applets aren't the best platforms for web apps, but the apps need to be kept separate from the documents, and there needs to be some small frictional cost imposed on publishers who choose the app route -- because otherwise all of them will choose it out of laziness.
Automating writing HTML is also easy as you can just write to stdout directly, and if you are comfortable writing HTML by hand directly this is a simple uplift to automate things you did by hand.
This is why jQuery was so popular because you could just add it in to this vanilla HTML in a nice way. You didn't have to stand up some JS scaffolding and toolchain to get there. Even jQuery can get you to a situation away from WYSIWYG because you don't just need to render the DOM you now have to have a JS runtime evaluation. In some contexts you have something that can write a DOM from HTML but you have no JS, it was only when chromium embedding became popular and normalized you got both the HTML and the JS together, for a long time you only got the HTML.
Finally, direct HTML will work as-is forever but JavaScript is a moving target. Some terrible websites I wrote in raw HTML work today after 20 yrs (admittedly 1024x768 optimizations didn't age well) but many JS things I have written have not had that longevity or require standing up a long dead development framework to get going again.