| A little more context: I've been working on the design of this reactivity system in some form since roughly 2018 as part of the Ember framework. The original design of the reactivity system made its way into Ember Octane as the "auto-tracking" system, and was fairly exhaustively documented (as originally designed) by @pzuraq in his excellent series on reactivity[1]. He also gave a talk summarizing the ideas at EmberConf 2020[2] after Octane landed. Unfortunately, there's no good way to use the auto-tracking system without the Ember templating engine and all of the baggage that implies. But there's nothing about the reactivity system that is fundamentally tethered to Ember or its templating system in any way! For various practical reasons, Tom, Chirag and I had a need to build reusable chunks of reactive code[3] that work across many frameworks. We liked the foundation of the auto-tracking system enough to extract its ideas into a new library, decoupling the auto-tracking reactivity system from Ember. PS. In case you're wondering, I expect Ember to ultimately migrate to Starbeam, once it's in solid production shape and the dust is shaken off. [1]: https://www.pzuraq.com/blog/what-is-reactivity [2]: https://www.youtube.com/watch?v=HDBSU2HCLbU [3]: I would have called them "components", but that would make it seem like they have something to do with creating reactive output DOM, which is not what I mean. |