Yes!
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'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.