index.md 10KB
title: ReactJS For Stupid People
url: http://blog.andrewray.me/reactjs-for-stupid-people/
hash_url: 352a1ada40
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.
What is React?
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.
The Good
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.
The Bad
Don't forget that React is only the view.
1. You DO NOT GET any of the following:
- An event system (other than vanilla DOM events)
- Any AJAX capabilities whatsoever
- Any form of a data layer
- Promises
- Any application framework at all
- Any idea how implement the above
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.
Stop Saying Flux
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.
Should I Use React?
Short answer: yes.
Long answer: unfortunately, yes, for most things.
Here's why you should use React:
- Works great for teams, strongly enforcing UI and workflow patterns
- UI code is readable and maintainable
- Componentized UI is the future of web development, and you need to start doing it now.
Here's why you should think twice before you switch:
- React will slow you down tremendously at the start. Understanding how props, state, and component communication works is not straightforward, and the docs are a maze of information. This will be countered, in theory, by a grand speed up when your whole team is on board.
- React does not support any browser below IE8, and never will
- If your application / website doesn't have very much dynamic page updating, you will be implementing a lot of code for a very small benefit.
- You will reinvent a lot of wheels. React is young, and because there's no canonical way to do events / component communication, you'll have to build large component libraries from scratch. Does your application have dropdowns, resizable windows, or lightboxes? You'll probably have to write those all from scratch.
That's It!
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