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.
Why is that a bad argument? The author strongly dislikes React and so wrote an alternative that is radically more simple, which sounds like a perfectly sane argument.
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?
Think Xstate[0] machines are a little more intuitive than the conditional value structuring displayed here in the example, but it is an interesting idea indeed.
Most of the time, it's enough to build in a simple, clean, and lightweight way.
Just like in the old days. Your server's resources will also thank you.
Furthermore, the simplicity of web pages is also rewarded by search engines.
If it were up to me, I'd build sites exclusively in .md format :)
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.
IMHO, you shouldn't make "hate" part of your tagline.
Maybe focus on a use-case? Something like, "No-build, no-NPM, SSR-first JavaScript framework specializing in Time-to-interactive" - maybe?
Why have `<div data-part="form">` instead of using a `<form>` element?
"If you hate react" feels like very bad argument in engineering.
Anyway, interesting approach for up to medium pages (not apps!). Totally not replacement for react.
Why is that a bad argument? The author strongly dislikes React and so wrote an alternative that is radically more simple, which sounds like a perfectly sane argument.
Does the author dislike react? How about preact? Or maybe simply jsx? Or nextjs?
There's nothing wrong with either of these if used correctly. Thus "hate" is a rather shallow argument.
Your argument that it’s a shallow argument is itself a shallow argument. ”I hate x” is not a technical argument anyway, it’s an emotional assessment.
Perhaps a bad argument, but for some people a very compelling one...
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?
Think Xstate[0] machines are a little more intuitive than the conditional value structuring displayed here in the example, but it is an interesting idea indeed.
[0]: https://github.com/statelyai/xstate?tab=readme-ov-file#super...
I agree, I hate unnecessary hypercomplexity.
Most of the time, it's enough to build in a simple, clean, and lightweight way. Just like in the old days. Your server's resources will also thank you. Furthermore, the simplicity of web pages is also rewarded by search engines.
If it were up to me, I'd build sites exclusively in .md format :)