I'm starting to wonder whether reactivity (not React specifically) was the originally sin that led to modern UI complexity. UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events) was supposed to make things easier. But in reality, it introduced state as something distinct from both the UI and the data source (usually an API or a local cache). That introduced state management. It was all downhill from there (starting with two way data binding, Flux architecture, Redux, state vs. props, sagas, prop drilling, hooks, context API, stateful components vs. stateless components, immutability, shallow copy vs. deep copy, so on and so forth).
Build steps are realistically speaking inevitable because of minification, tree-shaking, etc. which is not even a big deal these days with tools like esbuild. For a "true" DOM-first component reactive system just use Web Components and any Signals library out there and you're good.
I have been building with Next.js for years and still reach for it by default, but I genuinely appreciate the philosophy here. The no-build approach eliminates an entire class of problems -- stale caches, bundler config drift, slow CI pipelines -- that we have collectively normalized as "just how frontend works."
The SSR-first angle is especially interesting. Most frameworks bolt on SSR as an afterthought. Starting from HTML and progressively enhancing is how the web was designed to work, and it is telling that we keep circling back to it.
Rails does this perfectly with Turbo and Stimulus, Turbo does HTML-over-the-wire via SSR-first, server responds with small updates/appends of HTML as need etc, and then you lightly use stimulus JS controllers for the small stuff where HTML/forms don't make sense. https://hotwired.dev/
The fields/flags state model is a nice idea, having structured values separate from boolean state is something I haven't seen in other frameworks. How does this compare to Alpine.js or htmx in practice? They're in a similar space (no build, SSR-first) but I'm curious what made you go with a new framework rather than building on top of those?
Have tried multiple approaches. Sevelte. HTMX. Everything in between.
And came to conclusion that after certain complexity of UI - React kind of components are unavoidable if you want to be able to reason about your code.
Think of Shopify admin panel with product variations each variation having different pictures and what not.
Not saying not doable in plain JS.
But then Chrome can be written in NASM too, C++ is just...
I wonder how many users would prefer to have full page reloads (aka traditional server-side rendering) when navigating instead of all the insane http requests and ads we have today?
If the point it's to run propietary code, do yourselves a favor, ditch JS, and enable WASM for webapps and make most of the text web HTML5+CSS3 only. At least I won´t need to mangle User Agents to just read simple articles and images froma blog or a news site.
I went with SSR for a new project started 2025Q4. I'm not against React, but when I have to make an SPA (or very interactive component in an SSR app) I much rather use Elm.
In order to do the JS that I have to do with an SSR app I went with Alpine.js. It reduces the JS I have to write and that fits my SSR approach.
It feels a bit like a modern jQuery to be honest: you cannot build whole apps with it, but just to sprinkle on top of an SSR it does really well.
No-build, no-NPM, SSR-first JavaScript framework if you hate React, love HTML
(qitejs.qount25.dev)106 points by usrbinenv 19 March 2026 | 103 comments
Comments
Maybe focus on a use-case? Something like, "No-build, no-NPM, SSR-first JavaScript framework specializing in Time-to-interactive" - maybe?
Anyway, interesting approach for up to medium pages (not apps!). Totally not replacement for react.
The SSR-first angle is especially interesting. Most frameworks bolt on SSR as an afterthought. Starting from HTML and progressively enhancing is how the web was designed to work, and it is telling that we keep circling back to it.
And came to conclusion that after certain complexity of UI - React kind of components are unavoidable if you want to be able to reason about your code.
Think of Shopify admin panel with product variations each variation having different pictures and what not.
Not saying not doable in plain JS.
But then Chrome can be written in NASM too, C++ is just...
See also: HTMX and possibly even jQuery
It's not a great language for it.
In order to do the JS that I have to do with an SSR app I went with Alpine.js. It reduces the JS I have to write and that fits my SSR approach.
It feels a bit like a modern jQuery to be honest: you cannot build whole apps with it, but just to sprinkle on top of an SSR it does really well.
I'll just stick with a $5 vps with lamp and jjquery