Reactive Programming in JavaScript

As someone who's been going down this rabbit hole for the last year or so:

Haskell is worth learning because a lot of the work done in FRP has been done in a Haskell mindset. Flapjax, Fran, reactive-banana, Elm---all are written in Haskell or trace significant ancestry therefrom.

Clojure is worth learning because, well, it's the future, but also because the community seems to be bent on finding actual application for lofty CS concepts. If you want to use facebook's React, you can use JS, coffescript, facebook's "JSX" compiler, or clojurescript. I'd argue that clojurescript is the most pleasant option.

If you want to learn about FRP inside and out, Haskell. If you want to write something cool and reactive, Clojure.

(Other names to look at if you go clojure: Shafty, Javelin, Lamina, core.asynchronous)

The ideas here are similar in a sense. I'm not an expert on Angular, but their focus seems to be on templates that update automatically using data bindings. Our framework focuses more on compositionally of reactive data networks, connecting it to the DOM using reactive jQuery methods is just one of the outputs we allow.

The set and get methods are there to go from the JS world to the reactive world and back. Usually you're working with reactive variables (as if they were actual values) directly, in that case you won't use get and set at all.

Not exactly Functional Reactive Programming, FRB (Bindings) are actually a form of Self Adjusting Computation, but similar in spirit to what you see here, and what you see in Angular. You don’t need #get() and #set(), but it’s implemented using ES5 property descriptors and propagates synchronously. Also, unlike dependent properties like Ember, the dependencies do not have to be repeated—they are inferred from the expression language.

https://github.com/montagejs/frb

Sadly we haven't open sourced the library (yet?). The actual implementation is quite a bit larger, and messier, than described in this blog post. Additionally, it's written in our own module system. So while we'd like to open source it, it currently is more work than we have time for.

Fixed, thanks!