diff --git a/docs/_posts/2013-06-03-why-react.md b/docs/_posts/2013-06-03-why-react.md index c52c16d882..d4fb8a993d 100644 --- a/docs/_posts/2013-06-03-why-react.md +++ b/docs/_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 -`
`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. + 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. -## Reacting to changes +## 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 `` instead of - HTML +- Facebook has dynamic charts that render to `` 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!