This is basically what Vue and Solid do, no? Same sort of state and derive/computed variables, it seems like.

Also, I will never understand why people like reactive signals. The article even quotes "Knockout being right all along" which, no, reactivity and two way data binding creating a spaghetti mess of changes affecting other changes all over the place unless you're really careful is why React was made in the first place, to have only one way data binding and to re-render the entire page in a smart way. React will soon get its own compiler as well which will made regenerating the DOM even more efficient.

It's like every other framework is slowly rediscovering why React made the decisions it made. I am assuming it's because the users who are making these frameworks now have not used or do not remember the times where "signals" were called observables, or the usage of Rx libraries, and how having too many of these would cause you to lose your mind debugging the intricate webs you inadvertently spun.

Yes, the API is very similar to Vue's. $state is ref/reactive, $derived is computed, $effect is watch/watchEffect.

> why React was made in the first place, to have only one way data binding and to re-render the entire page in a smart way

This last part is why Vue and now Svelte didn't adopt React's model. Yes, reactivity and two-way data binding give you enough rope to thoroughly hang yourself, but it also gives you a very explicit picture of how and when components will update. React, on the other hand, expects you to trust its smart algorithms, which definitely removes a lot of the pain from day-to-day coding but also makes troubleshooting performance problems harder.

I see the distinction as similar to GC languages vs something like Rust: if all you need is to have an app that does a job and you don't care about how it does it, React is a good choice. If you need to have control over exactly what will update and when, Vue's model gives you fine-grained control over updates that's hard to achieve in React.

EDIT: And with that in mind, it's obvious why Svelte, which prides itself on being lean and fast, would avoid the React smart-but-complicated runtime model in favor of the Vue model.

You make it sound like react is a dark box with a lot of magic behind the curtains, but I always found the react model very easy to reason about. Modifying state is explicit and is the only thing that can trigger a rerender. These rerenders can only happen down from where in the tree the state change happens.

I mostly agree with you.

Unfortunately, many React apps use Relay (another Meta product) and it opens up a world of “magic” that is sometimes a real pain to reason about.

What do you mean by "many?" While I like Relay, I've almost never seen Relay used in the wild. It's sad as it's quite an elegant concept; just as you define your props for your React component, you define your "props" coming from the server as well, through the GraphQL notation. I've been looking at ways to combine both concepts so that there is no client- or server-side state at all, it's all just state, from a cache that determines whether to refetch from the server or to keep the state local.

https://github.com/coralproject/talk

I agree that Relay CAN be simple, but it isn't for what we do. Have a look at this ReplyListContainer and its nested Relay logic. I didn't originally write this, but I can see what they were trying to do and how Relay made it difficult for them. Your thoughts are welcome, I won't judge you for being critical of our code and welcome any other Relay dev's opinions.

https://github.com/coralproject/talk/blob/develop/client/src...