From b3e2aca13a529cc148191b68882810cffeef70cf Mon Sep 17 00:00:00 2001 From: petehunt Date: Mon, 3 Jun 2013 11:01:08 -0700 Subject: [PATCH 1/4] Add why-react --- docs/_posts/2013-06-03-why-react.md | 52 +++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 docs/_posts/2013-06-03-why-react.md diff --git a/docs/_posts/2013-06-03-why-react.md b/docs/_posts/2013-06-03-why-react.md new file mode 100644 index 0000000000000..6c76c4ac813c1 --- /dev/null +++ b/docs/_posts/2013-06-03-why-react.md @@ -0,0 +1,52 @@ +--- +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? + +First of all, **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). + +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 `
`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 not breaking separation of concerns. +- Large projects usually don't use WYSIWYG editors for production code +- 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. + +But the area where React really shines is when your data changes. + +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. + +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 `` 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! From 1897bb3d2e35c84fff9321d82cb91b54709e69a5 Mon Sep 17 00:00:00 2001 From: petehunt Date: Mon, 3 Jun 2013 11:16:38 -0700 Subject: [PATCH 2/4] @vjeux @benjamn --- docs/_posts/2013-06-03-why-react.md | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/docs/_posts/2013-06-03-why-react.md b/docs/_posts/2013-06-03-why-react.md index 6c76c4ac813c1..f59445159e000 100644 --- a/docs/_posts/2013-06-03-why-react.md +++ b/docs/_posts/2013-06-03-why-react.md @@ -6,10 +6,14 @@ 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? -First of all, **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 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 `
`s) or can return other components. @@ -18,10 +22,12 @@ This means that yes, we have JavaScript generating markup. But we think that thi - **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 not breaking separation of concerns. -- Large projects usually don't use WYSIWYG editors for production code +- 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. -But the area where React really shines is when your data changes. +## 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). @@ -39,10 +45,12 @@ Because this re-render is so fast (on the order of 1ms for TodoMVC), we don't ne 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 `` instead of HTML -- Instagram is a "single page" web app built entirely with React and Backbone.Router. Designers regularly contribute React code with JSX. +- 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) From 0244123a5233bfa5b017e060caa8db77226b0745 Mon Sep 17 00:00:00 2001 From: petehunt Date: Mon, 3 Jun 2013 11:19:51 -0700 Subject: [PATCH 3/4] Break lines --- docs/_posts/2013-06-03-why-react.md | 132 +++++++++++++++++++++------- 1 file changed, 98 insertions(+), 34 deletions(-) diff --git a/docs/_posts/2013-06-03-why-react.md b/docs/_posts/2013-06-03-why-react.md index f59445159e000..474af332a769d 100644 --- a/docs/_posts/2013-06-03-why-react.md +++ b/docs/_posts/2013-06-03-why-react.md @@ -4,57 +4,121 @@ 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? +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. +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). +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 `
`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 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. +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 +`
`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 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). +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. +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 `` 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! +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 `` 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! From 7b5602d00a323df52120e6b225a1c4109d9bdc26 Mon Sep 17 00:00:00 2001 From: petehunt Date: Mon, 3 Jun 2013 12:09:14 -0700 Subject: [PATCH 4/4] @jeffreylin --- docs/_posts/2013-06-03-why-react.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/_posts/2013-06-03-why-react.md b/docs/_posts/2013-06-03-why-react.md index 474af332a769d..a631a9ac74bd0 100644 --- a/docs/_posts/2013-06-03-why-react.md +++ b/docs/_posts/2013-06-03-why-react.md @@ -39,7 +39,8 @@ reasons: 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 not breaking separation of concerns. + "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.