Why have `<div data-part="form">` instead of using a `<form>` element?
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.
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...
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?
"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.
Hate and love, the borderline framework for borderliners. SCNR
Why use JS at all for SSR?
It's not a great language for it.
Philosophically Datastar is on the same page. Incredible performance and dramatic reduction in complexity.
I thought I hated React until I saw the samples on this page...
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?
I must have overlooked the site, but are there any working examples?
Yeah, no thanks..
I'll just stick with a $5 vps with lamp and jjquery
[dead]
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).