tatiyants.com A Second Look at Facebook's React

When I first heard about Facebook’s React library, I came away unimpressed. First, it came from Facebook (groan!). Second, aside from claims of really fast rendering, I didn’t see what the big deal was. And finally, it seemed like React’s proponents went out of their way to bash current leaders, namely Angular and Ember.

Well, I was (and still am) a huge fan of Angular. I’ve made the necessary (and significant) time investment to learn it and can now do pretty much whatever I need with it. Therefore, constantly hearing about how some wet-behind-the-ears framework from Facebook (groan!) was so much better than my beloved Angular did nothing to endear me to it.

And so, as is my custom, I assumed that React was a flash-in-the-pan, here-today-gone-tomorrow kind of framework and decided to simply ignore it until that happened. This was a fine plan except for one flaw: React refused to go away. On the contrary, it seemed like every other day someone was signing its praises.

Since ignoring React was getting me nowhere, I decided to give in and take a closer look. Here’s what I found.

tldr; React is a very impressive library for developing fast, component-based UIs. That said, it’s not a full framework and will likely require additional libraries in order to build large apps.

What Is This React You Speak Of?

React is a JavaScript library designed around component-based UIs and one-way data flow. It’s simple, internally consistent, and theoretically sound. Oh, and it’s very, very fast.

Component Driven UI

React is all about components. Its creators firmly believe in components as the right way to do UI and they’ve built a framework which goes out of its way to push the developer in that direction.

I couldn’t agree more with this approach. Components are a really good way to structure application UI for two reasons. First, it’s much easier to reason about (and build and debug) an application when you can restrict your mental model to a specific component within it.

Second, a component-centric mindset forces you to look for and extract common patterns used in your application into reusable pieces. Instead of thinking “To implement a table filter, I’ll just add a few tags to my template”, you think “To implement a table filter, I’ll add a new component to my app and drop that component into my template”.

By the way, unless component orientation is front and center in your framework, you won’t think this way. In fact, unless your framework not only encourages, but makes it easy to create components, you won’t. For example, Angular definitely has the concept of components in the form of directives. This is great, except that creating directives is not trivial.

To create directives you need to have a deep understanding of how Angular’s runtime is managed (compiling vs linking), how scope inheritance works (isolated vs. parent vs. child), and possibly what transclusion is. And so, many Angular devs simply ignore directives and use templates instead (I certainly was in this category until fairly recently).

Immutability

React is also all about immutability. Data flow between components is one-way and immutable by default. There’s a special ceremony around mutating state.

Again, this is a fantastic idea. Making state mutations so explicit and intentional forces the developer to really think about the flow of data within the app. It encourages eliminating needless state (such as creating separate variables to keep track of list counts) and makes bugs due to state inconsistencies between different parts of the app less likely.

Ok, So Can You Build Apps With It?

It’s important to remember that React (unlike Angular or Ember) is not a full framework. It is about the UI (or, as its website puts it “React is the V in MVC”). It gives you everything you need to create and render components, but it is missing a few things:

module system
routing
model management
server access

There are many options for each of these available on React’s Complementary Tools page.

Another thing to consider is testing. Facebook has its own test runner called Jest, which makes it easier to test React components. I haven’t tried it yet, but it does look similar to Angular’s Karma (which by the way is an excellent test runner).

Integration With Angular

Looking at the list of missing items, one can’t help but notice that Angular has support for all of these. Given that, one can’t help but wonder whether Angular and React can be combined.

It turns out that it’s at least possible to combine React and Angular. It boils down to calling React’s renderComponent() method from Angular directive’s $watch() method.

I haven’t made up my mind about whether this is a good idea. After all, you still need to go through the hassle of creating directives, and you now have to also figure out what belongs in that directive and what belongs in React’s component.

React or Angular

So, should Angular devs switch to React? It’s difficult for me to answer this question because, while I understand where React excels, I don’t know what the warts are. I don’t know what it’s like to write large apps in React, what it’s like to debug weird issues in React.

I suspect that skilled Angular devs can get by just fine with Angular. If you know what you’re doing with Angular, you can get a lot of mileage out of it. Unless you have some crazy performance problem which requires a rewrite, there may not be enough of a reason to switch.

On the other hand, new Angular devs could well benefit from taking a closer look at React. It does a better job than Angular in forcing you to do the right thing (whether it is organizing your application in terms of components or forcing you to manage state better).

Final Thought

React is a great library for creating UI. It solves some very complex problems in a clever and elegant way. It strongly encourages good habits. It is simple to grok.

It’s also true that React doesn’t give you everything you need to build apps. You need to make choices about a set of supporting technologies before you can really get going with it. Some may really like this best-of-breed approach, while others prefer a single, comprehensive framework.

I think that React’s adoption may be aided by a comprehensive framework built around it (à la Marionette). Facebook seems to be moving in that direction with Flux, but nothing concrete has materialized as of yet.

A Second Look at Facebook’s React