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).
I'd argue that it was all downhill after we moved away from using HTML as the state representation.
Moving state out of HTML and into JS means we now have to walk this ridiculous tightrope walk trying to force state changes back into the DOM and our styles to keep everything in sync.
Given that problem, reactivity isn't the worst solution in my opinion. It tries to automate that syncing problem with tooling and convention, usually declaratively.
If I had to do it all again though, DOM would still be the source of truth and any custom components in JS would always be working with DOM directly. Custom elements are a great fit for that approach if you stick to using them for basic lifecycle hooks, events, and attribute getters/setters.
I use Preact without reactivity. That way we can have familiar components that look like React (including strong typing, Typescript / TSX), server-side rendering and still have explicit render calls using an MVC pattern.
From what I can tell, they just do full page reloads, and just use Preact for building UIs using components. Those components and pages then get rendered on the server as typical template engines.
I genuinely don't understand why this model is the norm. As a game developer working in my own engine, UI is unbelievably straight-forward: the game has state. The master Render() function draws all of the graphics according to the current state, called at framerate times per second. Nothing in Render() can change the state of the program. The program can be run headlessly with Render() pre-processed out completely. The mental model is so easy to work with. There is a sleep-management routine to save on CPU usage when idle, and dirty logic to avoid re-drawing static content constantly. I feel like the world would save 90% of its GUI development time if it didn't do whatever the fuck reactive UIs are doing.
> The master Render() function draws all of the graphics according to the current state
What you are describing is exactly what GP complained about: "state as something distinct from both the UI and the data source".
React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves.
This is why people came up with things like Flux/Redux/Reducers/Immutability, to handle this in a standardized way, but nothing is necessary.
This was the case back in the days of the Amiga and 68000 Macs. Rendering everything every frame was impossible, the only way to make it work at all was to draw only what was absolutely necessary to depict changes.
Then computers got faster, much much faster. It became possible to redraw the whole UI from state every frame without it being a significant cost.
At the same time retained user interfaces managed to become more and more costly to do just about anything. I don't think for any particular reason other than computers were fast and they didn't need to do much better.
I find it really odd that there are user interfaces that take longer to rearrange their items than it takes for the same CPU to RayTrace a scene covering the same amount of screen area.
Indeed, I genuinely do not. Rather than passive-aggressively insulting my intelligence, why not explain it for me? As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI, so it seems like web developers do in fact want to build immediate-mode UIs, and in fact are constantly complaining about the nightmarish complexity of the status quo.
[1] I loathe this term, by the way. It's one of those terms that, I think, belong to a discipline of developers who love to obfuscate everything, even simple concepts, with unnecessarily opaque terminology until nobody can understand what the hell anyone is talking about anymore.
>As I understand it, React was an attempt to shoehorn "immediate-mode UI"[1] on top of retained-mode UI
the problem is that the typical modern web page is considered as a combination of immediate-mode and retained-mode.
therefore, as it is wasteful to update all the page when only a few components on the page change, people want to only update parts of the page immediately when changes happen.
furthermore the typical modern web page only makes sense in the context of the modern web site, so some pages are almost everything on the page needs to update all the time, some pages are nothing here needs to update until the user does anything, some pages are nothing here needs to update at all, and other pages are just a couple components need to update all the time based on various things.
This context of what a web site is like is very much determined by the type of the site, where many e-commerce sites are affected by all sorts of data that occur outside of whatever page the user is on and need to update all sorts of different components on a page, many governmental sites are almost just static, with all sorts of variations in between.
> Rather than passive-aggressively insulting my intelligence
I did no such thing. In fact I expressed my understanding of why you prefer your methods. I was hoping you would be willing to consider why declarative, composable UI patterns are worthwhile. Instead you substitute a deep topic for "React".
Have a good one, I have no intention of getting into a technical discussion with someone whose first reaction is to jump down people's throats.
I guess I misinterpreted your comment? I do apologise if that's the case. I certainly didn't intend to "jump down your throat", I was asking you to explain your comment further because I don't understand what you're getting at.
I still believe immediate rendering is the only way for easy-to-reason-about UI building. And I believe this is why early React took off - a set of simple functions that take state and output page layout. Too bad DOM architecture is not compatible with direct immediate rendering. Shadow DOM or tree diffing shenanigans under the hood are needed.
Why do you list all of these design patterns as though you have to hold them all in your head at the same time? As though each one made the ecosystem successively worse?
UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events)
That's not so much a lack of statefulness as it is making zero effort to lift your application's data model out of platform-specific UI concerns.
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 :)
Moving state out of HTML and into JS means we now have to walk this ridiculous tightrope walk trying to force state changes back into the DOM and our styles to keep everything in sync.
Given that problem, reactivity isn't the worst solution in my opinion. It tries to automate that syncing problem with tooling and convention, usually declaratively.
If I had to do it all again though, DOM would still be the source of truth and any custom components in JS would always be working with DOM directly. Custom elements are a great fit for that approach if you stick to using them for basic lifecycle hooks, events, and attribute getters/setters.
What you are describing is exactly what GP complained about: "state as something distinct from both the UI and the data source".
React can be 100% stateless, functional, and have the state live somewhere else. You just need to apply the same limitations as your model: components should be simple and not store data in themselves.
This is why people came up with things like Flux/Redux/Reducers/Immutability, to handle this in a standardized way, but nothing is necessary.
Then computers got faster, much much faster. It became possible to redraw the whole UI from state every frame without it being a significant cost.
At the same time retained user interfaces managed to become more and more costly to do just about anything. I don't think for any particular reason other than computers were fast and they didn't need to do much better.
I find it really odd that there are user interfaces that take longer to rearrange their items than it takes for the same CPU to RayTrace a scene covering the same amount of screen area.
At the very least, I understand why your techniques help you...
[1] I loathe this term, by the way. It's one of those terms that, I think, belong to a discipline of developers who love to obfuscate everything, even simple concepts, with unnecessarily opaque terminology until nobody can understand what the hell anyone is talking about anymore.
the problem is that the typical modern web page is considered as a combination of immediate-mode and retained-mode.
therefore, as it is wasteful to update all the page when only a few components on the page change, people want to only update parts of the page immediately when changes happen.
furthermore the typical modern web page only makes sense in the context of the modern web site, so some pages are almost everything on the page needs to update all the time, some pages are nothing here needs to update until the user does anything, some pages are nothing here needs to update at all, and other pages are just a couple components need to update all the time based on various things.
This context of what a web site is like is very much determined by the type of the site, where many e-commerce sites are affected by all sorts of data that occur outside of whatever page the user is on and need to update all sorts of different components on a page, many governmental sites are almost just static, with all sorts of variations in between.
I did no such thing. In fact I expressed my understanding of why you prefer your methods. I was hoping you would be willing to consider why declarative, composable UI patterns are worthwhile. Instead you substitute a deep topic for "React".
Have a good one, I have no intention of getting into a technical discussion with someone whose first reaction is to jump down people's throats.
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.
There's nothing wrong with either of these if used correctly. Thus "hate" is a rather shallow argument.
I'll just stick with a $5 vps with lamp and jjquery
[0]: https://github.com/statelyai/xstate?tab=readme-ov-file#super...
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 :)