The library for web and native user interfaces.
Revise "Why React" content.
yungsters committed
Jun 3, 2013 at 14:49 UTC
3ded55f9f7a1ed005c2053e2f99f5fbb1e8b2cfa
1 file changed
+64
-72
docs/_posts/2013-06-03-why-react.md
+64
-72
@@ -5,121 +5,113 @@ author: Pete Hunt
5
---
6
7
There are a lot of JavaScript MVC frameworks out there. Why did we
8
-build React, and why would you want to use it?
8
+build React and why would you want to use it?
9
10
11
## React is not an MVC framework.
12
13
-It's a library designed for building big UIs. The type where you have
14
-lots of reusable components that are handling events, presenting
15
-backend data, and accepting user input. The type where you have to
16
-integrate with legacy code, and support legacy browsers.
13
+React is a library for building large complex user interfaces with
14
+many reusable components that handle events, present backend data,
15
+and accept user input. At the same time, React was built to integrate
16
+with legacy code and to support older browsers.
17
18
-In a conventional MVC application, you'd build the View with React
19
-(and maybe the Controller too, if you'd like).
18
+In the traditional MVC pattern, React is used to build the view. React
19
+lets you decide how to manage your data and business logic, be it
20
+outside of React components or within.
21
21
-## React doesn't use templates.
22
+## React does not use templates.
23
23
-Traditionally, you'd create a set of templates with a template
24
-language or HTML directives to make a page dynamic. It's up to the
25
-designer of the template language or the author of the directives to
26
-provide the full set of abstractions you can use to build your
27
-front-end code.
24
+Traditionally, web application user interfaces are built using
25
+templates written in templating languages or HTML directives. These
26
+templates dictate the full set of abstractions that you are allowed to
27
+use to build the user interface.
28
29
-React's technique is to break your view down into small, composable
30
-and reusable **components**. These components provide a `render()`
31
-method which specifies how the component will generate its
32
-markup. `render()` can either return normal DOM elements (like
33
-`<div>`s) or can return other components.
34
-
35
-This means that yes, we have JavaScript generating markup. But we
36
-think that this is an advantage over using templates for a few
37
-reasons:
29
+React approaches building user interfaces differently by breaking them
30
+down into smaller, composable and reusable **components**. Although
31
+this means we have JavaScript generating markup, we think this is an
32
+advantage over templates for a few reasons:
33
34
- **JavaScript is a flexible, powerful programming language with the
40
- ability to build abstractions.** This is incredibly important in
41
- large applications.
42
-- "Logic" and "markup" are intimately tied, and are both part of the
43
- "presentation" layer, so we're unifying the presentation layer,
44
- not breaking separation of concerns.
45
-- Large projects usually don't use WYSIWYG editors for production
46
- code, so breaking apart markup from the code that creates it usually
47
- only introduces friction.
48
-- We've built a safe, convenient and fast way to compose markup and
49
- components using pure JavaScript. This means **no manual string
50
- concatenation** and limited surface area for XSS vulnerabilities.
51
-
52
-## Reacting to changes
35
+ ability to build abstractions.** This is incredibly important in
36
+ large applications.
37
+- Logic and markup are intimately tied and are both part of the
38
+ presentation layer. So we are unifying the presentation layer, not
39
+ breaking separation of concerns.
40
+- Large projects usually do not use WYSIWYG editors for production
41
+ code, so breaking apart markup from code creates friction without
42
+ any real gain.
43
+- By baking an understanding of markup and content into JavaScript,
44
+ there is **no manual string concatenation** and, thus, less surface
45
+ area for XSS vulnerabilities.
46
+
47
+## React updates are dead simple.
48
49
React really shines when your data changes over time.
50
56
-In a traditional JavaScript application you need to look at what data
57
-changed and imperatively make changes to the DOM to make them
58
-consistent. Even AngularJS, which provides a declarative interface via
59
-directives and data binding, still requires a linking function to
60
-manually update DOM nodes (remember: React components are quite
61
-flexible and analogous to AngularJS directives, not templates. In big
62
-apps you'll almost certainly need this level of expressive power).
51
+In a traditional JavaScript application, you need to look at what data
52
+changed and imperatively make changes to the DOM to keep it up-to-date.
53
+Even AngularJS, which provides a declarative interface via directives
54
+and data binding, requires a linking function to manually update DOM
55
+nodes. (Remember, React components are flexible and expressive, much
56
+like directives and less like templates in AngularJS.)
57
58
React takes a different approach.
59
60
When your component is first initialized, the `render()` method is
61
called and a string of static HTML is inserted into the DOM. When your
68
-data changes, the `render()` method is called again. We diff the old
69
-return value from `render()` with the new one and determine the
70
-fastest way to update the DOM. So if only a single attribute on a
71
-single node has changed, that's all that React will update.
62
+data changes, the `render()` method is called again. We simply diff
63
+the old return value with the new one and determine the fastest way to
64
+update the DOM. So if only a single attribute on a single element has
65
+changed, that is all that React updates.
66
67
We call this process **reconciliation**. Check out
68
[this jsFiddle](http://jsfiddle.net/fv6RD/3/) for an example of
69
reconciliation in action.
70
77
-Usually reconciliation will be faster than handwritten code, as React
78
-knows about the entire state of the page and can do cool tricks like
79
-batching reads and writes and picking the fastest subset of DOM
71
+Reconciliation will usually be faster than handwritten code because
72
+React knows about the entire state of the page and can do cool tricks
73
+like batching reads and writes and picking the fastest subset of DOM
74
mutations to perform.
75
82
-The way we're able to pull this off is by constructing a very fast,
76
+The way we are able to pull this off is by constructing a very fast,
77
lightweight representation of the DOM which knows which parts are
84
-dirtied and which parts are clean. That is, **the data returned from
85
-`render()` isn't a string and isn't a real DOM node, it's just a
86
-lightweight description of what the DOM should look like**.
78
+dirtied and which parts are clean. **The data returned from `render()`
79
+is neither a string nor a DOM node -- it is a lightweight description
80
+of what the DOM should look like.**
81
82
Because this re-render is so fast (on the order of 1ms for TodoMVC),
89
-we don't need the end user to explicitly specify data bindings. We've
90
-found that this is an easy way to build apps. It's a lot like the
91
-early days of the dynamic web. Back then you wrote simple
92
-presentational code and when your data changed you simply refreshed
93
-the page. Today, React makes that "refresh" very fast and lightweight,
94
-and only changes the parts of the markup that need to be changed.
83
+we do not need the end user to explicitly specify data bindings. We
84
+have found this to be an easier way to build apps. It is a lot like
85
+the early days of the dynamic web. Back then, you wrote simple
86
+presentational code and when your data changed, you simply refreshed
87
+the page. Today, React makes that refresh very fast and lightweight,
88
+and only the parts of the markup that need to be changed are changed.
89
96
-No other framework we've seen can support this easily, since it would
97
-have to be built from the ground up to have very little coupling with
98
-the DOM.
90
+No other framework that we have seen does this.
91
100
-## Not just for HTML components in the browser
92
+## HTML is just the beginning.
93
102
-Since React makes so few assumptions about its environment, we can do
103
-some pretty cool things with it:
94
+Since React makes very few assumptions about its environment, we can
95
+do some pretty cool things with it:
96
105
-- Facebook.com has dynamic charts that render to `<canvas>` instead of
106
- HTML
97
+- Facebook has dynamic charts that render to `<canvas>` instead of
98
+ HTML.
99
- Instagram is a "single page" web app built entirely with React and
100
`Backbone.Router`. Designers regularly contribute React code with
101
JSX.
110
-- We've built an internal prototype that runs React apps in a web
111
- worker
102
+- We have built an internal prototype that runs React apps in a web
103
+ worker.
104
- You can run React
105
[on the server](http://github.com/petehunt/react-server-rendering)
106
for SEO, performance, code sharing and overall flexibility.
107
- Events behave in a consistent, standards-compliant way in all
108
browsers (including IE8) and automatically use
117
- [event delegation](http://davidwalsh.name/event-delegate)
109
+ [event delegation](http://davidwalsh.name/event-delegate).
110
111
Head on over to
112
[facebook.github.io/react](http://facebook.github.io/react) to check
121
-out what we've built. Our documentation is geared towards building
122
-apps with the framework, but if you're interested in the
113
+out what we have built. Our documentation is geared towards building
114
+apps with the framework, but if you are interested in the
115
nuts-and-bolts
116
[get in touch](http://facebook.github.io/react/support.html) with us!
117