In the last year you could spot a big change in the way javascript applications were built: The javascript world is moving away from unpredictable mutable state architecture to a more predictable immutable application architecture.

With frameworks like backbone the common approach was to keep your data and your view in sync by listening manually on some dom change events. This was kind of error prone and had too much boilerplate code. Angular came and fixed this by providing an automated process for this: two-way bindings.

But now things are moving in a different direction: With React and React tooling like redux it’s now easier to keep things immutable than to do it the mutable way. When using mutable state your application cannot take advantage of other tooling like live reloading, so you really want to keep things immutable.

Libraries taking advantage of the functional programming paradigm, like redux, are easier to extend because pure functions compose well. Functional libraries usually have fewer lines of code and thus fewer possible bugs and less complexity. Just take a look at the redux source code, you can read through the code in 15 minutes because there is just not much code.

Composability and less complexity means tooling can reach a far higher quality. Live reloading and time-travel-debugging are things you cannot do easily in imperative designed applications because side effects get into the way[0].

Keep in mind that frameworks and libraries come and go. It’s likely that React will not be the hottest technology in a year or two. But the thing is that the functional paradigm , which is pushed by React and other functional libraries, will stay. It’s just that the tooling is so good, that there is no way back. Once you have used live reloading and time-travel-debugging you will not want to go back. It really enhances your productivity. Interactive software development is the future[1]. Also keep in mind that functional code is usually less bug-prone and easier to understand[2].


Even if React is not the hot thing in the future, the philosophy of it, functional programming, is here to stay.

When you are new to functional programming I suggest taking a look at haskell. I can recommend “Learn You a Haskell for Great Good!”, it’s available online for free here. It’s worth learning haskell for the profound insights you get about programming even if you will never use haskell for anything serious. Also check out this article, which shows how functional programming is used in real world code.

Thanks for reading :) Follow me on twitter if you’re interested in more of this stuff!

[0] Technically it’s possible, but it’s hard to do and because of side effects not possible everywhere.

[1] Take a look Bret Victors homepage. It’s full of examples on interactive programming. Make sure you check out his talk “Inventing on Principle”.

[2] But this is not the reason why the frontend world is moving into that direction. Functional programming is nothing new. We would be using a more functional architecture for a long time now when less bug-prone and easier to understand code was the reason for the rise of functional design. The tools are the reason, and the less bug-prone and simplified code is a sideffect.