This article is completely backwards. We do not want to manually manage what-gets-refreshed-when. The whole point of React was to react to state changes automatically.
One upside of this approach is that the only subtree that needs to be re-rendered is the specific element whose state got mutated.
Another upside of this approach is that the code doing the mutation is very close to the actual UI element that triggered it. Of course, this rapidly turns into a downside as the size of the codebase grows...
It's not automatic though. Theres function calls() and you must createSignal for every derived value.
When you ignore the performance aspect, React has the objectively least amount of boilerplate for reactivity.
The question, that I genuinely don't know the answer to, is a) whether the performance improvement is worth it, and b) whether that's still the case after the compiler.
React is the most inefficient in terms of performance (after imgui); it recomputes everything on every event like mousemove. It was probably made for simple forms with tens of variables.
> The whole point of React was to react to state changes automatically.
It isn't, given that React requires you to provide an array of dependencies when using useMemo and useEffect. The point of React is to automatically update the DOM when a virtual DOM tree gets modified.
Yeah, I'm interested to learn more about signals, but the article seems to miss the whole point of brute-force state updates -- less cognitive complexity.
I can understand the point, and the fact that in virtual dom implementations you in general specify the state -> view mapping and don't need to distinguish between first render and updates.
However, practically and personally I find working with signals way simpler, and that is even without considering the debugging experience.