You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 

4.9 KiB

title layout author
Why Should You Care About React? post 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 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.
  • By baking an understanding of markup and content into JavaScript, there's no manual string concatenation and therefore less surface area for XSS vulnerabilities.

Reactive 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 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 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.

We call this process reconciliation. Check out this jsFiddle 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 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.

No other framework that we've seen has managed to decouple building UIs without being coupled with the DOM.

HTML is just the beginning.

Since React makes very few assumptions about its environment, 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 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 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.

Head on over to facebook.github.io/react to check 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 with us!

Thanks for reading!