Posted on January 10, 2015

After a few days of scratching my head, reading this tutorial and the package documentation, and playing about with examples, I have grokked Reactive Banana sufficiently to put together a trivial demo that exercises most of the functionality that I will need to redo the todo app. However, I still have not the faintest idea where the banana comes from.

I can report that reactive programming does indeed appear to deliver what it promises: event-based, non-spaghetti code. One thing that has particularly struck me is that reactive-banana does not force me to push all my state into a single structure, as I did with the GHCJS-only version of the todo app. The cost of keeping some parts of the code pure was that largely unrelated things had all to be shoved together. To some extent spaghetti was avoided, but the code would still have proved hard to extend and maintain. For example, just about any change to the State type would have meant tweaking all the State -> State functions. (To be sure, judicious use of field selectors and def could have mitigated this.)

With banana, I do need to provide a single type that can represent all my events. But beyond that, entirely independent (and largely trivial) functions tease unrelated events apart, and they can then act on separate behaviours, causing separate actions. This all looks very promising.

Just to keep score, here are the various technologies I’ve used or investigated so far.

  1. Pure yesod
  2. Yesod + Ember
  3. GHCJS + jQuery
  4. GHCJS + jQuery + reactive-banana

That’s all (so far), folks!