(repost from the Asciinema thread, this comment feels more on topic here)
Wow, I just read about Solid for the first time, and I'm impressed at the API design. I love how it's a fully reactive data flow thing, but it looks and feels like React Hooks.
The other reactive/observable-based frameworks I've seen (eg Cycle) put the observable streams center piece. I always felt that was distracting, and that nuances about how the underlying observable stream library worked (eg Rxjs or Bacon) quickly got in the way.
Solid still puts the components firmly at the center, just like React, but replaces React's state concept by reactive observable state, called "signals". You use them like you useState in React, but deep inside it's an observable stream of data changes, and you get all the finegrained update control that comes with that.
I also love how noun-heavy it is. Resources, tracking scopes, effects, signals. It's just like how React moved from "do this thing after the component updated" to "ok we have this concept called an effect", but extended to more topics such as dealing with async data loading, when exactly a signal is observable, etc.
By fine grained update control -- do you mean similar to mobx + react. I think "automatic change tracking" is the phrase I've seen thrown around. If so this was always the most appealing method for performant UI's for me. You have some conceptual overhead of dealing with observables, but in return you get to ignore the majority of performance -- components only update when the data they need to use changes, and you never have to manually specify it. Really nice for web apps that have a lot of mix and match screens (say, complex internal tooling that may have numerous components re-used ina variety of places).
It's a bit like MobX but instead of re-running full components or subtrees it contains the updates granularly. Picture if your renderer was just MobX Autoruns wrapping specific DOM updates as depended upon. In so because the reduced of need for diffing and the compiler that transforms the JSX to this you can author components in a normal way yet get incredible performance.
Reading this I'm reminded of knockoutjs, which the author of SolidJS cites as an influence. I remember at one point, years ago, trying to figure out why it was so much faster than AngularJS. Two things seemed to be going on: 1) It was only updating the parts of the DOM it needed to 2) To do this it seemed to 'automagically' be inferring dependencies.
I wondered how they did this second thing and guessed that it was parsing the JS code I was writing somehow. Either that or flooding the observables with values and making note of how changes trickle down. It turned out that it was doing neither of those things but frankly I didn't understand how it worked even when it was explained to me. Might be a good time to revisit and satiate my curiosity and take another look at it.
It just tracks function calls. The general idea is that if a function is called in the render cycle of a component, that registers as a subscription for that piece of data that function returns. There is some magic with proxy and getter to hide the functions but basically that's it.
Comments
(repost from the Asciinema thread, this comment feels more on topic here)
Wow, I just read about Solid for the first time, and I'm impressed at the API design. I love how it's a fully reactive data flow thing, but it looks and feels like React Hooks.
The other reactive/observable-based frameworks I've seen (eg Cycle) put the observable streams center piece. I always felt that was distracting, and that nuances about how the underlying observable stream library worked (eg Rxjs or Bacon) quickly got in the way.
Solid still puts the components firmly at the center, just like React, but replaces React's state concept by reactive observable state, called "signals". You use them like you useState in React, but deep inside it's an observable stream of data changes, and you get all the finegrained update control that comes with that.
I also love how noun-heavy it is. Resources, tracking scopes, effects, signals. It's just like how React moved from "do this thing after the component updated" to "ok we have this concept called an effect", but extended to more topics such as dealing with async data loading, when exactly a signal is observable, etc.
By fine grained update control -- do you mean similar to mobx + react. I think "automatic change tracking" is the phrase I've seen thrown around. If so this was always the most appealing method for performant UI's for me. You have some conceptual overhead of dealing with observables, but in return you get to ignore the majority of performance -- components only update when the data they need to use changes, and you never have to manually specify it. Really nice for web apps that have a lot of mix and match screens (say, complex internal tooling that may have numerous components re-used ina variety of places).
It's a bit like MobX but instead of re-running full components or subtrees it contains the updates granularly. Picture if your renderer was just MobX Autoruns wrapping specific DOM updates as depended upon. In so because the reduced of need for diffing and the compiler that transforms the JSX to this you can author components in a normal way yet get incredible performance.
Reading this I'm reminded of knockoutjs, which the author of SolidJS cites as an influence. I remember at one point, years ago, trying to figure out why it was so much faster than AngularJS. Two things seemed to be going on: 1) It was only updating the parts of the DOM it needed to 2) To do this it seemed to 'automagically' be inferring dependencies.
I wondered how they did this second thing and guessed that it was parsing the JS code I was writing somehow. Either that or flooding the observables with values and making note of how changes trickle down. It turned out that it was doing neither of those things but frankly I didn't understand how it worked even when it was explained to me. Might be a good time to revisit and satiate my curiosity and take another look at it.
This is the article series for you (I wrote it so I'm biased): https://dev.to/ryansolid/a-hands-on-introduction-to-fine-gra...
It just tracks function calls. The general idea is that if a function is called in the render cycle of a component, that registers as a subscription for that piece of data that function returns. There is some magic with proxy and getter to hide the functions but basically that's it.