React showed up last May at JSConf, and the initial reaction was skepticism. Facebook's pitch—"we're putting HTML in JavaScript"—sounded like a regression to the bad old days of mixing presentation and logic. But after spending time with it, I think React is asking the right questions, even if the answers feel uncomfortable.
The Separation of Concerns Debate
Web development has a dogma: separate structure (HTML), presentation (CSS), and behavior (JavaScript). This made sense in 2005 when we were sprinkling jQuery onto server-rendered pages. But single-page applications broke this model. Now our JavaScript creates HTML, manipulates the DOM, and manages state. The "separation" is illusory.
React's proposal: components are the unit of separation, not technologies. A button component owns its markup, styles, and behavior:
var Button = React.createClass({
render: function() {
return (
<button className="primary" onClick={this.handleClick}>
{this.props.label}
</button>
);
},
handleClick: function() {
this.props.onClick();
}
});That JSX syntax—HTML-looking code in JavaScript—is jarring. It violates the separation we've been taught. But it's making a different trade-off: colocate everything related to a component rather than separating by file type.
Whether this is better is debatable. But it's addressing a real problem: when building SPAs, our "separated" code is tightly coupled anyway. The HTML template knows about specific JavaScript functions. The JavaScript knows about specific DOM structure. React admits this coupling and organizes around it.
The Virtual DOM Bet
React's other controversial idea: don't update the DOM directly. Instead, describe what the UI should look like, and React figures out the minimal changes:
// Traditional approach - imperative
$('.counter').text(count);
$('.message').toggle(count > 10);
// React approach - declarative
render: function() {
return (
<div>
<span className="counter">{this.state.count}</span>
{this.state.count > 10 && <span className="message">High!</span>}
</div>
);
}React builds a virtual representation of the DOM, compares it to the previous version (diffing), and applies only the changes needed. This sounds expensive—building a parallel DOM tree, comparing them, computing diffs. Facebook claims it's fast enough that you can treat UI like a pure function: UI = f(state).
The appeal is simplicity. No manual DOM manipulation, no tracking which parts of the page need updating, no accidental inconsistencies between model and view. Just describe what should be rendered given current state.
The skepticism is performance. How can an abstraction that does more work be faster than direct DOM updates? React's answer is that developers are bad at optimizing DOM manipulation, and a library with a good algorithm can do better than hand-written code. Maybe. The proof is in production use.
Where This Fits
React isn't a framework—it's just the view layer. No router, no AJAX, no models. This is intentional. Facebook wants React to be composable with other tools. But it means React alone isn't enough for building applications.
The comparison with Angular is interesting. Angular gives you everything: routing, data binding, dependency injection, templates. React gives you components and nothing else. Angular is opinionated; React is focused.
Which approach is better depends on what you value. Angular provides structure that helps teams avoid bad decisions. React provides flexibility that helps teams build exactly what they need. Both have trade-offs.
The JSX Question
JSX—the HTML-in-JavaScript syntax—is optional. You can write React with pure JavaScript:
React.DOM.div(null,
React.DOM.span({className: 'counter'}, this.state.count)
)This is more "correct" (it's just JavaScript), but it's less readable. JSX looks like markup, which makes UI code easier to scan. But it requires a build step, and mixing languages feels wrong to many developers.
I'm conflicted. JSX makes sense for React's component model, but it creates friction. You need to understand JSX, configure a transformer, and accept that your JavaScript files contain non-JavaScript syntax. That's overhead.
The Component Architecture Pattern
What's most interesting about React isn't the implementation—it's the pattern. Organizing UIs as trees of self-contained components with explicit data flow has appeal regardless of the library.
Other frameworks are exploring this. Web Components (a browser standard being developed) have similar goals. Ember is adding components. The industry seems to be converging on "components are the right abstraction."
React is early to this pattern and opinionated about how it should work. Whether React itself succeeds, the ideas it's pushing seem durable.
Performance Claims Need Validation
Facebook claims React is fast, but they're building Facebook. Their use case is specific: complex UIs with lots of updates, where developer time spent optimizing is expensive. For simpler applications, the virtual DOM overhead might not be worth it.
I'm skeptical that an abstraction doing more work is faster than direct DOM manipulation done well. But "done well" is the key phrase. Most developers don't optimize DOM updates carefully. If React makes decent performance the default, that's valuable even if hand-tuned code would be faster.
The real test is building something with it. Benchmarks are useful, but production usage tells the story.
The Learning Curve Question
React's concepts aren't intuitive. JSX looks weird. Props vs state is confusing initially. The component lifecycle methods require study. There's cognitive overhead.
Compared to Backbone (minimal) or Angular (comprehensive but documented), React sits in an awkward middle. It's not a full framework, so you need other tools. But it's not minimal—it has opinions about how views work.
Whether the learning investment pays off depends on your application complexity. Simple apps don't need React's abstraction. Complex SPAs might benefit from its model.
Looking Forward
React is eight months old. It's being used at Facebook and Instagram, but broader adoption is limited. The patterns it's pushing—components, declarative UIs, virtual DOM—will influence how we think about view layers regardless of React's success.
The bigger question is whether putting HTML in JavaScript is rehabilitation of bad practices or evolution past outdated dogma. I lean toward the latter, but I understand the former argument.
For now, React is worth watching. Even if you don't use it, understanding why Facebook made these choices clarifies trade-offs in UI architecture. And that's valuable regardless of which library you choose.
Resources:
- React – Official documentation
- JSConf US 2013 talk – Pete Hunt introducing React
- React on GitHub – Source and issues
