Lessons From Facebook: React/Flux

Zach Gardner JavaScript, Opinion, Technology Snapshot 5 Comments


This blog post will cover Facebook’s React JavaScript library and Flux application architecture paradigm. It is a summary of the presentation I presented at DevCon 5 on 7/22/2015 in NYC.


All the buzz on Hacker News these first few months of 2015 has been centered around Facebook’s React library and Flux paradigm. I got the itch to try them out on a sample project, and learned a few things along the way. By no means am I a React or Flux expert. I’m still in the process of figuring out everything these two can provide to front end developers.

This blog post, as well as the presentation I’m giving at DevCon 5, is the culmination of my experiences using these two, and where I feel they fit into modern front end web development.


A lot of the JavaScript applications we help write here at Keyhole are for large companies with very big teams responsible for developing a product. They range from financial institutions to health care companies, so they tend to have very specific goals in mind for the applications we help them write. That lens is what I often look through when judging new libraries or frameworks.

The most common goal I’ve come across in the applications we help write at Keyhole is maintainability. The applications we help write are expected to live for five, 10, or even 15 years after they go to production. They need to be written in such a way that a support team can come in once active development is done, and keep the product up and running for as long as necessary.

The experience I’ve had with React leads me to believe that Facebook wrote it with a different set of goals in mind. There are a lot of opinions on what that goal exactly is, so I’ll pull what I think they are straight from the horse’s mouth:

Just the UI: Lots of people use React as the V in MVC.
Virtual DOM: React abstracts away the DOM from you, giving a simpler programming model and better performance…
Data Flow: React implements one-way reactive data flow…

Those three points can be boiled down to performance. Facebook lives and dies by how quickly their web app loads. Longer load times leads to unhappy users, and unhappy users are a sub-optimal target for ads, and fewer ad clicks lead to less revenue. Getting new features out there that are snappy is the goal to keep the gravy train flowing.

The bias I have in favor of maintainability is something I kept in mind when evaluating React and Flux. We may have different goals, but I can completely understand where Facebook is coming from with React. The question you’re probably wondering is, “What about Flux?”

React vs Flux

Up to this point I haven’t really defined what React and Flux actually are. In as simple terms as I can come up with, Flux is an application architecture paradigm that recommends a unidirectional application flow, and React is the JavaScript implementation of Flux.

These two were born out of Facebook’s attempt to use traditional MVC to develop their JavaScript web application. The MVC diagram that is most commonly used to describe its origin is the following:

From InfoQ

Trying to maintain an application with that kind of complicated interaction matrix is a nightmare. The engineers at Facebook tried to rethink the entire MVC paradigm, and came up with something like this:

From InfoQ

The flow of the application is unidirectional. The application moves from the action to the dispatcher to a store to a view, then recursively back to an action. Maintaining and debugging an application written in that fashion is infinitely easier than what was described above.

See Also:  Spring Boot and React: Happily Ever After

This is the most common motivation I’ve seen for why React and Flux were invented. After several hours of research, I came up with the following list (which lacks citations, sorry to my English 102 professor) of all the most common motivations I’ve seen for React and Flux:

  1. DOM writes are expensive.
  2. Independent widgets have unpredictable flows.
  3. In large applications written by developers of differing levels of ability, keeping the code consistent and maintainable is difficult.

These are concerns I’ve had with any application I’ve written. Although I don’t know it from end to end, I do not believe that React and Flux are a panacea for those concerns.

DOM writes are expensive

I’ve seen this concern come up when developers talk about pieces of JavaScript that cause a large number of reflows and repaints. Rather than allowing a component to interact with the DOM at any time it wants, React’s Virtual DOM ensures that updates to the DOM are kept to a minimum. The Virtual DOM helps mitigate any mistakes a developer may make by only writing deltas to the DOM when a change occurs.

The graphic I’ve seen most used to illustrate this point comes from when Khan academy switched from Backbone to React. This graphic shows how React (bottom left) and Backbone (bottom right) behave when a computationally expensive operation (converting raw text to a fancy math equation)  is performed:

Note that the Backbone version (bottom right) is choppy, whereas the React version (bottom left) is smooth. This is because React is only persisting the deltas on each keystroke to the DOM, but Backbone is rendering everything from scratch on a change.

