FRP - Demonstration of reactive-banana in the web browser with Ji
EDIT (2013-08-01): The reactive-banana-ji experiment has now been superseded by the reactive-banana-threepenny library which is available on hackage.
My primary motivation for creating an FRP library was to write GUI programs. With the release of reactive-banana version 0.7, I consider FRP to be a mostly solved problem now, at least to the point where playing around with FRP in isolation does not yield significant insights anymore. It is time to return to my original motivation and focus on the interactions between real GUI programs and FRP. I’m sure that they are plenty of design patterns waiting on the road towards the ultimate goal: writing GUI applications with just one line of source code!
Unfortunately, it appears that Haskell GUI libraries are mostly dormant these days. Both Gtk2Hs and wxHaskell are tricky to install and haven’t seen any recent work on their API. I prefer not to bet on a horse that lies in the grass, regardless of whether it is just sleeping or whether it will never wake up again.
But there is one GUI framework that people are throwing serious efforts at: the web browser! Projects like haste, uhc and ghcjs try to compile Haskell to JavaScript, alternative approaches to Haskell in the web browser are investigated with fay and Ji, and Haskell-like language like elm and roy are showing up.
It looks like these efforts are not ready for prime-time just yet, but I feel compelled to do my part and add fuel to their momentum. Thus, I have whipped up a small demonstration that uses reactive-banana with Ji to create a small GUI example. You can find the project on github in the folder reactive-banana-ji. Here a screenshot:
Typing in one input field will immediately update the other input field, i.e. data can flow in both directions. The source code is very simple, it just declares the value of each input field to be a transformation of the value of the other field. FRP takes care of the recursion and the automatic updates.
The example code still contains more administrative details than I’m happy with, like the compile function and the specialized behaviorValue functions. But that is because neither the DOM bindings, nor my reactive-banana glue have seen any serious API design efforts. The time is ripe for changing that!
It sure looks like 2013 is going to be the year of Haskell in the web browser!
Howdy, cowboy, it’s advertisment time! If you like what I’m doing with reactive-banana, you can support me with a small donation: 
. (I stopped pestering people with my ¢2 worth status information at the end of every month, though, but that is perhaps for the best.)