I am not an FRP expert but I've played around with both Elm [1] and Flapjax [2]. With both libraries, I ran into a basic mismatch with what I wanted to do. They both make it very easy to have static controls create dynamic behavior. You create the controls, observe them, and then combine their signals to output whatever dynamic output the program has.<p>But most interesting web UIs are not static->dynamic; they instead involve dynamic and circular dependencies. Pressing the "add new todo" control doesn't just dynamically affect the display, it also creates new controls that need to get added into the set of observable things that affect the display. This idea, of modifying existing observables to include new observables, is somewhat problematic. In examples I've seen, it ends up leading back to code just as unfortunate as imperative callbacks.<p>If you can use Bacon to create an entry for TodoMVC [3] showing how to have dynamic->dynamic dependencies, I'll be sold.<p>[1] <a href="http://elm-lang.org/" rel="nofollow">http://elm-lang.org/</a><p>[2] <a href="http://www.flapjax-lang.org/" rel="nofollow">http://www.flapjax-lang.org/</a><p>[3] <a href="http://addyosmani.github.com/todomvc/" rel="nofollow">http://addyosmani.github.com/todomvc/</a>
TL;DR: Reactive Programming ≈ Sequence Comprehensions + Futures.<p>This looks pretty similar to a .NET library called Rx (Reactive Extensions). We're using it in a MonoTouch iOS app and I found it to solve some problems in a very convenient way. If you used functional style in your code, you know it shines in mapping/filtering/aggregating/reducing sequences of data. In .NET LINQ sequences have type of IEnumerable. You can think of Rx's IObservable as of IEnumerable's odd twin brother. The main difference is you IEnumerable is “cold” by its nature: it produces new items when you ask for them by calling MoveNext(). It doesn't do anything by its own. It's also synchronous.<p>IObservables, however, can both be cold and hot, i.e. they can yield items without being asked to. It's like IEnumerable but with “don't call me—I'll call you” approach. Because of this, it doesn't have to be synchronous. Long processes that emit one item at a time, which may later be transformed, processed in batches, throttled, etc, benefit from being expressed via IObservable. The benefit I found is you can easily switch between different asynchronous data source implementations.<p>For example, it's trivial to write an IObservable wrapper around iOS Photo Library that will yield one item at a time. Then you can write a function that compares cached items in array with new items that arrive from photo library, and return IObservable of “differences” between cached and new data. Then you group those differences using built-in methods into batches—and feed them to UICollectionView so it can <i>animate the updates as the application receives them from system API</i>.<p>Then you just write another IObservable implementation for getting photos from Facebook, and wrap it in a function that will pre-fetch their thumbnails before yielding them. It is also an IObservable. You already implemented updating collection view, so you just plug in your new asynchronous data source and that's it.<p>Need to implement a Dropbox file picker? You already implemented collection view logic, diff logic and prefetching images, so you just need to wrap Dropbox folder fetch API in an IObservable, and merge IObservable-s from nested folders.<p>On top of that, you can add some caching, and magically it will work for any data source.
Anyone who's interested in this should also take a look at Functional Reactive Bindings: <a href="http://documentup.com/montagejs/frb/" rel="nofollow">http://documentup.com/montagejs/frb/</a><p>Boasts of realtime, 2-way bindings between any JS object.
It really disappoints me when good projects are given names that trigger bad mental associations.<p>Sure, everybody loves bacon – except vegans, vegetarians, Jews, and other swine-shunning cultures – but I really don't want to be thinking about bacon when I'm programming. Nor do I want to evoke the smell, taste, and unhealthiness of bacon, nor the dirtiness of pigs, in the minds of people I talk to about Bacon.<p>Largely for this reason I will probably not try, use, or try to get my friends to use Bacon. Please consider changing the name, perhaps to something that evokes the conceptual spirit of the project, because I'd like to see more people adopting FRP techniques.
I think this is related but not sure: <a href="http://www.cs.umd.edu/projects/PL/arrowlets/" rel="nofollow">http://www.cs.umd.edu/projects/PL/arrowlets/</a>