I am in total agreement that trying to figure out how to do that efficiently in Backbone would be a challenge. I agree that in this situation I would use React for my view layer instead of Backbone. What I disagree with is that this means I should use React for every view everywhere. I have never worked on an application (nor have I heard of an application we’ve worked on at Keyhole) that has a piece that has a requirement for this kind of update. It seems an exception to the normal functionality we help our clients develop. Using React in places like this makes sense, but I can’t at this time see how this exception should make me completely rethink the rule of using Backbone.View as my standard view.

Independent widgets have unpredictable flows

Just as a reminder, this is the graphic I’ve seen that most commonly accompanies this concern:

From InfoQ

If an application looks like this, I am in total agreement that its flow is going to be a major concern. No argument there.

The argument I have is that in an application like that flow is not the primary concern. That kind of application is simply not maintainable. Adding additional pieces has to be done either by an expert that knows every sharp edge of the troublesome application, or has to be done with duct tape and prayer. If your application looks like the diagram above, flow is the least of your worries.

A maintainable way to write an application is the following:



An action comes in, and is handled by one controller. The controller takes care of the orchestration of the event. The view is responsible for displaying HTML to the user. The model is responsible for being the mechanism by which communication with a server can be performed. The controller can delegate more specific aspects of functionality to subordinate controllers. Maintaining the supervisor/subordinate controller relationship bakes in the notion of application flow.

This is the pattern that is used in almost every server-side language I know of. Every maintainable JavaScript application I know of uses some derivation of this pattern. Interestingly enough, Flux is pretty close to this pattern as well. This is the graphic I showed above:

See Also:  Machine Learning: The Time is Now!

From InfoQ

The dispatcher (supervisor controller) can talk to other dispatchers (subordinate controllers). The action data is stored in a store (model/collection). The action is eventually written to the view (view). This flow then repeats in exactly the same fashion as the MVC diagram above.

On this point I agree in principle with Facebook’s Flux team. I disagree, however, that it takes a completely new library to achieve this pattern. All you have to do to achieve the MVC pattern I showed above in Backbone is to create a Backbone.Controller class, let it know about other Backbone.Controllers, give it a member variable for view, and presto-chango you have the start of a maintainable JavaScript MVC application.

In large applications written by developers of differing levels of ability, keeping the code consistent and maintainable is difficult

Yes, I agree.

Seriously, yes.

I mean it, I actually agree. If I were the lead architect for a large JavaScript project with developers of differing skill levels, I would seriously consider using React.

Thankfully I’m not. 🙂 Most of the projects I’ve consulted on had very small front end teams with above-average JavaScript skills. The more successful of those chose libraries and frameworks that allowed the skills of the team to shine without being hampered by constraints or patterns not of their choosing. I enjoy JavaScript because I know its strengths and pitfalls, and I make a conscious effort to avoid those pitfalls. Having the freedom to make stupid mistakes and choosing not to make them is better for me than limiting the amazing things I can do at the cost of never being able to make a mistake.

If I had a small team of JavaScript developers that were really strong with the language, I feel something like React would hamper rather than strengthen the team. Backbone in that case would be a better choice so the team could developer their own patterns and play it to their strengths. I can, however, see how a large team may benefit from the uniformity that React provides. The same thing could be said of any other JavaScript framework, so this is still an area that React is not the de facto standard.

Code Introduction

I created a GitHub repo for a React implementation of Grokola, our Q&A wiki platform. It was originally written in Backbone, so I wanted to see what a purely React implementation of it would look like. I learned more doing this than I ever having when using the typical To Do application approach to learning a new framework or library.

I’ll save my thoughts on how the coding went for my DevCon 5 presentation. So if you’ve liked it my blog so far, consider coming to see me yammer away for an hour.


Facebook’s React/Flux is an interesting take on the MVC paradigm in JavaScript. While I disagree with the results, I understand where Facebook is coming from with these two pieces of the front end puzzle. I still think that an MVC Backbone application is what I would choose for a small team of strong JavaScript developers.

But if I had to give a recommendation for a large team with varying levels of JavaScript skill, then React would be something I would consider.

