The latest JavaScript brand to hit critical mass is React. It’s a few years old, and still not at 1.0, but that hasn’t stopped it from making large waves in the community. If you’re just now getting proficient with Angular after switching from Knockout or Backbone, this might feel annoyingly familiar (and you might want to ignore React for a few years while the dust settles). But if you’re interested in where JavaScript at scale might be headed in the future, React deserves your attention for a few reasons.
The first is non-technical: teams at Facebook are using it internally to build very large systems like the chat application. The fact that the React brand of dog food makes up a large part of their diet means that it merits serious consideration. Other libraries like Knockout or Angular are not deployed at nearly the same scale within Microsoft or Google.
Of course, plenty of software tools see wide adoption because of fashion, so with React (and the proposed Flux architecture that goes along with it) we also have to look at the technical situation. Facebook has distributed some good media on this subject (see this video and the Flux documentation) but I get the sense that some of the ideas can be obscured by the vocabulary. I’ve seen “declarative” and “virtual DOM” and “immutable” too many times to count, but these might not communicate the relevant ideas to everyone. You might wonder: What makes React different if both Knockout and Angular use “declarative” markup too?
I think the central idea percolating through the community is stateless UI. React is designed to make it practical to move all state out of your UI components and into a separate, single place for each part of your problem domain (Flux calls these “Stores”). If you’ve ever encountered bugs with two-way view-model type stuff, eliminating these bugs while still delivering good performance is what differentiates this approach. For everyone else, let’s say you have UI components A and B that are bound to your application state (some view-model type stuff), and UI component A receives an update from the user. This propagates to the application state, and if component B is watching it will update as well. But what if component B also contains some state that component A is watching? Now A will update, and so on. In the real world more than two components are usually involved, and the potential for this behavior makes the program harder to reason about.
So then why do we need a special library? Can’t we just move the state out to a separate module and route every action through there (effectively making all bindings one-way)? The reason is that most libraries weren’t designed with that in mind, so throwing away the old state and fetching new state from an external source on every action means a lot of DOM operations, making for a slow application. This is where React’s virtual DOM comes in: you can go ahead and overwrite the state from your external source, and React will optimize what is sent to the real DOM.
More details will have to wait since I’m still learning the technology, but look into reactive programming for an extreme perspective on stateless UI, and check out the Windows message loop to learn about a precursor to the Flux architecture. Again, the technical reasons are important, but the easier argument to understand is that large teams at Facebook and elsewhere have had success with React (and Flux). Happy coding.
GusBook 