If you follow me on Twitter, you’ve probably heard me raving about React. React is described as a “JavaScript library for building user interfaces” and was open sourced by Facebook about a year ago. Everybody and their mom has a JavaScript framework, so what makes React so interesting? Why would you use it over mainstays like Backbone or Angular?
There are a few things that make React worth looking at. First, React is a library, not a framework. It makes no assumptions about your frontend stack, and it plays nicely with existing codebases, regardless of the tech you’re using. This is great because you can use React incrementally for new or legacy code. Write your whole UI with it or use it for a single feature. All you need is a DOM node to mount.
React is delightfully simple (contrasted with Angular, which is a nightmare for beginners, and Backbone, which is relatively simple but still has several core concepts). It’s built around one idea: the Component, which is merely a reusable unit of UI. React was designed from the ground-up to be composable—Components are composed of other Components. Everything in the DOM is a Component, so your UI consists of a hierarchy of them.
Components can be built using JSX, an XML-like syntax that compiles down to regular JavaScript. As such, they can also be specified using plain-old JavaScript. The result is the same, but JSX makes it easy to visualize your DOM.
React does not do two-way data binding ((It’s worth noting that React provides a small add-on for getting the conciseness of two-way binding with the correctness of its one-way binding model.)). This is by design. It uses the von Neumann model of dataflow, which means data flows in only one direction. Two-way data binding makes it difficult to reason about your code. The advantage of the one-way model that React adopts is that it essentially turns your UI into a deterministic state machine. On the surface, it behaves as if the entire UI is simply re-rendered based on the current state of your data model. If you know what state your data is in, you know exactly what state your UI is in. Your UI is predictable. The React mantra is “re-render, don’t mutate.”
Re-rendering the entire DOM sounds expensive, but this is where React really shines. In order to draw your UI, it maintains a virtual DOM which can then be diffed. React’s diffing algorithm determines the minimum set of Components that need to be updated. It also batches reads and writes to the real DOM. This makes React fast.
Data is modeled two ways in a React component, props and state, which highlights the one-way data flow described earlier. Props consist of data that is passed from parent to child. A Component’s props can only be set by its parent. State, on the other hand, is an internal data structure that is accessed and modified only from within a Component. A Component is re-rendered when either its props or state is updated.
Once again, this makes it really easy to reason about your code (and unit test). Also note the use of the onClick handler. React provides a synthetic event system that gives you cross-browser compatible event listeners that you can attach to Components.
React and Backbone’s Router is a surprisingly powerful, yet effortless, combination for building single-page applications.
React makes it trivial to build small web apps, but because of its affinity for reusability and data modeling, it also scales well for large, complex UIs. You don’t have to use it for a new project, just start replacing small pieces of your UI with React Components. This makes it a lot easier for developers to adopt.
Follow @tyler_treat
I’ve been reading a lot about react, and also I’ve been building things in html recently. I am certainly not sold on this pattern, or level of complexity for simple todo lists (which are what all the demos are in).
Beyond that, maybe it is useful? But in reality these dom updating problems aren’t all that interesting to me anymore. The maintainability and long term library support are far more interesting. And it seems like these js libraries come and go so quickly.
Have you build a real project with this and did you think the complexity and liability of “other people’s code” was worth the trade off?
I have built a “real” project in it and have found it much more maintainable than using Backbone views (what I used to do) because it really is much easier to reason about. The problem I’ve had with JavaScript UIs is I always ended up using jQuery to manipulate elements based on events and changes in the data model. Backbone views also force a refresh of the entire view that a model/collection is bound to, which has problems beyond performance, e.g. it clears any input fields you’ve populated. I much prefer the fine-grained rendering that React allows.
It has very minimal learning curve—spend an hour with it and you’ll have solid grasp. Spend a day with it and you’ll pretty much have it mastered. I have great disdain for frontend stuff, but I’ve genuinely enjoyed using React. The less state you have in your UI, the better.