> To overcome the shortcomings of the default change detection paradigm, the Angular team is working on a new approach called Signals. Conceptually, signals are similar to Svelte stores (which we’ll get to later), and fundamentally, they solve the change detection problem the same way as React; the framework is taking control over the application’s state so that changes can be easily monitored and re-renders can be as efficient as possible.
I radically disagree with this statement. Angular Signals (and signals in general, as in SolidJS) could not be more different from React's change detection model, and they are not particularly similar to Svelte stores either.
In React, your component function is a render function, which reruns. React diffs the state object when `setState` is called, determining which part of the DOM to update.
Signals-based solutions are generally much more fine-grained: the framework knows which portion of the DOM was affected by the signal, and does not need to diff the entire state object. This "surgical" approach requires more explicit state management on the part of the developer, through the use of Signals to wrap the application state. However, DOM nodes can be updated without doing a large, expensive diff. (As a corollary, the component function is typically a create function, not a render function.)
The developer experience is quite different as a result.
Signals have their own shortcomings as well. Once you leave the "re-run the render function on state change" you suddenly are dealing with implicit dependencies, stale closures, cyclical updating, and all sorts of weirdness in debugging things, figuring out what triggered what, etc.
Signals as a concept existed well before React and I think part of the genius of React is actually not using them. In a way a signal is just a very simple version of RxJS that Angular is moving away from, with a lot of the same downsides, just without all the pipe/abstraction mess.
> I think part of the genius of React is actually not using [signals]
Except that with the introduction of hooks (aka "OCaml 5.0 effects, but in JS, as a UI framework") you get some of the same interesting issues cropping up in React codebases as well, just spelled differently (stale closures, implicit dependencies, weird debugging issues)
Well you get explicit dependencies which have ups and downs, but closures do become an issue. That said, I find hooks less magical and less prone to cycles, especially as you're staying with a top down data flow generally.
For a little while it looked like mobx was going to displace Redux in React-world, and if that had happened it would have brought this to React without having to change React itself.
Mobx had one thing going for it -- it let you update your neighbor easily. But now Reacts useExternalStore achieves that cleanly with about 100 lines to wrap it in a cute API.
The proxy stuff I don't trust. Burned me once, never again.
The proxy stuff always works great when fiddling around with it in a small project. However, my experience has been the same. Whenever a project using proxies leaves the playground phase, all sorts of nasty bugs and performance issues arise.
> Signals-based solutions are generally much more fine-grained: the framework knows which portion of the DOM was affected by the signal, and does not need to diff the entire state object
I believe this to be generally pointless. Diffs are not that expensive, DOM changes are. The only case where this would help is you have a very large diff but a small amount of actual changes. React offers tools to handle this without changing the entire state management paradigm.
> React diffs the state object when `setState` is called, determining which part of the DOM to update.
Er, what? That's not true at all, even for class-based components. `setState` merely queues up another render of the function and its children. There is no diffing, except for the new DOM returned against what is currently rendered.
There are a large number of very incorrect statements in this article.
> True to its de-facto tagline, change detection in React is “just JavaScript.”
Then in the example, the author updates a variable with `setCount(count - 1)`. That's not "just JavaScript". Just JavaScript would be `count = count + 1`.
Well, JavaScript has no simple way to react to an assignment like count = count + 1 without introducing some magic between the code you write and the final code that runs in the browser. Svelte is only able to achieve that experience because it has a compilation step, but React does not; hence why setState() is necessary and why people argue it's more "just JavaScript" because the code you write is pretty much the final code that runs (aside from the transpilation necessary to convert JSX syntax into JS, but this doesn't alter the way that anything works).
This isn't to make any kind of judgement on either approach though, I personally really enjoy the DX that Svelte offers.
I radically disagree with this statement. Angular Signals (and signals in general, as in SolidJS) could not be more different from React's change detection model, and they are not particularly similar to Svelte stores either.
In React, your component function is a render function, which reruns. React diffs the state object when `setState` is called, determining which part of the DOM to update.
Signals-based solutions are generally much more fine-grained: the framework knows which portion of the DOM was affected by the signal, and does not need to diff the entire state object. This "surgical" approach requires more explicit state management on the part of the developer, through the use of Signals to wrap the application state. However, DOM nodes can be updated without doing a large, expensive diff. (As a corollary, the component function is typically a create function, not a render function.)
The developer experience is quite different as a result.