I’m confused and I feel bad as I’m going to be disagreeing a lot.
This post seems to imply that signals are somehow not declarative, but a performance-oriented non-declarative thing. And that plain React code is easier to write and maintain (as it’s somehow more declarative) until you have unique performance characteristics.
My experience has been very different. I found signals, in Solid.js, just as declarative as React code, and easier to reason about. Their declarative nature is the very thing that allows the code that builds on them to be performant - it has more information to reason about to trigger precise updates. The marketing surrounding signals emphasizes the performance characteristics a lot, but I myself find it far more important that it’s easier to reason about.
Raw performance of a framework isn’t everything: developer usability matters. The fastest framework is no
framework at all. But we use frameworks for a reason, and the reason is not performance, it’s developer usability.
That post probably says it better than my comment here, but I’ll continue.
I’ve used React + MobX for a long time and this brings some of the same affordances as signals do. When I used hooks-based React I was frustrated with how difficult it was to reason about - how many finicky rules there are around the various hooks, and how easy is it to get wrong with state management requirements that are dead-simple to handle with MobX.
It contrasts signals with “functional component-based frameworks like React”, but Solid.js is signals based and it looks like a component-based framework like React. Perhaps “functional” is doing the heavy lifting here but if a framework makes components look very similar to React even though it’s not re-rendering components for each update, how is “functional” useful?
Signals are not immutable of course, but immutability is not what makes something declarative. It’s describing the what over the how, and signals do that at least as well as hooks - I’d argue better as they do automatic dependency tracking, a “how” which is only about performance optimization, not functional requirements, that I don’t need to worry about anymore.
I don’t think there’s anything inherent in signals that make an API that uses it less declarative, and you can easily argue it makes it more declarative.
For developers weighing their options, the trade-off is pretty clear: stick with React if your data aligns well with your UI and you value a straightforward, mature ecosystem.
I think the trade-offs are different, so perhaps it’s less clear than that.
Stick with React if you want to use the mature ecosystem and the vast amount of libraries available. I’d recommend using a nice declarative observability framework with it - I’ve seen nothing that parallels mobx in ease of use and power, though things might’ve changed in the last couple of years when I have been paying less attention.
But if you want straightforward declarative code and still React-like components, use a signals-based system like Solid.js. In my experience it’s easier to use than React as well as faster and simpler inside, while extremely similar to it on the surface. The one obstacle I found (and it’s a huge one!) is the lack of mature libraries in its ecosystem.
I’m confused and I feel bad as I’m going to be disagreeing a lot.
This post seems to imply that signals are somehow not declarative, but a performance-oriented non-declarative thing. And that plain React code is easier to write and maintain (as it’s somehow more declarative) until you have unique performance characteristics.
My experience has been very different. I found signals, in Solid.js, just as declarative as React code, and easier to reason about. Their declarative nature is the very thing that allows the code that builds on them to be performant - it has more information to reason about to trigger precise updates. The marketing surrounding signals emphasizes the performance characteristics a lot, but I myself find it far more important that it’s easier to reason about.
As I wrote a few years ago
That post probably says it better than my comment here, but I’ll continue.
I’ve used React + MobX for a long time and this brings some of the same affordances as signals do. When I used hooks-based React I was frustrated with how difficult it was to reason about - how many finicky rules there are around the various hooks, and how easy is it to get wrong with state management requirements that are dead-simple to handle with MobX.
It contrasts signals with “functional component-based frameworks like React”, but Solid.js is signals based and it looks like a component-based framework like React. Perhaps “functional” is doing the heavy lifting here but if a framework makes components look very similar to React even though it’s not re-rendering components for each update, how is “functional” useful?
Signals are not immutable of course, but immutability is not what makes something declarative. It’s describing the what over the how, and signals do that at least as well as hooks - I’d argue better as they do automatic dependency tracking, a “how” which is only about performance optimization, not functional requirements, that I don’t need to worry about anymore.
I don’t think there’s anything inherent in signals that make an API that uses it less declarative, and you can easily argue it makes it more declarative.
I think the trade-offs are different, so perhaps it’s less clear than that.
Stick with React if you want to use the mature ecosystem and the vast amount of libraries available. I’d recommend using a nice declarative observability framework with it - I’ve seen nothing that parallels mobx in ease of use and power, though things might’ve changed in the last couple of years when I have been paying less attention.
But if you want straightforward declarative code and still React-like components, use a signals-based system like Solid.js. In my experience it’s easier to use than React as well as faster and simpler inside, while extremely similar to it on the surface. The one obstacle I found (and it’s a huge one!) is the lack of mature libraries in its ecosystem.
All the links seem to be giving a 404