99% of the time those sites could be plain HTML and CSS, but apparently new generations don't even know how to do that, out of programming bootcamps.
That is because the latest framework always fixes everything that wasn't broken before.
React enjoyed its spot in the limelight. Then, unskilled people wrote bad React and the framework, not rank-and-file developers, took the credibility hit. It is more difficult, I suppose, to make a user-perceived slow webpage in jQuery.
I dispute this. I don't have any statistics either, but my subjective experience is that most websites are not like newspapers or blogs. Even shopping websites have pretty heavy interactivity these days.
Also, most boring pure-information-presentation problems are mostly solved by ancient technologies like wordpress. If you're working in web development in 2026, you probably aren't making static websites or blogs. You're doing something novel that probably has much higher interactivity demands.
HTML is abysmally lacking for any interactive (which is what this article is about).
Decades later, even something as common as a combobox is unsupported.
EDIT: Downvotes but no argument.
Documents vs Programs
The parent is rightfully pointing out that most websites are documents and have no need for client side rendering or interactivity. You are rightfully pointing out that VanillaJS is insufficient to build software in the browser.
Where I imagine you lose some people is that comboboxes can be done natively with the datalist attribute.
Where does that html come from, then? Do you honestly believe all pages could be static html+css served from some bucket? Or do they need to be rendered by a programm running on a server? Because once you start talking about servers generating pages then all this talk about JavaScript frameworks boils down to arguing where the complexity should be in place A or B.
But even given your position you see no difference between shipping the user a binary and shipping source code plus a compiler in terms of the user's experience? Surely the existence of server side react points to the server doing the initial lift being an improvement.
I don't think you understood my question. I stressed the fact that complaining about the complexity of a page implemented with a JavaScript framework is a red herring, because said complexity doesn't go away by moving it to a server.
And the old "dynamic HTML" approach is not easier to maintain and developm. By far.
In the meantime, what goes away is performance and perceived performance. Your dynamic HTML pages need to travel all around the world until clients see an update, and a page reload is far heavier and time consuming than doing a fetch to get data.
Try to ask yourself this simple question: why do software engineers bother with JavaScript frameworks? Do you think everyone has absolutely no idea about what they are doing?
> said complexity doesn't go away by moving it to a server.
> why do software engineers bother with JavaScript frameworks?
Some of that css and html doesn't run reliably and consistently on all browsers. A visit to sites such as canIuse helps build up an idea of the extent of the problem.
Also, you seem to ignore the fact that JavaScript frameworks use said html and CSS extensively, and provide the necessary abstractions to bridge the unreliability gap in addition to introducing features that html and css do not support.
What I really find funny about this issue is the fact that this type of claim implies that virtually all software engineers who for some reason aren't html+css purists are utterly incompetent and completely unable to assess any technical tradeoffs. Imagine yourself walking around with the belief that an entire field is manned by people who don't have a clue about what they are doing.