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
it. 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
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!
Coupled with the wonderful
Immutable.js library, React
is able to diff virtual and actual DOMs even more effciently 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
documentation about the
subject, immutable datastructures 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
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 :)