Chris Hamilton, a developer on the Ember framework, writes about JavaScript framework design and reactivity systems like autotracking.
HN commenters link it as background on how Ember's autotracking works; the author adds context on the design's history, and an Ember user praises Octane.
Wow. I really didn't realize it was so close! I've just today finished up what took me away from my Ember project.
Ember has been freakin' amazing to use, and Octane really, really, makes it shine. I love ember because it includes everything you need to manage state in your application, install and you're ready to go. I don't have to pick my view renderer, state/history management, storage system, networking stack etc... I also don't have to maintain the dependencies between them, like I would with something built using React.
Ember also favors convention over configuration; which, I find to be a godsend when visiting the world of JavaScript. Yeah, it's a bit painful sometimes not knowing the convention, but that's just good ol' fashion learning. I also think the opposite, configuration, is incredibly painful in JavaScript, because the ecosystem moves so fast.
The Ember team (and community) also have fixed, and continue to fix, a ton of issues from making module loading easier to better support of Typescript.
I'd like to give a few getting started tips for anyone about to jump in (as I did the same a few months ago):
* Glimmer templates give you nice HTML-esque looking components while separating the HTML from the JavaScript itself (which I like versus embedding it like JSX does)
* Use the decorators. Seriously, they're awesome, they're a MUST if you use typescript.
* Ember modifiers are really a big improvement over the previous hooks/lifecycle management. It's just…
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.
Related and possibly helpful:
* How Glimmer.js implemented autotracking: https://www.pzuraq.com/blog/how-autotracking-works
* Discussion specifically on Lamport Clocks and autotracking: https://v5.chriskrycho.com/journal/autotracking-elegant-dx-via-cutting-edge-cs