Why React

By Gil M.

Jan 30, 2016

React is a new(ish) front-end library from Facebook that aims to provide a simpler UI programming model with some performance gains.

Library vs. Framework

I don’t know of any universally agreed upon definition of a library vs.
a framework but to me a piece of code is a library if my code calls
. This piece of code becomes a framework when it controls the
execution thread and therefore it calls my code.

A library typically provides more control at the cost of more
boilerplate and a framework is the other way around, less boilerplate
for the cost of less control.

Simpler Programming Model

So to understand React’s claim of a simple programming model we need to
go back just a bit to the early days of jQuery… with jQuery we have to
manually and repeatedly sync the state of the DOM and the state of the
memory. jQuery according to the above definition is a library that
provides easy DOM query and manipulation abstractions and works across
browsers — this is great and effective but results in quite a bit of

Then came Angular… Angular promotes the notion of two-way binding in
which we teach the framework via directives how to sync the DOM and the
memory state automatically. This pretty much solved the boilerplate
issue as we don’t need to copy stuff back and forth between memory and
DOM anymore. However Angular is not a library like jQuery but a
framework. This means that we have less control over what gets called
when, in other words we need to know the inner workings of Angular
pretty well to avoid performance issues and hard to find bugs.

And then came React… React tries to tackle these issues with
Angular by providing a “simpler programming model” i.e. a library rather
than a framework. So how do we create a simple library on the one hand
and still avoid boilerplate on the other? This is where the React magic
kicks in. The gist of React is that the DOM is a pure function of the
state, in other words you simply ask React to render the entire app from
top to bottom on each and every change to the state. Clicked a button,
render the whole thing again, got a callback from the server with new
data, render the whole thing again, simple!

Simple but of course this sounds awfully expensive. The innovative thing
React brings to the table is that rendering doesn’t happen “for real”,
React simply renders to a virtual DOM in memory. This is not an
expensive operation since Javascript is very fast. Now that React knows
how the resulting DOM should look like it simply runs sort of a diff
between the actual DOM and the virtual DOM to discover only those places
that actually changed and these get rendered “for real”. Presto, simple
programming model and boilerplate free — good stuff!

Performance Gains

Coupled with the wonderful Immutable.js library, React
is able to diff virtual and actual DOMs even more efficiently and
quickly. For instance if the app state is captured with Immutable.js
data structures, a diff is really just a simple matter of comparing
pointers which is of course fast. If you want to know why that is, I
suggest reading the Immutable.js docs and also some Clojure
 about the subject, immutable data structures are a really fascinating programming concept regardless of React.

So why use React?

  • Easier to test

  By promoting a pure functional style, React and it’s leading app
  frameworks are easy to unit test, most business logic is captured in
  functions that accept a state and an action and return a new state.
  Since rendering is just a pure function of the state, we don’t need to
  mock the browser, no need to inject dependencies… easy.

  • Enforces single data direction

  This is always a good idea as it reduces spaghetti logic and hard to
  trace event flows. There’s nothing preventing you from doing the same
  with jQuery and Angular but the React frameworks actually enforce this
  and it’s a blessing.

  • Enforces components

This is both a plus and a minus, components is definitely where the web is going but sometimes you just want to sprinkle some Javascript over a large HTML file, React is not a great fit for that. But if your app gets bigger and you have a large team collaborating on a single view nothing beats simple composable components and React loves these.

  • Isomorphic apps today

  Round-trip apps render quickly but provide a sub-par user experience as
  each action results in a full page load. On the other hand single page
  apps provide a great user experience but have a relatively long boot
  time. Isomorphic apps are apps that render either on the client or on
  the server allowing you to mix the two approaches for optimal results.
  Angular is coming out with an Isomorphic variant (called Universal)
  but React has this today so if you want to go Isomorphic, React is
  probably the best bet right now.

  • React-Native today

  React-Native brings the well polished and great looking native widgets
  to the world of cross platform mobile development. Other
  frameworks may offer the same but right now, React is the only
  framework with a production grade offering so there’s that.

  • Easier offline-first

  Since React is very explicit about global state (as this is where all
  the rendering comes from) it forces you to think about global
  state first. That’s a good idea if you want to build offline-first

This sounds great, why not React?

  • There’s no silver bullet

  React brings a really innovative approach to UI development but after
  the dust settles, I think we’ll still discover that most of
  development efforts revolve around final touches, fine-tuning UX and
  squashing bugs. React can’t eliminate those.

  • Relatively young

  While React is driven by Facebook and is in production right now, it
  is still a relatively young framework and there’s little consensus
  around how to do things, basically everyone is reinventing React, at
  least for now.

  • Nothing new

  So of course React is new, virtual DOM is brilliant, and immutable
  datastructures are heavenly but you can write beautiful, boiler-plate
  free, test driven, component based, isomorphic, offline-first,
  grass-fed and gluten free UI in pretty much any framework you want,
  it’s almost always the ideas behind the tool rather than the tool that
  make the difference.


The water’s fine… jump in 🙂

Leave a Reply