I don&#x27;t fully understand the argument against FRP here.  It seems like the author has passed on FRP in favor of coroutine-like asynchronous programming.  I don&#x27;t view one as replacement for the other, but as different layers of an asynchronous programming system.  Coroutines are great for async and imperative tasks, while FRP is great for async and functional tasks with persistent data.  My own FRP implementation [0] in Guile Scheme is built <i>on top of</i> a coroutine implementation [1], which in turn is built on top of Guile&#x27;s first-class delimited continuations. [2]<p>That said, the author specifically talks about RxJs and Bacon.js, both of which have two major problems for me:<p>1) They don&#x27;t satisfy the closure property.  They both have two fundamental data types: event streams and properties.  Certain combinators expect streams, and others expect properties.  Compare this with API&#x27;s like Elm&#x27;s which just have a single type: the signal.  The closure property is satisfied here and programming is much more pleasant.<p>2) They both deal with stream&#x2F;property life cycles.  Objects need to explicitly unsubscribe from other objects, and streams may have a beginning and an end (i.e. they may be marked as having no value or marked as being done producing values).  I think this is a mistake that complicates the API.  FRP objects should <i>always</i> have a value, have no notion of being done, and not require the equivalent of manual memory management to clean up.  My Scheme implementation uses weak references to automatically unsubscribe signals when they are no longer referenced, which is basically only during development when changing things at the REPL.  Bacon and RxJS can&#x27;t do something like this because (and correct me if I&#x27;m wrong), no JS standard prior to ES6 has weak data structures.  Anyway, after all the hacking, the final program has a static signal graph, just like Elm, which I think is the right way to do things.<p>[0] <a href="https:&#x2F;&#x2F;git.dthompson.us&#x2F;sly.git&#x2F;blob&#x2F;HEAD:&#x2F;sly&#x2F;signal.scm" rel="nofollow">https:&#x2F;&#x2F;git.dthompson.us&#x2F;sly.git&#x2F;blob&#x2F;HEAD:&#x2F;sly&#x2F;signal.scm</a><p>[1] <a href="https:&#x2F;&#x2F;git.dthompson.us&#x2F;sly.git&#x2F;blob&#x2F;HEAD:&#x2F;sly&#x2F;coroutine.scm" rel="nofollow">https:&#x2F;&#x2F;git.dthompson.us&#x2F;sly.git&#x2F;blob&#x2F;HEAD:&#x2F;sly&#x2F;coroutine.sc...</a><p>[2] <a href="https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;guile&#x2F;manual&#x2F;html_node&#x2F;Prompts.html" rel="nofollow">https:&#x2F;&#x2F;www.gnu.org&#x2F;software&#x2F;guile&#x2F;manual&#x2F;html_node&#x2F;Prompts....</a>