I've asked someone who likes using tons of JavaScript before and the response I received was along the lines of "It saves developer time."
I don't get that one because in my experience, writing straight HTML is simpler than writing JavaScript. The real problem seems to be that many people today seem to have learned frontend web development through fancy JavaScript frameworks and don't know any other way. Since learning the simpler way to do it is more work, they don't bother. That's just my impression, however, and I don't have any hard data. Another possibility is that people want to learn the latest sexy technology and React/Angular/whatever people use these days is that.
We probably need good tutorials about how to create a nice looking HTML pages. Pure HTML, maybe with CSS. I'd prefer page to be self-contained - a document, not an app. This way some accessibility problems could be avoided too.
At least we may have static page generators which execute JS once on server side - for pages which don't really need interactivity (documents, not apps). There are a lot of them.
This goes into JavaScript later as well but it seems to be the way I'd consider proper: only using JavaScript for things that can only be done in JavaScript.
i don't know if i would have made the same choices they made, but I've been developing websites since 2000 (so before one relied on JS for anything but sugar) and I prefer to work with the component model of things like webcomponents, react, etc than I do with plain HTML.
So it's not just about "i don't know how". I just think it fits my mental model better.
Do you approach pages as applications or as marked up documents?
In those many cases when the page just carries information - it's not, for example, application-in-page, where you can change parameters and see the results - it's a document. A document is simpler than an app, doesn't need full power of Turing complete engine, and because of that, allows easier tools to manipulate - extract data, render differently (like for users with disabilities), modify (e.g., combine with another data set).
Sure, documents can be considered apps - a simple version of apps. There are also reasons to explicitly maintain strictly lower complexity for something which is not a proper app. For those, webcomponents could be overkill. Just imagine webcomponents with which you never use at least some of their capabilities?
I don't see much of a difference if you're doing SSR though. It'd just mean not delivering code that never gets used. If I'm just showing documents, then that's what it is. It needs nothing else.
I'd guess because if someone is building something in their free time they're likely to build it either using whatever technology is most fun for them, or using whichever framework they're most excited to learn.
For most frontend devs that's going to mean something a little bit more exciting than a static site.
Yes, I understand that if you're mostly doing (at work) these things this way, you may be inclined to do the same way your own project.
That doesn't mean you can't do better - and for some people "better" can be without JS, for many reasons, including convenience of end users. By now it's probably also an interesting challenge - create a good, but straightforward (i.e., "simple") no-JS page.
