|
|
|
|
|
|
by tomdale
1509 days ago
|
|
|
Hey folks, I've been working with wycats and my colleague Chirag Patel on Starbeam for the last few months. We prefer to work in the open, but this repo is still a work in progress and is definitely not ready for public consumption, other than very very very early adopters. We were planning to reveal more in June when things were more buttoned up, and certainly didn't expect to see this on the HN front page! That said, we'd be happy to answer any questions people have about Starbeam, with the understanding this repo is still very WIP. |
|
|
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.