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.

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.

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.

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.

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 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.

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)

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.

Instead of HTML, think about GTK or Swing.

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.

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?

    UI elements automatically reacting to data changes (as oppposed to components updating themselves by listening to events)