— Zach Gardner, [email protected]

Comments 5

  1. Zach,

    The virtual DOM makes me think of HTML5 web component shadow DOM, how does React match up with the Web Component spec, if at all.


    1. Post


      Great question. If you checkout the render method of solution.jsx, you’ll see what it looks like. Some notable differences:

      1. File names need to be .jsx, and the JSX converter needs to be included on the page. If you don’t use JSX, you end up with a giant mess of JS to express their Virtual DOM.
      2. A tag’s class attribute is renamed to “className.”
      3. Event listeners are bound by doing the old school onClick=”this._functionName” convention

      The templating is included as part of the Virtual DOM, so there is no opportunity to use whatever your favorite templating library is.

  2. This was an interesting read, but I wanted to pick a few bones with you:

    React is NOT an implementation of Flux. They are completely separate things.

    Your React app DOES NOT implement the Flux pattern whatsoever.

    Again, I really appreciate when people, instead of jumping on the hype train, take a critical look at something, but your takeaways aren’t really going to be useful if you haven’t REALLY grokked what React and/or Flux are all about.

    I don’t work for Facebook, and I just started playing around with React myself. However, if you wanted to utilize Flux, you will either need to implement it yourself, or use one of the numerous implementations out there:


    There are boatloads more…

    React/Flux is also, as far as I know, not considered MVC. Semantics, yes, but I think it’s an important distinction to make.

    I find it interesting you mention “This is the pattern that is used in almost every server-side language I know of.” because your right. Server side code is generally ‘immediate mode’ and a new page is created every single request. This greatly simplifies the code.

    Client side code has generally been ‘retained mode’. The DOM has state, and you read and write that state from the DOM (in addition to keeping it somewhere else many times). The idea of virtual dom is to present an immediate mode interface, similar to the server. It handles the actuality of rendering client side in the retained-mode DOM.

    Additionally, for me, the neat thing about React and virtual dom is how you conceptualize an app. Your app is a function of props and state. You don’t store anything in the DOM, it is simply an implementation detail (as React-Native demonstrates).

    For me, this idea that, through creating components you describe what you want your app to look like, and your virtual dom implementation takes care of making sure the DOM keeps up, is powerful.

    That being said, an even more functionally/reactively pure implementation of this idea is Cycle.js (https://github.com/staltz/cycle), which looks really interesting and is something I want to take some time out to explore. The author of the library also has his own takedown of React, which I found very well thought out: http://staltz.com/dont-react/.

    Basically, I agree that React, and particularly Flux, are one big giant ball of hype. React did a wonderful job of introducing the idea of a ‘virtual-dom’, and I think the idea is great. Flux, on the other hand, is less groundbreaking, and its really just a fancy name for a simple idea (that has probably been called something else before).

    Your process and article seem biased from the start, and I don’t think you’ve given the concepts their due consideration. I don’t think you should stop writing your apps in backbone, but I think the reasoning behind your dismissal of React is flawed.

    Lastly, I think there is a hint of elitism surrounding the whole “strong developers” bit.

    I’m not an expert of logical fallacies, but it seems your saying:
    Strong javascript developers can code well structured apps in backbone, therefore since React offers a simpler programming model (etc), it is only useful for apps which are maintained by teams which include “weak” developers.

    Anyway, I’ve spent to much time on this already. My intention wasn’t to be mean or snappy, so I’m sorry if I came across that way.

    1. Post


      Thank you very much for the feedback! I appreciate the time you spent figuring out what I need to clarify, and what I need to change completely. My presentation is still in a state of flux, pun intended, so I’m open to whatever feedback I can get.

    2. “I find it interesting you mention “This is the pattern that is used in almost every server-side language I know of.” because your right. Server side code is generally ‘immediate mode’ and a new page is created every single request. This greatly simplifies the code.”

      Agree on this. The kind of “event-pinball-hell” scenario that Facebook initially describes doesnt really happen when everything is broken up by a page serve. OTOH if one is in the Client side domain then the potential for things to get to the state where you trigger complex, interdependent interactions is much more real. Two way data binding (in Angular 1 or anywhere else) can make this a fairly common situation to run into.

What Do You Think?