Today we see how web applications grow up from traditional multi-page sites (where all business logic was implemented on the server side) to single-page or ajax-driven apps. If you have ever read Reactive Manifesto you should understand the reasons why nowadays web-development goes asynchronious and event-driven way. We spen a lot of time to provide responsive, fast and usable design. But as developers we want resilient, scalable, declarative software.
Event-driven architecture allows us to reach scalability, resiliency and responsivness. But events are not declarative. They're not clean, unpredictive, action's result depends on app's state...
It's hard to combine and compose events, cause of these asynchronious nature. But it's all we have. From the start of all, the only way to act with DOM was events, and that's the problem we presume. Most of nowadays frameworks provide solutions for every level of deep troubles of events. jQuery made them crossbrowser, some frameworks tried kick them out by two-side data-binging, some frameworks tried to wrap events into declarative components.
One of the main probles of asynchronious programming is accidental complexity. Simple apps turns to the tangled web of states, when we try to compose events wich change state.
It goes harder when we realize that asynchronious shows itself not only on events tier. Offline, non-blocking multithreadness (web-workers), client-server replication - them all partially cases of asynchronious. With ECMA6 we will recieve object observations which async too. Complexity of state grows with async data sources. When handlers change state - we create a new segment of variants in states tree.
We used to ignore states that doesn't mean anything in out application at current time. But it's not scalable model. When we will want to add some concurent event, we can face to situation when we need to debug all probable states. It makes life of developer pretty hard.
Different languages and enviroments provides different solutions of common problems. In functional languages like Clojure or Scala you will find immutable data structures and software transaction memory (STM). It's good way, but we have not it on JavaScript. Sure we can use ClojureScript, or just Mori or Immutable.js and use persistent-data types. It will partially solve some troubles with state. React provides Virtual DOM and components hieracrchy. It's really goood solution, but despite that React says that it;s not a framework - it's framework. It requires definitively background, so you can't take ready tangled spagetthi-code jQuery app and say "hey, guys! Let's add some React.js into our app" and it will work.
One of the common solutions for JavaScript is the implementation of functional reactive programming ideas. FRP suggest that you will use pure functional approach. In terms of FRP there is no events. There is a source of data which partial case events are.
Main difference between traditional event driven programming and FRP are pure functions as stream handlers, changes propagation as mechanism of state updating. If you're using React - you can find out that idea of Virtual DOM is pretty much looks like functional approach state managment. It's not suprising because really functional approach will make you construct your apps in way where all state changes will be changes of view. There is a realy good stack: React + ClojureScript + Javelin, where all stores in React are Cells of Javelin
