You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@trusktr To be fair Most and the compared libraries appear to all be FRP. Ie.. unicast operator oriented stream transformation libraries. Technically you can build that on top of Solid but its reactive system is designed for auto-tracking like MobX etc.. So it's a very different sort of thing. Solid's reactive system is multicast and caches values with each node. They are designed for very different purposes. Solid's granular auto-tracking makes its ideal for working with granular view updates. Most and co are optimized for data transformation, io ops, I actually like using libraries like Most for stores, and async data loading and then feed them into Solid's reactive system at the leaves. These approaches can be complementary just aren't really the same thing at all.
EDIT:
It is possible to build operators on top of Solid like I've shows with solid-rx. So if someone chose they could build all of them and put Solid in the comparison. But the difference here is that is what these libraries do, and they all have more or less the same set of operators, so adding them to the suite was likely easy.
Thanks @trusktr and @ryansolid. I agree with @ryansolid's perspective that most and solid have different goals and approaches, and also can be complimentary. I'm not sure how much value most's microbenchmarks would provide for solid, but if someone thought it'd be useful and wanted to contribute them, we'd certainly take a look.
I'll leave this open for a bit to see what discussion develops.
Summary
It might be nice to add Solid's reactive signals and state into the tests, for comparison.
cc @ryansolid
The text was updated successfully, but these errors were encountered: