-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comparison to other reactive libraries #18
Comments
Hi, That is a hard question since there are many libraries :). Let's first define "(functional) reactive programming":
Generally speaking, I think there are two important flavors of reactive programming: Event stream based FRPEvent stream based libraries, focus at manipulating streams and are very good at that. Joining, splitting, merging, mapping, sampling etc. These libs are useful if you want to reason about multiple event streams at the same time. Or when throttling plays an important role, like with network traffic. For solving simple problems though, these libraries are quite obtrusive (imho). They need a different mindset. Also, representing every variable in your state as stream might become quite unwieldy. Examples: RxJs and BaconJS. Transparent FRPTransparent Reactive programming on the other hand tries to hide reasoning about time. It just applies reactive programming in the background. Like with event based, TFRP updates views whenever needed. The difference is that in TFRP you don't define how and when stuff updates. While with streams you (have to) define that explicitly. The tracker library of Meteor summarizes this nicely:
Examples of frameworks that apply TFRP libs are knockoutJS, EmberJS and Meteor. Mobservable is stand-alone, although it ships with a small ReactJS binding. These are things that makes mobservable distinctable from other TFRP libraries:
I'll hope that answers your question. |
Thanks. This answer helps to understand Mobservable better.
|
Would it be possible to give some insight on the benefit of using Mobservable over Tracker? |
Hi @mehdi-cit , The pure basics of libraries are very similar; the dependency of functions will be tracked automatically, so that the can be re-run when one of their dependencies changes. These are the interesting differences however:
Oh it is true indeed that changes are only propagated if a computation really resulted in a new value indeed. But I'm not sure whether the same holds for tracker or not. P.s.: an atomic update is this: var thing = makeReactive({
value: 2,
squared: () => this.value * this.value,
cubic: () => this.value * this.squared
}); now suppose you are observing |
Oh, another notable difference is that there is hardly any cleanup to do in mobservable, only |
Thank you Sir. |
Along this lines i would also like to point out that i wish i knew about Good job! El El vie, 21 ago 2015 a las 9:47 a.m., mehdi-cit notifications@github.com
|
I assume
Here's an excerpt from the Meteor docs about their "An important property of ReactiveVars — which is sometimes a reason for using one — is that setting the value to the same value as before has no effect;" So if you're using a |
@aleclarson observable arrays are basically objects with numeric keys and all the other array methods |
I would like to see a comparison between Mobservable and other reactive libraries.
The text was updated successfully, but these errors were encountered: