S VS bruh

Related is S.js: https://github.com/adamhaile/s

I love signals. I prefer them when making UIs over any other primitive (besides, perhaps, the cassowary constraint algorithm). I try to replicate them in every language I use, just for fun.

I also don't believe they belong in the Javascript language whatsoever. Let the language be for a while, people already struggle to keep up with it. TC-39 is already scaring away people from the language.

"Signal" has been used in FRP circles for some time [1,2]. The original FRP stuff was events/signals and behaviours. But I agree that JS didn't use this terminology until more recently. S.js is maybe one of the earlier ones, but that was still over 8 years ago.

[1] https://scholarworks.rit.edu/cgi/viewcontent.cgi?article=651...

[2] https://github.com/14427/signal

[3] https://github.com/adamhaile/S/tree/e897ec1212a073bb1fe695e1...

Fine-grained reactivity libraries have been growing in popularity recently. Examples include new libraries like Preact Signals, µsignal, and now Reactively, as well as longer-standing libraries like Solid, S.js, and CellX. Using these libraries, programmers can make individual variables and functions reactive. Reactive functions run automatically, and re-run 'in reaction' to changes in their sources.

No. Krestianstvo SDK 4 is introducing its own implementation of Croquet Application Architecture in JavaScript, based on Solid JS & S.js using Functional Reactive Programming (FRP).

SolidJS / S.JS

Cool! This reminds me of S.js [0] which I've used a decent amount to great effect, but it seems about half the size. I'll have to look at how they compare (though if someone knows off the top of their head that'd be appreciated). S.js is nice because it has a helper library (surplus) for dom things.

[0]: https://github.com/adamhaile/S

There are a lot of good libraries and frameworks to handle state management and reactivity. From simple and short utilities such as S.js to heavy solutions like Solid.

except that is wrong... you're welcome.

The key is topological sorting of a dependency graph. This can be done implicitly by storing a reactive variable node’s depth once it is created, and just making sure that updates are enqueued in separate queues per depth.

I have a somewhat small implementation that transparently batches updates with queueMicrotask in this library (bruh): https://github.com/Technical-Source/bruh/blob/a829af9df9405b...

If you have any questions, you can ask here now or in the discussions tab in the github page.