Add "Why React"

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

@@ -0,0 +1,125 @@
+---
+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!