I've done the same for years, and it feels a little bit like the IQ bell curve meme, where on the left and right it is like "vanilla HTML/CSS/JS are all you need."
I nowadays use flex, calc, clamp, min, max, scoped variables, and even display table sometimes these days and it just works so well. Eliminates almost all hacks.
This attitude is why we’re all still stuck writing C++ in 2026. Nobody wants to admit that they’re not hardcore enough to write in poorly designed languages so we never make the effort to improve the situation. We all seem to agree that Zig is an upgrade over C. There’s nothing inherently modern about Zig that we couldn’t have written back in 1995 - we just didn’t because nobody wanted to admit that C is frustrating and clunky, albeit fast.
I honestly didn't know people like this still existed, with such strong viewpoints on C.
Point out to these people that compilers rewrite your code quite significantly so the choice of language matters a lot less than the choice of debugger, profiler, etc.
GP asked about reactivity. And that still requires some frameworking, either prebuilt or a lightweight self-written one.
Whenever state is updated, the listeners are all called with the updated state and can update the UI and what not based on the new state.
I haven't profiled this and compared it to frameworks, but feels adequate for the relatively simple UIs I've done.
Most web apps and websites do not have that much state variables (even though it may be a lot of data). So while React may offer a small dev speed boost, it’s consumed by the need to build stuff and a whole deploy pipeline to nurse.
Libraries like HTMX and Alpine can take care of most the boilerplate for old style imperative patterns. And backend frameworks like Rails, Phoenix, Laravel donhave their own implementation for data updates.
What the frameworks do is take this concept one step further to create a SPA (single page application) but I honestly think they’re an antipattern that needs to die.
Anyone can write code that tweaks nodes or uses templating, but doing it in a consistent way on a project with hundreds of thousands linea of code is challenging, especially if you also need performance and everyone's least favourite child: accessibility.
Sure you don't get some of this with frameworks, but they help a lot.
"Reactivity" means "when those variables change, some generic code already exists to update the DOM instantly". As opposed to writing specific pieces of code to make those changes directly.
Unfortunately, with React, "updating the DOM automatically" generally means: you update the data; React recreates the entire DOM as a new copy in memory; React runs a diff checker to find out what changed from the real DOM; React makes each individual change in the real DOM. With React (or other virtual-DOM-centered alternatives) being used for the smallest of web projects, so many small sites do all that work when the procedure ought to be as simple as: you update the data; you update the DOM directly.
It comes down to inexperienced devs not being able to consider which tool is best for the job at hand, and just hammering nails into every web project in the same way.
Signals are basically as fast as writing event handlers yourself but way less fragile and verbose. React is just shaping everyone's impression of all JS frameworks because it's very popular and very slow.
Your javascript can target those 2 divs, ala doc.getElementById(counter).innerHtml and document.createElement.
Like that kind of works for simple stuff. But it gets more complicated fast. Reactivity is when your counter listens for change in the count and updates itself whenever that count changes.
Works well for a small bumber of things to update, quickly becomes unmanageable.
I consider it a huge advantage to have the code for both the counter and the banner in the same place. thisCounter++; thisBanner.className = "shown";
Well, that's simplifying the situation, but as those situations become more and more in ones site, at some point one might switch to a mediator pattern, which kind of is very close to signal emit and listening for signals.
But it has no utility
Compute is fine and nearly free
These are just art projects
Really knowing what you're doing is the implicit part of the right-hand side of the bell-curve meme :-)
Yes. We could do those before React and other crap too.
That's always the trotted-out response, most often recited by people who've read someone else saying it but not had the experience to form an opinion for themselves.
You absolutely don't end up recreating a massive, bloated, slow framework that tries to be as generic as possible to try to be everything to everyone. What you end up creating is a relatively tiny, fast, piece of code that is specific to that site's needs. The difference in size, speed and simplicity tends to be absolutely enormous.
Once you start adding dynamic forms for managing multiple items of different kinds, dashboards, error states, i18n, etc, you either end up with a homegrown framework, or with a lot of spaghetti.
Almost every web application being built today, framework or no framework, is a variation of a theme. We have no issue recreating those ad nauseum, but we draw the line at recreating a framework?
That is an odd caveat to throw on the end. Sure, to avoid frameworks you have to know what you are doing. Is that really such an outrageous expectation?
Not really. Frameworks are usually created to avoid boilerplate and provide some nice scaffolding to support you while you’re coding the business layer. And a lot of them do smooth over accidental complexity, even though the architecture is generic and may hinder you in the future.
But the learning curve still exist, as most of what you interact with is custome codes, modules and components.
No. Use a framework if you want those things. Everything around reactivity, state management, and components have been badly fumbled by the web platform and the various front-end frameworks are far more ergonomic.
(Full disclosure, I wrote a book on this, so I'm not exactly neutral: https://theosoti.com/you-dont-need-js/)
While a lot of devs love to use brand-new stuff that's only just been added to some browsers, some of us are not willing when we know it won't work for (almost) all users. The scroll() function is too new for use in production, IMO (but good to know it exists, to revisit after a while). If I have to code something else anyway, or copy-and-paste a polyfill, then why not just use a more robust option in the first place.
Smaller bundles, often easier to use, less bug potential. Code's a liability and being able to occasionally rip a bunch out as a feature becomes baseline is always a joy.
IMHO even HTML+CSS should be completely implemented outside the browser in the 'framework layer', but I guess that's not a very popular opinion among the more 'conservative' web devs ;)
Meanwhile, there's Typst bundles [1], still experimental, that implement the same idea backwards: convergint a Typst project into a set of output files (which can be HTML).
But there is probably a world where what you’re describing is possible with WASM and Canvas. Would need to solve for accessibility though.
dont need to import libraries anymore, can just build my own.
What exactly has gotten good?
CSS is the only area that is seeing improvement, and frameworks ... use the same CSS, so no idea what you're talking about.
Most everything outside of CSS has been and continues to be shit.
Edit: Moreover, literally all frameworks as one say: give us good browser APIs so that we don't have to do any of the things we do.
I find it is way too complicated with regards to flexbox, grid etc...
Just do a google search for flexible divs side by side. Start with two. Then switch to five. Tell me the solutions that work well.
I did like you asked. The first search result on google is a question on stack overflow. And the first comment provides an example that looks very much like flexible divs, side by side, between two and four based on the width of the container.
https://stackoverflow.com/questions/60615826/two-divs-side-b...
What didn't you like about the solution in that comment?
Y'all know React and Vue frameworks still use HTML, CSS, and JS, right? We're using the same thing, with a thin layer of helpers around mounting components and managing their lifetimes...
On the flip-side I always found javascript frameworks to have a purpose. Though to be fair I don't think I've worked with user facing javascript without a framework since jquery came about. I guess you could call that a library, but still.
Of course you can still write plain CSS.
But it is SO nice to not have any build step. All of my new projects start as a single babashka script now. You got html templating, throw in a stylesheet. Slap a datastar script tag in there for everything else. It’s just easy peasy.