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.
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.
[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.
Like @tomdale, I'm surprised to see this on the front page of Hacker News!
I have been working on more detailed documentation about the overall model. It's also still in flux (and not ready for release ), but you can check it out at https://wycats.github.io/starbeam-docs/.
>We call this collection of values the data universe. The data universe is always internally coherent. Once you mutate your state, you can call any function that depends on the mutable state, and that function will see an up-to-date version of the state.
It's a model. Call it a model. This reinvention of standard CS terms is a constant source of cringe in the JS community.
I’m not sure that’s a fair criticism. Would calling this a model help? That’s such an abstract and overloaded term. Also, I know not everyone can know every open source author, but wycats has been a crucial contributor in the Ruby, Rust, and JS (probably more) ecosystems for over a decade. I doubt he picked the terminology out of naïveté and would guess that he would welcome discussion on the topic if you raised it in the repo.
Is the main benefit of this the cross-framework support? Or does it provide something beyond the state management of the existing frameworks that it integrates with?
Is the encapsulation of computed values (formulas) something that trades for the added complexity?
Edit: I guess I'm wondering who this is for? Is it aimed at SDK maintainers who want easier compatibility with multiple frameworks?
Edit edit: Audience is clarified at the bottom of the README[0]. It is indeed library maintainers primarily.
Looks awesome! Big fan of doing UI this way, but honestly I find doing BE stuff like this too, but typically find it too difficult to read/share to do often
They're in the same general class of dataflow systems but the emphasis is different. Rx and other FRP libraries emphasize control over the flow of data through the observable chain: lots of combinators, explicit creation and merging of observables, etc. Cell libraries (my term, nobody's come up with a name that's stuck) are mostly about propagating updates to UI and are generally meant to be as simple as possible otherwise so they'll terminate propagation when there's no change in output, do automatic subscription management, and offer minimal to no control over the observables themselves (control is done from within the flow).
Historically there's been a significant performance difference between the FRP set and cell libraries. I haven't kept up with Rx so I don't know if that still holds but cell libraries have substantially fewer constraints on their use cases so I expect it to. If a compiler is involved, cell libraries can get big wins by compiling the reactive updates to JS functions and getting boosted by the engine JIT.
Cell libraries have been around for a while. Knockout popularized them but I'm sure someone wrote one before that point. I glanced through the README and didn't see anything particularly novel about this implementation.
Self-adjusting computation is probably the closest term for what I call cell libraries but the only time I've seen it used outside academia is when Jane St announced their cell library. My understanding is that the term covers a wider variety of techniques than the three or four common variations I've seen in cell libs. Incremental computing seems to cover an even wider subset.
Wasn't aware of reactive demand programming. My quick skim over the top search hits has the authors insisting that there's upstream parameter passing as part of their model. I've seen that done once in a toy/weekend project as well as true bidirectional computation in Kris Zyp's Alkali (by defining a transformation function each way) but usually the only "upstream" information I've seen in other cell libs is a demand for computation if it's pull based instead of push based. Also wasn't aware of "incremental DAG" but searching for that term doesn't turn up anything at all.
Datalog is only tangentially related in that it seems to pretty much always be implemented incrementally. I'm not an expert but I'm pretty sure it's still datalog if your implementation is stupid.
There's other related fields of computing: most incremental computations can be modeled as unidirectional constraint solutions, timely dataflow allows for incremental computation (including cycles) across distributed nodes, databases perform view maintenance, lens libraries can be implemented incrementally and chained to accomplish similar things.
The JS community is the most prolific author of the libs I'm talking about, mostly because the size of the community, the direct demand for it (incremental UI updates), and the relative ease of implementation. The most common term I've seen for it is "reactivity" or a "reactivity system", which I simply don't like.
Edit: It occurred to me that I didn't mention the obviously related spreadsheet engine in this response. I've only looked at a handful of spreadsheet implementations but none use the function + heap allocation per computation step pattern (i.e. cell) that cell libs use. Their use patterns have a lot more cells and generally less control flow so the focus is generally on arrays and unconditional updates.
That said, we'd be happy to answer any questions people have about Starbeam, with the understanding this repo is still very WIP.