Saving Time & Staying Sane? Pros & Cons of React.js

Kent William Innholt 6 min read

When I began working for m›PATH earlier this year, one of the exciting early tasks was putting together our new web app tech stack, which currently consists of Ruby/Sinatra, Sass/Autoprefixer, CoffeeScript—and React.js.

We're building an ambitious new web app, where the UI complexity represents most of the app's complexity overall. It includes a tremendous amount of UI widgets as well as a lot rules on what-to-show-when. This is exactly the sort of situation React.js was built to simplify.

Overall, we've had a great experience using React.js. In my experience, the biggest benefit of the framework is how it effectively makes obsolete a number of front-end concerns and problem domains.

Big win: Tighter coupling of markup and behavior

In React.js, markup and JavaScript behavior are defined together in the same file, and event handling is defined directly on the relevant DOM nodes—similarly to for instance Angular (as well as DHTML for those who remember).

Here's a simple example:

ToggleButton = React.createClass
  getInitialState: ->
    active: false

  toggle: ->
    @setState active: not

  render: ->
      className: 'active' if
      onClick: @toggle

So, how does this make our life easier?

Jury's still out: CSS lives outside React.js

Given the maintenance wins outlined above, the natural next step might be to look at whether a component's CSS could also live together with the component.

In my experience, the number of lines of CSS often outnumber the JavaScript/markup two or three to one, so I'm not sure if it would be a great idea to include the CSS in the component file itself.

Having said that, there are “architecture smells” to the current solution:

In other words, I wonder what gains could be had from making CSS a more integrated part of React.js.

Big win: Cascading updates and functional thinking

React.js invites us to think about our web app's UI as a tree where each level decides how to delegate responsibilities down to its branches.

The mental model is beautifully simple: A component is basically a function that receives a set of @props (properties) and returns a description of how to render itself given those properties and its internal @state. As long as we stay true to this intended cascading architecture, we are guaranteed that the application is always up-to-date. React.js relieves us of the need to worry about updating the DOM.

When reasoning about your app, you can imagine that the entire application re-renders every time there is a change in state—whenever the user clicks on something, or new data is retrieved from the back end.

(In practice, React is a lot more efficient than that, performing a diff operation behind the scenes to avoid redrawing more than necessary.)

Other JavaScript frameworks like AngularJS and Ember.js provide similar mechanisms, but React's virtual DOM approach appears to have performance benefits as UIs grow more complex.

Jury's still out: Verbose propagation

In React.js, by default the children of a component know nothing about their parent. The parent has to explicitly tell them anything they need to know.

For example, imagine that we have an application with a comment form, and this form needs to know about the current user's login state:

Application = React.createClass
  render: ->
      user: Users.getCurrentUser()

Article = React.createClass
  render: ->
    CommentForm user: @props.user

This way of propagating knowledge though your application seems simple enough early on, but it can become a bit verbose and error-prone as the application grows. In my experience, the leaf node (CommentForm in the example) might easily appear 5–10 levels deep in the UI hierarchy, which means that we might end up with 5–10 instances of user: @props.user strewn out over our code base.

Often, there is more than just one piece of knowledge that need to get propagated out in this manner, and we end up with the following concerns:

To avoid this, we might reach for React's built-in @transferPropsTo method. It can simplify the surface propagation for us, making this:

render: ->
    user: @props.user
    applicationColor: @props.applicationColor
    articleId: @props.articleId


render: ->
  @transferPropsTo CommentForm()

However, this approach comes with its own drawbacks:

As of now, propagating props explicitly might be the lesser of evils. Luckily, it seems the React team is aware of the issue and looking at ways to resolve it.

Big win: Thinking in components

The push towards UIs that are reusable and composable has turned out to be a major productivity win for us.

Of course, this is not an idea unique to React—we see the same idea practically all over the place: web components, Ember, Angular, Backbone and other frameworks all provide similar abstractions.

Suffice it to say that React makes it easy to take advantage of composability. For example, in our current application, we have these components:

When the need came up to implement a custom drop down similar to a <select>, all we had to do was something like this:

Form.SelectDropdown = React.createClass
  render: ->
      className: 'form-select-dropdown'
      children: @transferPropsTo Form.RadioSet()

The only thing that remained was to add special styles for the form-select-dropdown class—and we were done.

Wrapping up

That's it! What has been your experience with React? Let me know in the comments!

If you want more updates from me, I have an RSS feed and a Twitter profile, and if you'd like to get in touch—m›PATH is hiring—you can reach me at kentwilliam [ at ] gmail [ dot ] com.

Take care,
/Kent William