[jarpineh]

Higher level concepts in area so rife with incidental complexity like programming tend to get lost in the details of the implementation. Patterns and abstract concepts like FRP can only be understood by with implementation. Ideas tend to bend before working code, then again with an example app you enthusiastically write for your blog, and then again when someone bases her next project on that (not to mention HN discussions...).

I like to learn thing this way, and not care that much about what the alphabet soup entails. Try to find what is a proper JavaScript MVC framework. And then write the first one yourself ;)

I'm currently reading Clojure Reactive Programming, which differentiates from FRP using another term, CES for Compositional Event Systems, and goes to some length into history of these concepts, like higher order FRP, First Order FRP, Arrowized FRP, and of course Observer pattern and Data Flow programming. There is also Elm's creator's presentation at Strange Loop last year of the same topic:

https://www.youtube.com/watch?v=Agu6jipKfYw

[seanmcdirmid]

I saw Evan's talk at Splash, and while it was good, I think the history is far more complex and nuanced than you can fit into a one hour keynote! When I hear CES I think component-entity systems (also popular in Clojure), but they have been rebranded as entity component systems (to not conflict with event systems), while Rx (Erik Meijer) would be more of where compositional event systems came from.

I have my own system that supports side effects with transactional semantics (see http://research.microsoft.com/en-us/um/people/smcdirm/apx/in... for the latest). I try to keep my bibliography straight since the questions will always be asked (how does your work compare to X?).