Plus the real power of reactivity is that it is push, not pull. The changes are propagated without ever needing to poll for the new value manually - for instance, you could display the value of b in a UI and have it change whenever the value of a changes.
Nothing I said implies either push or pull. Sufficiently smart runtimes can do both based directly on function definitions.
Even Excel knows how to bind a displayed value directly to functional dependencies and only recalculate when necessary.
I'm not denying these techniques are useful, I'm just pointing out that a lot of what seems nice about them is actually attempts to reimplement functional programming inside languages that don't do it very well natively.
Isn't the push strategy an expensive one? Maybe not all of the dependencies are needed right away, why bother with dispatching a new value though all of them? ...and more, considering that distinct dependency updates may require different (and admittedly expensive) computations, won't the push way be an overkill?
I'm not sure pull is any better in this regard. Simply stated, naive push and pull are both bad. You wind up putting a fair bit of heuristics on top of either to make them good.
Pull has the major downside that you never know when you need to pull a new value. Which is a pretty major downside.
And really, this does just feel like we baked some new semantics onto the observer pattern.
It depends on your point of view. From one perspective, the observer pattern is simply a way to implement reactive values in the OO paradigm - indeed, a somewhat arrogant FP aficionado would describe many of the GoF design patterns as clumsy OO emulations of things a functional language would be able to express much more elegantly.
In the Rx-style reactive model the big thing is making the event streams, in addition to the events, first-class objects, so they can be composed and manipulated with the usual FP subjects like map/filter/reduce. This makes, for instance, throttling to optimize the propagation of changes almost trivial compared to the situation where you only have individual events without context.
Yeah, I've read some of the papers. I was even heavily swayed for a time. However, I'm not entirely sure that Streams are an automatic win in abstraction. Often combining streams is just a very clumsy way of saying "add this and that."
More specifically, I think things are a lot easier when you can work way above those abstractions. As soon as you get into the weeds, all of the abstractions suck.
I also think this is specifically why people like angular so much. For many use cases, you are just setting values and having the UI present said values. Note, setting values, not appending to streams.
Now, do I expect that angular's internals would benefit from the streams metaphor? I certainly suspect so. Don't know, though.
