3 ms·
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
by grayrest 4y ago
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.
- CMCDragonkai 4y agoWhat about self-adjusting computations, incremental DAG, reactive demand programming, datalog?
- grayrest 4y agoWhat about them? 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.