diff --git a/_posts/2013-06-04-why-react.md b/_posts/2013-06-04-why-react.md index 8cb79945..2ea0f5f7 100644 --- a/_posts/2013-06-04-why-react.md +++ b/_posts/2013-06-04-why-react.md @@ -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 `` instead of HTML. - Instagram is a "single page" web app built entirely with React and