S VS bgjs

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 author does a lovely job of covering a number of the interesting ideas in this space. But reactive programming is such a tough sell. I know from experience.

I maintain a reactive, state management library that overlaps many of the same ideas discussed in this blog post. https://github.com/yahoo/bgjs

There are two things I know to be true:

1. Our library does an amazing job of addressing the difficulties that come with complex, interdependent state in interactive software. We use it extensively and daily. I'm absolutely convinced it would be useful for many people.

2. We have completely failed to convince others to even try it, despite a decent amount of effort.

Giving someone a quick "here's your problem and this is how it solves it" for reactive programming still eludes me. The challenge in selling this style of programming is that it addresses complexity. How do you quickly show someone that? Give them a simple example and they will reasonably wonder why not just do it the easy way they already understand. Give them a complex example and you've lost them.

I've read plenty of reactive blog posts and reactive library documentation sets and they all struggle with communicating the benefits.

State machines are cool but they don't compose well out of the box. Behavior Graph let's you build a composable network of them so they become a practical software architecture. (Disclaimer, I am a coauthor) https://github.com/yahoo/bgjs

HTTP imports in Deno are really nice for making quick little test apps. I threw something together the other day using Comlink, that Yahoo state library, and a couple of other things without having to think about package.json or anything else. I wanted a throttle, so I just imported it from the source. It was all light and fast and Just Worked.