# Reactive Banana 1.2.2.0

**URL:** <https://discourse.haskell.org/t/reactive-banana-1-2-2-0/3249>\
**Category:** Announcements\
**Created:** [September 16, 2021, 7:17pm UTC](https://discourse.haskell.org/t/reactive-banana-1-2-2-0/3249 "2021-09-16T19:17:10Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![ocharles](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ocharles/32/102_2.png) [@ocharles](https://discourse.haskell.org/u/ocharles)\
**Post date:** [September 16, 2021, 7:17pm UTC](https://discourse.haskell.org/t/reactive-banana-1-2-2-0/3249/1 "2021-09-16T19:17:10Z")

</div>

Along with @HeinrichApfelmus and @mitchellwrosen, I’m happy to announce the release of [Reactive Banana 1.2.2.0](https://hackage.haskell.org/package/reactive-banana-1.2.2.0). Reactive Banana is a library for functional reactive programming. This release is mostly a maintenance one, though there a few new goodies. See [the changelog](https://github.com/HeinrichApfelmus/reactive-banana/blob/master/reactive-banana/CHANGELOG.md) for more details!

---

<div class="post-metadata">

**Author:** ![mitchellwrosen](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mitchellwrosen/32/1307_2.png) [@mitchellwrosen](https://discourse.haskell.org/u/mitchellwrosen)\
**Post date:** [September 16, 2021, 8:00pm UTC](https://discourse.haskell.org/t/reactive-banana-1-2-2-0/3249/2 "2021-09-16T20:00:13Z")

</div>

I’m happy to see this gem of a library get some love.

If you have ever been curious about what it’s like to write a program using FRP, reactive-banana is the preeminent interface - in any language - to get started.

---

<div class="post-metadata">

**Author:** ![jhrcek](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/jhrcek/32/319_2.png) [@jhrcek](https://discourse.haskell.org/u/jhrcek)\
**Post date:** [September 17, 2021, 4:55am UTC](https://discourse.haskell.org/t/reactive-banana-1-2-2-0/3249/3 "2021-09-17T04:55:59Z")

</div>

You just sparked my curiosity. Until now I was lazy to look into FRP more deeply. Could you please give me few examples what are great applications that are made easier by using FRP compared to some other approach?  
Is it mostly used for GUI programming or are there other domains where it shines?

---

<div class="post-metadata">

**Author:** ![mitchellwrosen](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mitchellwrosen/32/1307_2.png) [@mitchellwrosen](https://discourse.haskell.org/u/mitchellwrosen)\
**Post date:** [September 17, 2021, 3:10pm UTC](https://discourse.haskell.org/t/reactive-banana-1-2-2-0/3249/4 "2021-09-17T15:10:48Z")

</div>

Sure. Yes GUI programming, but also games, simulations, reactive or event-sourced applications… basically, anything loosely involving a possibly-dynamic collection of locally-stateful “entities” that relate to one another, whose implementation might otherwise involve spooky callbacks or other non-compositional abstractions.

And as we all know, or at least suspect, non-compositional programs are doomed to collapse under the weight of their own complexity when they reach a certain size (which, for me anyway, seems to have shrunk to a mere 500loc or so).

---

<div class="post-metadata">

**Author:** ![f-a](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/f-a/32/2740_2.png) [@f-a](https://discourse.haskell.org/u/f-a)\
**Post date:** [September 17, 2021, 4:47pm UTC](https://discourse.haskell.org/t/reactive-banana-1-2-2-0/3249/5 "2021-09-17T16:47:20Z")

</div>

Off the top of my head, I can name more — way more — FRP Haskell frameworks than _games made in Haskell with FRP_. [Allure of the Stars](http://www.allureofthestars.com/play/), [intricacy](http://mbays.freeshell.org/intricacy/), [scroll](https://joeyh.name/code/scroll/), etc. are all `Control.Monad.State` happy.

I only know of Ivan Perez programming real games with FRP («real games» as opposed to «toy examples») and he apparently loves it.  
It is a pity because there seems to be much to be gained but most likely not enough info or tutoring to get people committing to FRP.

---

<div class="post-metadata">

**Author:** ![cdsmith](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/cdsmith/32/1519_2.png) [@cdsmith](https://discourse.haskell.org/u/cdsmith)\
**Post date:** [September 17, 2021, 4:54pm UTC](https://discourse.haskell.org/t/reactive-banana-1-2-2-0/3249/6 "2021-09-17T16:54:24Z")

</div>

> [@mitchellwrosen](#):
>
> If you have ever been curious about what it’s like to write a program using FRP, reactive-banana is the preeminent interface - in any language - to get started.

This comment has me intrigued. I’ve looked into FRP in Haskell, but it’s always been using Reflex. Can someone comment on how Reflex and Reactive Banana compare to each other as implementations of FRP? I’ve found some answers to this, but they mainly focus on Reflex being a more complete implementation, implementing more combinators, more type class instances, more library integrations, and the Dynamic abstraction. This is all in favor of Reflex. I’d particularly like to here about what specific things people prefer about Reactive Banana.

---

<div class="post-metadata">

**Author:** ![mitchellwrosen](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/mitchellwrosen/32/1307_2.png) [@mitchellwrosen](https://discourse.haskell.org/u/mitchellwrosen)\
**Post date:** [September 17, 2021, 5:21pm UTC](https://discourse.haskell.org/t/reactive-banana-1-2-2-0/3249/7 "2021-09-17T17:21:01Z")

</div>

I think your understanding matches mine. Reflex seems like a more mature implementation with many more person-hours invested in optimizations to power larger-scale production web apps.

But note I said reactive-banana offers the preeminent _interface_, not _implementation_ (though its implementation is neat). Its API is clean, concise, and presents the two core FRP abstractions, Event and Behavior, with about as little incidental complexity as possible. Leak-free higher-order FRP is supported with minimal additional machinery.

In summary, reactive-banana is a great way to get comfortable with the essence of FRP. Maybe I wouldn’t board an aircraft powered by bananas and barbed wire (ok, now I’m mixing metaphors).

By the way, Dynamic is just a pair of Behavior with an Event that is known to be the source of its “changes” (in air quotes, because a Behavior whose underlying Event that emits a value “equal” to its previous, for example, would not be noticeable in the semantics of the Behavior). It’s easy to build and use this abstraction with reactive-banana’s API, if you’d like.

---

<div class="post-metadata">

**Author:** ![cdsmith](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/cdsmith/32/1519_2.png) [@cdsmith](https://discourse.haskell.org/u/cdsmith)\
**Post date:** [September 17, 2021, 6:06pm UTC](https://discourse.haskell.org/t/reactive-banana-1-2-2-0/3249/8 "2021-09-17T18:06:16Z")

</div>

Okay, I understand you. I definitely agree that the combinator names in reflex are sometimes bewildering. Why would you call it `ffilter` instead of `filterEvent` or something obvious like that, for instance? But completeness of the API, and especially working with a lot of standard type classes, are also very nice things about the quality of the API.

Yes, I understand about `Dynamic`, but in the end it’s just a phenomenally useful and _simplifying_ combination of `Event` and `Behavior`, so it’s nice to have it around and have combinators that work well with it! My personal opinion is that, despite the trivial implementation, `Dynamic` as a concept is one of the great success stories of the reflex API.