Why we are switching to Redux (and sticking with React too)
This post originally appeared in my employer’s blog on March 1st, 2016. I reposted here because the original URL is down now.
Abstract
This is the story of a one-year long journey taken by a professional Javascript development team. Why we’ve changed our beloved, well-established and confortable stack based on Backbone, require.js and Grunt (remember those old friends?) for the newer, fancier new kids on the block: React, Redux, Babel and webpack.
Oh, and all this while still coding and delivering Javascript applications for customers. Speak about Javascript fatigue.
Stage 0: Rewhat?
Let’s be honest, our first reaction when we first saw React -and more specifically its JSX syntax- around November 2014 was exactly the same everyone else was having at the time:
It’s funny how certain old, deep rooted habits quietly go away in a matter of weeks. Everyone is loving JSX and React now. They, those Facebook punks were right. We, the separate-file-with-hacky-syntax-template-engine people were wrong.
We see it clear now. This is not about giving some weak scripting and interpolation skills to HTML, it’s the other way around. It’s about supercharging your Javascript code with DOM manipulation weapons (for both HTML and SVG). That’s what React with JSX does. And once you get used to it and find yourself in the zone, you simply can’t go back. There’s life after jQuery.
Was it hard to learn or to begin with? There was a learning curve indeed. But the fact that React only dealt with the View layer made it somewhat easier. Less things to learn at once, even when Flux was mixed in. Only three new concepts to absorb -Component, Store, Action- and a relatively small API surface at the time. We produced some ugly, not at all standard React code from time to time, but we were still productive and refactoring and improving was easy as our React knowledge grew. We just had to learn and internalize the React way, as we had learned the Backbone way before.
React was a quick sell for almost everyone, but the same can’t be honestly said about Flux. At that time it was more an abstract idea -a conference video, some posts here and there- than a real framework upon which to build your apps. For many of us, however, the concept of Actions instantly clicked. The idea behind it was powerful and thought-provoking: everything that may cause a change to your app’s state should be defined and processed in a standard, explicit way. All of a sudden things like complete logging and undo/redo was relatively easy to implement. Think about it, we didn’t even use the concept of web application state back then: it was scattered among models, collections, views and data -* attributes in our Backbone applications.
It’s really a big idea for web development. Yes, we know the Command pattern has been around for more than 20 years, but this version is a pure data construction, not an OOP artifact. Much easier indeed, which leads to quicker and wider adoption. I think we produce better software with React and Flux.
Stage 1: Standard Flux sucks. We can do better. Inventing RedFlow
As everyone else seemed to be doing, we cherry picked what we liked most about Flux and rolled out or own version, Redflow. It was heavily inspired by Om, and Clojure in a broader sense. That’s why we chose mori.js -instead of the then just published Immutable.js- for our immutability needs and built our atom around it. The whole application state is a big immutable hash map.
We used singleton Stores to handle actions and provide query methods for components to access specific parts of the atom, and got rid of the paradoxical change event emitted by the Stores by listening to changes on the data itself from the root React component. Whenever the atom is changed in any way, just render the whole app. Add some shouldComponentUpdate spices here and there if needed and you’re done.
I think it worked pretty good. We were able to deliver applications that were performant and slick, both for web and mobile, learned some new concepts, improved our functional programming thinking and embraced ES2015 with Babel along the way. Not bad for less than a year.
Stage 2: Build or Buy
Unfortunately, we didn’t take into account a key issue: the Javascript ecosystem grows and evolves much faster than we do. As we were using Redflow to build real customer work, the rest of the world was creating a whole family of React related libraries, from routers to component sets to immutable structures to hot code replacement plugins. In just ten months we started to feel we were already lagging behind mainstream React.
It was clear we had two choices: either to improve, upgrade (and document!) our homemade Flux implementation, or choose some existing framework. Nothing new under the sun: a classic, recurring problem in software development. Review what you have, what you need, and what’s available there. So we started by raising issues on our own framework.
Something that was, and still is, hard to achieve with Redflow and standard Flux in general was server-side rendering, which was becoming the new Holy Grail of web development: SEO-friendly, isomorphic, universal, cosmic Javascript applications. We wanted a sip too, and getting it to work involved some pretty ugly code on the Node.js server, with implications for the client side as well.
Our choice of mori.js for immutability caused some friction for newcomers to the framework because of its Clojurish syntax, and made it harder to integrate promising libraries that worked with plain old Javascript data structures out of the box. We knew many of the cool things we were seeing out there would have to be done, or at least carefully integrated, by ourselves.
On top of that, we were watching a clear winner emerging from the Cold War between competing Flux implementations: Redux. Designed by the same guy who had knocked our heads off with his live, hot loading, time travelling developer experience session at ReactConf in Paris.
Stage 4: Evaluating Redux
What instantly got my attention from Redux was its beautiful documentation and the rationale behind the library. Sometimes it feels like reading an essay. It also had a nice set of examples, some of them of medium complexity, which is not common at all.
In addition, the idea of putting Flux on an even stricter diet with plain Javascript functions or reducers acting as Flux Stores was simply too good to ignore, and the most original by far. The object-oriented singleton Flux Store transformed into a simple function, that you can run on the backend with ease. It’s brilliant.
It also kept the main idea we already had with Redflow: a single state object for the whole application, which in Redux is simply called the store. It had also removed the ugly change event in Flux stores like we had. And it already provided you with mechanisms to connect your React components to that atom or store, with much more elegant and future-proof solutions than React Mixins or our own change listener. Yep, it keeps the now famous switch statement, but we can definitely live with that.
Redux spreads rapidly, with dozens of blog posts, examples, boilerplates and side projects spawning every week. Having the best possible development and debugging experience seems to be core part of the ecosystem, and for a team like ours that it’s a huge selling point.
Stage 5: Conclusion
Redux is now our official framework at Redradix. It keeps and improves the very same ideas we had developed on our own, embraces a coding style that had already been adopted, and allows our team to focus more on customer problems and get away from infrastructure issues. We’re now using the same tools other people are using to create similar products, so hopefully we’ll be able to find and share open source solutions or techniques for day to day small problems within a much bigger community.
We’re developing our base app, or in-house boilerplate, with small examples we call recipes demonstrating specific use cases we’re likely to find on most real projects: authentication, REST APIs, WebSockets, drag and drop, and so on. This should improve even more our productivity on new projects from now on.
Redux does not depend on React at all. But there’s no way we’re abandoning React now. For what I’ve personally seen of Angular 2, it has taken the wrong approach - at least for my current taste. They got the Virtual DOM from React but decided to leave the second weapon of React behind: that you write Javascript, no longer HTML applications. We don’t really need to learn again how to iterate a list of items to produce an HTML list with yet another syntax. We know how to do it with Array.map. We use the very same principles and code for UI generation that we’re using for building a complex backend with Node.js.
Finally, the fact that React is powering one of the world’s busiest and most demanding sites in the world like Facebook gives us, and our customers, confidence in that it’s a valid and proven technology. The icing on the cake is React Native, which looks like a really promising technology for creating native mobile apps, while allowing us to reuse our day to day experience with React and our best Javascript knowledge for a completely different platform.
React, and Redux, are going to stay.
(Fingers crossed) At least for another year. ;)
