|
|
|
@ -1,5 +1,5 @@ |
|
|
|
--- |
|
|
|
title: Why Should You Care About React? |
|
|
|
title: Why did we build React? |
|
|
|
layout: post |
|
|
|
author: Pete Hunt |
|
|
|
--- |
|
|
|
@ -7,35 +7,26 @@ 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? |
|
|
|
|
|
|
|
|
|
|
|
## React isn't 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 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 is a library for building composable user interfaces. It encourages |
|
|
|
the creation of reusable UI components which present data that changes over |
|
|
|
time. |
|
|
|
|
|
|
|
## React doesn't use templates. |
|
|
|
|
|
|
|
Traditionally, web application UIs 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 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. |
|
|
|
- By unifying markup and logic with a common language, applications can |
|
|
|
implement more appropriate separations 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. |
|
|
|
Traditionally, web application UIs are built using templates or HTML directives. |
|
|
|
These templates dictate the full set of abstractions that you are allowed to use |
|
|
|
to build your UI. |
|
|
|
|
|
|
|
React approaches building user interfaces differently by breaking them into |
|
|
|
**components**. This means React uses JavaScript to generate markup, which we |
|
|
|
see as 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. |
|
|
|
- By unifying your markup with it's corresponding view logic, React can actually |
|
|
|
make views **easier to extend and maintain**. |
|
|
|
- By baking an understanding of markup and content into JavaScript, there's |
|
|
|
**no manual string concatenation** and therefore less surface area for XSS |
|
|
|
vulnerabilities. |
|
|
|
@ -46,46 +37,35 @@ 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 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. |
|
|
|
which provides a declarative interface via directives and data binding requires |
|
|
|
a linking function to manually update DOM nodes. |
|
|
|
|
|
|
|
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 simply diff the old return value with the |
|
|
|
new one to determine the fastest way to update the DOM. So if only a single |
|
|
|
attribute on a single element changes, that's all that React updates. |
|
|
|
When your component is first initialized, the `render` method is called, |
|
|
|
generating a lightweight representation of your view. From that representation, |
|
|
|
a string of markup is produced, and injected into the document. When your data |
|
|
|
changes, the `render` method is called again. In order to perform updates as |
|
|
|
efficiently as possible, we diff the return value from the previous call to |
|
|
|
`render` with the new one, and generate a minimal set of changes to be applied |
|
|
|
to the DOM. |
|
|
|
|
|
|
|
We call this process **reconciliation**. Check out |
|
|
|
[this jsFiddle](http://jsfiddle.net/fv6RD/3/) for an example of reconciliation |
|
|
|
in action. |
|
|
|
|
|
|
|
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 data returned from `render` is neither a string nor a DOM node -- it's a |
|
|
|
> a lightweight description of what the DOM should look like. |
|
|
|
|
|
|
|
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. **The data returned from `render()` is neither a string nor a DOM |
|
|
|
node -- it's 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 this to be an |
|
|
|
easier 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 the parts of markup that need to be changed are changed. |
|
|
|
We call this process **reconciliation**. Check out |
|
|
|
[this jsFiddle](http://jsfiddle.net/fv6RD/3/) to see an example of |
|
|
|
reconciliation in action. |
|
|
|
|
|
|
|
No other framework that we've seen has managed to decouple building UIs without |
|
|
|
being coupled with the DOM. |
|
|
|
Because this re-render is so fast (around 1ms for TodoMVC), the developer |
|
|
|
doesn't need to explicitly specify data bindings. We've found this approach |
|
|
|
makes it easier to build apps. |
|
|
|
|
|
|
|
## HTML is just the beginning. |
|
|
|
|
|
|
|
Since React makes very few assumptions about its environment, we can do some |
|
|
|
pretty cool things with it: |
|
|
|
Because React has its own lightweight representation of the document, we can do |
|
|
|
some pretty cool things with it: |
|
|
|
|
|
|
|
- Facebook has dynamic charts that render to `<canvas>` instead of HTML. |
|
|
|
- Instagram is a "single page" web app built entirely with React and |
|
|
|
|
petehunt
12 years ago