> In Backbone, you had view with a model that managed a dom element tree. You could render whenever you wanted and exactly when needed.

In Backbone, many people over-rendered like crazy. And in a far more disruptive & costly redraw process than React's VDOM. React made rendering much faster & eliminated the complexity in figuring out what and when to render: just redraw, and it will be fast. This joins with Flux/Redux's advantage, to which you say:

> We kind of didn't need it though.

You talk about SQL being a big ball of mud / mutable state & saying we were fine with it. But what we get from Flux/Redux is selectors, where we can react to changes in data & only redraw what we need. Direct data flow let us make our apps much faster, and in a way where we didn't have to explicitly carefully manage all the data-flow dependencies ourselves: here's a pattern to subscribe, here's a pattern to write, and the store works it all out. It was hugely useful.

If anything, the battle here has just subtly intensified over the years. Observables keep simmering along. Lenses were a thing for a bit but faded. Signals seem to be the up-and-coming, with dozens of incredibly high performance frameworks and big names like Angular tracking to them, to much more precisely manage these data-flow problems, all in the name of doing what Redux did: letting the computer quickly figure out what work & rendering actually needs to be done.

Having a formal system for data also has huge upside. The Redux dev tools are an incredible window into what is happening in your app over time. Having a well defined world enables incredible powers of observation: it's a stunning & massive win.

> Hooks and the like just feel like an entirely different programming language. It's impossible to trace what is actually going on.

Anecdata here, but I've been at quite a number of pipelines with strong hire-from-college & hire-from-bootcamp pipelines, and my heavens. These newcomers definitely take to hooks much better, in my view. And it's much easier for me to code review & see the intent & to suss out weaknesses.

Contrary to your claim, struggle to think of coworkers ever actually having to dive into React codebase to understand or optimize code. Understanding when to useCallback is a micro-lesson, but makes sense if you know DOM. If you understand vdom basics you should understand why deps are there and what they're for, but that's still a micro-lesson that needs teaching or sometimes re-teaching, but usually takes 20 minutes. If anything, I think it's staggering & threatening how little people understand their frameworks, but it just doesnt matter.

> there are all these edge cases and the realities of interop with a big ball of DOM state.

What's the use case here? What are we talking about? Why do you need to interop with the DOM? I generally find that writing event handlers in React is no problem at all. Is that what you're talking about? What's the situation?

> Ocaml was a terrible choice.

In retrospect maybe perhaps, but I still think of Ocaml as a brilliantly smart programming language with a huge stock of incredibly talented developers. Maybe yeah it didn't work out, but I can absolutely see the signs of promise, and see why the vision here could have worked out and could have made sense & could have been powerful.

More generally, I don't think this is the avenue of consideration I'd be looking after. What about Flow was bad or overly complicated or otherwise bad? There's arguments against the community failing to take off, sure, but good tech badly supported is a different argument than the "overly complicated" "big ball of mud" grievances.

> For many years to come, no one can stray too far for React to innovate because of the familiarity and risk.

In this I share laments. I myself want to embody the radical revolutionary trying new things ever improving spirit, and the long era of React has been such a giant damper after so many years of tuning in daily to be thrilled with new ideas on Ajaxian & feeds. We have so much more to explore & improve, and we cannot stop here.

But I also think it's unclear what is worth switching for. There are some really alluring interesting concepts out there. Qwik's resumable-ness is a fascinating concept, and a compelling alternative to the typical SSR hydration. I am so excited to see where Solid goes and hope we can see some more shape towards 2.0 emerge. Threads on signals & new signalling libraries get semi-regular traction here on HN & are such a point of excitement & possibility. I keep hoping we'll distill out clear paths for WebComponents, and it seems like Lit does get shipped a decent bit but few others do. Overall it doesn't excite me but I recognize most people are trying to solve business problems, and they are replete with known viable choices & options if they stay somewhere in the huge React ecosystem. It's not just the hype machine to me: there really aren't the clear technical wins yet for most alternatives to become established worthwhile options one can feel confident picking.