Revise "Why React" content.

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

@@ -5,121 +5,113 @@ author: Pete Hunt
 ---
 
 There are a lot of JavaScript MVC frameworks out there. Why did we
-build React, and why would you want to use it?
+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.
+React is a library for building large complex user interfaces with
+many reusable components that handle events, present backend data,
+and accept user input. At the same time, React was built to integrate
+with legacy code and to support older browsers.
 
-In a conventional MVC application, you'd build the View with React
-(and maybe the Controller too, if you'd like).
+In the traditional MVC pattern, React is used to build the view. React
+lets you decide how to manage your data and business logic, be it
+outside of React components or within.
 
-## React doesn't use templates.
+## React does not 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.
+Traditionally, web application user interfaces are built using
+templates written in templating languages or HTML directives. These
+templates dictate the full set of abstractions that you are allowed to
+use to build the user interface.
 
-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:
+React approaches building user interfaces differently by breaking them
+down into smaller, composable and reusable **components**. Although
+this means we have JavaScript generating markup, we think this is an
+advantage over 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
+  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 are unifying the presentation layer, not
+  breaking separation of concerns.
+- Large projects usually do not use WYSIWYG editors for production
+  code, so breaking apart markup from code creates friction without
+  any real gain.
+- By baking an understanding of markup and content into JavaScript,
+  there is **no manual string concatenation** and, thus, less surface
+  area for XSS vulnerabilities.
+
+## React updates are dead simple.
 
 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).
+In a traditional JavaScript application, you need to look at what data
+changed and imperatively make changes to the DOM to keep it up-to-date.
+Even AngularJS, which provides a declarative interface via directives
+and data binding, requires a linking function to manually update DOM
+nodes. (Remember, React components are flexible and expressive, much
+like directives and less like templates in AngularJS.)
 
 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.
+data changes, the `render()` method is called again. We simply diff
+the old return value with the new one and determine the fastest way to
+update the DOM. So if only a single attribute on a single element has
+changed, that is all that React updates.
 
 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
+Reconciliation will usually be faster than handwritten code because
+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,
+The way we are 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**.
+dirtied and which parts are clean. **The data returned from `render()`
+is neither a string nor a DOM node -- it is 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.
+we do not need the end user to explicitly specify data bindings. We
+have found this to be an easier way to build apps. It is 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 the parts of the markup that need to be changed are 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.
+No other framework that we have seen does this.
 
-## Not just for HTML components in the browser
+## HTML is just the beginning.
 
-Since React makes so few assumptions about its environment, we can do
-some pretty cool things with it:
+Since React makes very 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
+- Facebook 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
+- We have 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)
+  [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
+out what we have built. Our documentation is geared towards building
+apps with the framework, but if you are interested in the
 nuts-and-bolts
 [get in touch](http://facebook.github.io/react/support.html) with us!