TL;DR I struggled for a long time trying to understand what React is and how it fits in the application architecture. This post is what I wish someone had told me.
How does React compare to Angular, Ember, Backbone, et al? How do you handle data? How do you contact the server? What the heck is JSX? What is a "component"?
Stop.
Stop it right now.
React is ONLY THE VIEW LAYER.
React is often mentioned in the same breath as other Javascript frameworks, but "React vs Angular" doesn't make sense because they aren't directly comparable things. Angular is a complete framework (including a view layer), React is not. This is why React is so confusing to understand, it's emerging in an ecosystem of complete frameworks, but it's just the view.
React gives you a template language and some function hooks to essentially render HTML. That's all React outputs, HTML. Your bundles of HTML / Javascript, called "components", are allowed things like storing their own internal state in memory (such as which tab is selected in a tab view), but in the end you just barf out HTML.
You absolutely cannot build a fully functional dynamic application with React alone. We'll learn more about why below.
After working with React for a while, I've seen three very important benefits surface.
1. You can always tell how your component will render by looking at one source file.
This may be the most important benefit, even though it is not different from Angular templates. Let's use a real world implementation example.
Say you have to update your site's header with the user's name upon log in. If you're not using a Javascript MVC framework, you might do this:
<header>
<div class="name"></div>
</header>
$.post('/login', credentials, function( user ) {
// Modify the DOM here
$('header .name').show().text( user.name );
});
I can tell you from experience that this code will ruin your life and your friends' lives. How do you debug the output? Who updated the header? Who else has access to the header HTML? Who holds the source of truth for the name being visible? This DOM manipulation is just as bad as a GOTO statement for reasoning about your program.
Here's how you might do it in React:
render: function() {
return <header>
{ this.state.name ? <div>this.state.name</div> : null }
</header>;
}
We can tell instantly how this component will render. If you know the state, you know the rendered output. You don't have to trace program flow. When working on complex applications, especially in teams, this is critically important.
2. Bundling Javascript and HTML into JSX makes components easily understandable.
The weird mix of HTML / Javascript soup above might make you cringe. We've been conditioned to not put raw Javascript in the DOM (like onClick handlers) since we were wee developers. You'll have to trust me, though; working with JSX components is really nice.
Traditionally you separate views (HTML) from functionality (Javascript). This leads to monolithic Javascript files containing all functionality for one "page", and you have to trace complex flow from JS > HTML > JS > bad-news-sad-time.
Tying functionality directly to markup and packaging it in a portable, self contained "component" will make you happier and less filthy in general. Your Javascript has intimate knowledge of your HTML, so mashing them together makes sense.
3. You can render React on the server.
If you're building a public facing site or app and you're following the render-it-all-on-the-client path, you've already done it wrong. Client-only rendering is why Soundcloud feels so slow and why Stack Overflow (purely server side rendering) feels so fast. You can render React on the server, and you should.
Angular and others encourage you to do disgusting things like render your page with PhantomJS and serve that to search engine crawlers based on user agent, or pay actual cash money for that as a service. Ugh.
Don't forget that React is only the view.
1. You DO NOT GET any of the following:
React on its own is useless for the real world. Worse yet, as we'll see, this leads to everyone reinventing the wheel.
2. The documentation is not "accessible" nor "good." Again, this is a blog post for stupid people. Look at the first part of the sidebar on the documentation page:
There are three separate, competing quickstart guides. I'm overwhelmed and I'm not even drunk. The sidebar below that is straight out of my nightmares, with sections that obviously shouldn't be there, like "More About Refs" and "PureRenderMixin".
3. React is large for how little you get, including how little cross browser support.
Update: React is not 144 KB as I previously wrote. React is about 35 KB gzipped over the wire.
That's without the react-with-addons library you will need to actually develop a real app!
That's without the ES5 Shim library you need to support IE8!
That's without any sort of application library of any kind!
React is a comparable size with Angular, even though Angular is a complete application framework. React is frankly bloated for how little functionality you get. Hopefully this will improve in the future.
Perhaps the most annoying part of React development is "Flux." It's far more confusing than React. The name "Flux" is a pretentious barrier to understanding.
There is no such thing as Flux. Flux is a concept, not a library. Well, there is a library, sort of:
"Flux is more of a pattern than a framework"
Ugh. The worst part is the name: React didn't reinvent the last 40 years of UI architecture knowledge and come up with some brand new concept for data management.
The concept "Flux" is simply that your view triggers an event (say, after user types a name in a text field), that event updates a model, then the model triggers an event, and the view responds to that model's event by re-rendering with the latest data. That's it.
This one way data flow / decoupled observer pattern is designed to guarantee that your source of truth always stays in your stores / models. It's a Good Thing™.
The bad side of Flux is that everyone is re-inventing it. Since there's no agreed on event library, model layer, AJAX layer, or anything, there are many different "Flux" implementations, and they all compete with each other.
Short answer: yes.
Long answer: unfortunately, yes, for most things.
Here's why you should use React:
Here's why you should think twice before you switch:
Check out the follow-up post, Flux For Stupid People.
I hope this helped someone as stupid as me understand React better. If this post made your life easier, consider following me on Twitter
