At some point, someone is going to come out with a no-JS, no-NPM, no-SSR framework and we're just going to have invented HTML again
I'm starting to wonder whether <i>reactivity</i> (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).
Absolutely. Look at facebook today. Back in 2010, everything had just the right amount of interactivity. Because, separation of concerns existed at the language level - HTML for structure and CSS for presentation, JS for everything else.<p>Then some bunch of geniuses decided it would be awesome to put everything together in the name of components. Today, you open facebook, the creators of React - normal drop-down with just a list of barely 5-6 items is a fucking component that makes 10 different requests. I would even argue this unnecessary forced interactivity is what perhaps annoyed users the most as everything always has to "load" with a spinner to the point of the platform being unusable.<p>Same goes for instagram. It's not just that, React is a hot ball of mess. It's not opinionated, so anyone can use anything to do anything. This means if you work with multiple teams, each one uses their own code organisation, state management library and general coding paradigm. Eventually the engineers leave and the new guy decides to do things his own way. I've honestly never seen a company with a great product run over React. Everything always is being re-written, migrated every 3 weeks or straight up is buggy or doesn't work.<p>React is the worst thing to happen to the Javascript ecosystem. The idea is good, but the execution is just piss poor. I mean look at Vue and Svelte, they managed to do it right.
I'd argue that it was all downhill after we moved away from using HTML as the state representation.<p>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.<p>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.<p>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 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.
That is immediate-mode graphics. Fine when you are already power-budgeted for 60 frames each second. UIs typically use retained-mode graphics, with persisting regions.
This is basically "reactive UI" foundation. The complexities come from effects (now managed via hooks)
Isn't that what reactive ui trying to achieve? To only have a render function and have ui state sync according to the data?
That reminded me of another complexity: virtual DOM diff.
UI is mostly static.
Rendering everything at framerate per second is a huge waste of time and energy.
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.<p>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.<p>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.<p>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.
[flagged]
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.<p>[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<p>the problem is that the typical modern web page is considered as a combination of immediate-mode and retained-mode.<p>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.<p>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.<p>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 am no web developer but whenever I built the UIs, re-rendering a page by doing some big DOM change through JS as always led to stutter. So maybe its just inefficient and can't be optimised.
React is not immediate-mode in the traditional sense where everything is redrawn on every frame.
On the web you need accessibility and often also responsive layouts.<p>These are requirements the DOM / CSSOM addresses, you'd probably not have an easy time getting this right in a <canvas>.
> Rather than passive-aggressively insulting my intelligence<p>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".<p>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.
No horse in this race, but your phrasing seems a bit weird, honestly... If reduced, your comments read as:<p>"You don't know about X? Well, at least I know about X and Y..." Doesn't seemed like a good faith comment to me either?<p>And then you say "You misunderstood my intentions so I'm going to disengage". For what it's worth, I didn't interpret your argument as insulting someone, but also it wasn't a useful or productive comment either.<p>What did you hope to achieve with your comments? Was it simply to state how you know something the other person doesn't? What purpose do you think that serves here?
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.
To be perfectly fair, you accused me of insulting you and said you "loathe" a word which I thought was a fairly inert term of art. Would you believe I didn't actually notice that you wanted me to say more? :) More than happy to give the benefit of the doubt though, the shoe's been on the other foot for me more than once.<p>For my part, I also loathe the insensate writhing mass of frameworks, patterns and dependencies that is "modern" frontend development. Where you and I differ is I recognize a handful of extremely good ideas hidden in the morass. But I am perfectly happy dismissing the majority of it; if nothing else, you shouldn't come away thinking of me as a React fanboy.<p>Writing is a lossy medium for thought, and programming is no exception. I'd say at a minimum that you and I are on the side of programmers whose code is a medium for their <i>own</i> thought.<p>All of these choices really just comes down to cognitive bandwidth, context, domain, taste, any number of things, really. Which is what was behind my first (admittedly terse, slightly salty) comment.<p>What I condemn is someone who opts out of making choices for themselves in their software. Web dev just happens to have an unfortunately high concentration of this sort of thoughtlessness.
[dead]
<i>> The master Render() function draws all of the graphics according to the current state</i><p>What you are describing is exactly what GP complained about: "state as something distinct from both the UI and the data source".<p>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.<p>This is why people came up with things like Flux/Redux/Reducers/Immutability, to handle this in a standardized way, but nothing is necessary.
>components should be simple and not store data in themselves.<p>That is a ”controlled component” model which is bad for interactivity, especially text inputs.<p>If every keypress triggers a state change and rerender, the UI will be slow and things like focus management become complex issues.<p>Without a rerender, it must now use a reactive binding to update the field value.<p>If you don’t want to update state on every keypress, your component must be uncontrolled, store its state internally (in the DOM) and update it to a parent store e.g. when the user stops typing (debounced) or moves focus out of the field. These are not trivial things either, and as a result, components get more boilerplate to handle the UX complexity. And of course, there are now UX pitfalls.<p>Indeed, these are reasons why reactive patterns exist. Now, if they just managed to abstract away the tedium.
I don't know what people generally recommend now, but for a long time the best practices with organizing React components had them connected to the store midway down the tree or higher, which definitely would have contributed to the UI slowness since it would rerender everything below that on each update. Push the store access down as far into the leaves as possible and you won't get anything noticeable, even though it is still doing more work than just accessing the DOM state as needed.<p>Also, focus management isn't really a thing in React, the vdom diffing means DOM nodes are updated instead of replaced so focus isn't lost or changed unexpectedly. There used to be a demo on the React homepage showing this, since the idea was very new to most people at the time - everything popular before it was just rendering template fragments to replace nodes and did have this problem.
> 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.<p>"just" is doing a lot of heavy lifting here. Where do you store "pure" GUI state (button state, is expandable expanded, …)? Do you really want to setup Redux for this? (And no, the DOM is not an option in non-trivial cases.)
Might be naive, but this has always been a concern of the view-model for me. Every GUI change results in a VM change via event/command. The VM becomes gospel for UI state which means reducers are much simpler, and my actual model doesn't care if it is indeed a button, expando, radio button or whatever else.
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.
> UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events)<p>Is there really a difference? Angular uses RxJS in a pub-sub scheme. (At least it did when I last used it.)
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.
Give me state management vs. event bus management any day of the week. The former is fully testable and verifiable. You can even formally define your UI as a state machine. With events you are constantly chasing down race conditions and edge cases, and if your data lives seperately in components there is no clean way to share it horizontally.
In my view, the problem isn't specifically reactivity but the fact that reactivity isn't actually native of the UI toolkit.<p>Instead of HTML, think about GTK or Swing.<p>To add React-style "reactivity" to it, instead of just making a dialog to change the "title" of a document and committing the change when you press OK, you'd need a top-level "App" class that holds all the state, a class for state properties with IDs accessible at runtime which probably would be a variant (accepts any primitive type), a binding class to bind the toolkit's textbox to the App's state "title" property (because you'll probably want to bind a lot of textboxes, so it's easier to separate the code into classes), and then every time the user types something into the textbox, instead of using the toolkit's code that is already written for you which updates the textbox' state directly, you block the state change in an event handler, send the state change to the App class, let the App class figure out the differences between the current state and the new state, and then it calls some callback in the binding class that is responsible for actually changing the text in the textbox to reflect the new App state. You'll probably run into a ton of issues (selections resetting, assistive technologies bugging, etc.) that you'll have to deal with externally somehow. All just to make it do exactly the same thing it would have done anyway.<p>It's like you have a fully autonomous robot and you want to add marionette strings to make it move.
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?<p><pre><code> UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events)
</code></pre>
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.
Why have `<div data-part="form">` instead of using a `<form>` element?
IMHO, you shouldn't make "hate" part of your tagline.<p>Maybe focus on a use-case? Something like, "No-build, no-NPM, SSR-first JavaScript framework specializing in Time-to-interactive" - maybe?
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.
There are people who hate react?
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.<p>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.<p>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.
"If you hate react" feels like very bad argument in engineering.<p>Anyway, interesting approach for up to medium pages (not apps!). Totally not replacement for react.
Perhaps a bad argument, but for some people a very compelling one...
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.
Have tried multiple approaches. Sevelte. HTMX. Everything in between.<p>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.<p>Think of Shopify admin panel with product variations each variation having different pictures and what not.<p>Not saying not doable in plain JS.<p>But then Chrome can be written in NASM too, C++ is just...
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.<p>[0]: <a href="https://github.com/statelyai/xstate?tab=readme-ov-file#super-quick-start" rel="nofollow">https://github.com/statelyai/xstate?tab=readme-ov-file#super...</a>
I agree, I hate unnecessary hypercomplexity.<p>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.<p>If it were up to me, I'd build sites exclusively in .md format :)
I thought I hated React until I saw the samples on this page...
Philosophically Datastar is on the same page. Incredible performance and dramatic reduction in complexity.
Hate and love, the borderline framework for borderliners. SCNR
Why use JS at all for SSR?<p>It's not a great language for it.
I must have overlooked the site, but are there any working examples?
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?<p>See also: HTMX and possibly even jQuery
Yeah, no thanks..<p>I'll just stick with a $5 vps with lamp and jjquery
[dead]