react.dev/_posts/2013-06-03-why-react.md

---
title: Why should you care about React?
layout: post
author: petehunt
---

There are a lot of JavaScript MVC frameworks out there. Why did we
build React, and why would you want to use it?

## React is not an MVC framework.

It's a library designed for building big UIs. The type where you have
lots of reusable components that are handling events, presenting
backend data, and accepting user input. The type where you have to
integrate with legacy code, and support legacy browsers.

In a conventional MVC application, you'd build the View with React
(and maybe the Controller too, if you'd like).

## React doesn't use templates.

Traditionally, you'd create a set of templates with a template
language or HTML directives to make a page dynamic. It's up to the
designer of the template language or the author of the directives to
provide the full set of abstractions you can use to build your
front-end code.

React's technique is to break your view down into small, composable
and reusable **components**. These components provide a `render()`
method which specifies how the component will generate its
markup. `render()` can either return normal DOM elements (like
`<div>`s) or can return other components.

This means that yes, we have JavaScript generating markup. But we
think that this is an advantage over using templates for a few
reasons:

- **JavaScript is a flexible, powerful programming language with the
    ability to build abstractions.** This is incredibly important in
    large applications.
- "Logic" and "markup" are intimately tied, and are both part of the
  "presentation" layer, so we're unifying the presentation layer,
  not breaking separation of concerns.
- Large projects usually don't use WYSIWYG editors for production
  code, so breaking apart markup from the code that creates it usually
  only introduces friction.
- We've built a safe, convenient and fast way to compose markup and
  components using pure JavaScript. This means **no manual string
  concatenation** and limited surface area for XSS vulnerabilities.

## Reacting to changes

React really shines when your data changes over time.

In a traditional JavaScript application you need to look at what data
changed and imperatively make changes to the DOM to make them
consistent. Even AngularJS, which provides a declarative interface via
directives and data binding, still requires a linking function to
manually update DOM nodes (remember: React components are quite
flexible and analogous to AngularJS directives, not templates. In big
apps you'll almost certainly need this level of expressive power).

React takes a different approach.

When your component is first initialized, the `render()` method is
called and a string of static HTML is inserted into the DOM. When your
data changes, the `render()` method is called again. We diff the old
return value from `render()` with the new one and determine the
fastest way to update the DOM. So if only a single attribute on a
single node has changed, that's all that React will update.

We call this process **reconciliation**. Check out
[this jsFiddle](http://jsfiddle.net/fv6RD/3/) for an example of
reconciliation in action.

Usually reconciliation will be faster than handwritten code, as React
knows about the entire state of the page and can do cool tricks like
batching reads and writes and picking the fastest subset of DOM
mutations to perform.

The way we're able to pull this off is by constructing a very fast,
lightweight representation of the DOM which knows which parts are
dirtied and which parts are clean. That is, **the data returned from
`render()` isn't a string and isn't a real DOM node, it's just a
lightweight description of what the DOM should look like**.

Because this re-render is so fast (on the order of 1ms for TodoMVC),
we don't need the end user to explicitly specify data bindings. We've
found that this is an easy way to build apps. It's a lot like the
early days of the dynamic web. Back then you wrote simple
presentational code and when your data changed you simply refreshed
the page. Today, React makes that "refresh" very fast and lightweight,
and only changes the parts of the markup that need to be changed.

No other framework we've seen can support this easily, since it would
have to be built from the ground up to have very little coupling with
the DOM.

## Not just for HTML components in the browser

Since React makes so few assumptions about its environment, we can do
some pretty cool things with it:

- Facebook.com has dynamic charts that render to `<canvas>` instead of
  HTML
- Instagram is a "single page" web app built entirely with React and
  `Backbone.Router`. Designers regularly contribute React code with
  JSX.
- We've built an internal prototype that runs React apps in a web
  worker
- You can run React
  [on the server](http://github.com/petehunt/react-server-rendering)
  for SEO, performance, code sharing and overall flexibility.
- Events behave in a consistent, standards-compliant way in all
  browsers (including IE8) and automatically use
  [event delegation](http://davidwalsh.name/event-delegate)

Head on over to
[facebook.github.io/react](http://facebook.github.io/react) to check
out what we've built. Our documentation is geared towards building
apps with the framework, but if you're interested in the
nuts-and-bolts
[get in touch](http://facebook.github.io/react/support.html) with us!

Thanks for reading!