M V C An easy way to think of it is as just the V in MVC. It’s not strictly true as the borders of these can start to get fuzzy, but generally speaking, that’s mostly where it fits.
Who here has seen or read the Da Vinci Code? So we know Leonardo Da Vinci was a member of a secret society tasked with was protecting the secret of the holy grail. We all know that’s crazy… right? After years of working on large codebases with complicated implicit data relationships, an intrepid young developer by the name of Jordan Walke went looking for answers.
PHP + XML = XHP The history of React actually begins several years ago with something called XHP. XHP is an extension to PHP which let you embed XML in your PHP while generating views.
echo ; The beauty of this system was that it was extensible. It was possible to wrap up reusable pieces of markup and refer to a single line of code. For example, here's how you render a friend button in XHP. Again, you're just using XML, but now referring to something specific in a namespace. We simply call this a component.
echo ; An interesting thing came out of this, instead of each page fetching all the data it might need up front and passing it off to a template, each component became responsible for the data it accepted as arguments and the data it would fetch before rendering. In this case we need to know information about the relationship between the viewer and user with uid 1234. With server rendering you only send data down the tree, never up, so the data flow is unidirectional and always flowing down, never back up.
So out of XHP we came away with 2 really important concepts that became essential to developing anything at Facebook: components and explicit data flow and ownership.
Reusable Components So out of XHP we came away with 2 really important concepts that became essential to developing anything at Facebook: components and explicit data flow and ownership.
Reusable Components Explicit Data Flow & Ownership So out of XHP we came away with 2 really important concepts that became essential to developing anything at Facebook: components and explicit data flow and ownership.
What about JavaScript? Ok, enough about PHP. What about JavaScript? Historically we used JS pretty sparingly at FB. In our ads product we wanted to build an app that felt much more like a desktop app.
Here’s what some of it looks like today. So we wrote it primarily with JavaScript. And as you do, libraries tend to pop up to help with this process. The first thing we did was continue building around this idea of components. Data binding is/was a really popular way to build client-side JS applications and that's what we did. As the product became more complex, it became harder and harder to understand what other parts of the page were being modified when you made changes to the data model in your component.
Here’s what some of it looks like today. So we wrote it primarily with JavaScript. And as you do, libraries tend to pop up to help with this process. The first thing we did was continue building around this idea of components. Data binding is/was a really popular way to build client-side JS applications and that's what we did. As the product became more complex, it became harder and harder to understand what other parts of the page were being modified when you made changes to the data model in your component.
Jordan Jordan Walke (from our Da Vinci story earlier) took a step back and realized that with these implicit updates, it was not only hard to realize the scope of your changes, but frequently you were updating pieces of data, resulting in a lot of DOM manipulations. He wanted to clean this up and for that he took inspiration from server-side rendering and functional programming.
It took a couple attempts. The first version of React was actually written in SML. There’s no idea of a DOM or a browser here, but the core functional concepts made their way out. Then he used a framework called Haxe. And finally a version was written in pure JS. At the time, people at Facebook thought the entire idea was crazy and Jordan kept iterating worked on some APIs and recruited some others to help out. Out of that effort we ended up with what we now call React.
SML It took a couple attempts. The first version of React was actually written in SML. There’s no idea of a DOM or a browser here, but the core functional concepts made their way out. Then he used a framework called Haxe. And finally a version was written in pure JS. At the time, people at Facebook thought the entire idea was crazy and Jordan kept iterating worked on some APIs and recruited some others to help out. Out of that effort we ended up with what we now call React.
SML Haxe It took a couple attempts. The first version of React was actually written in SML. There’s no idea of a DOM or a browser here, but the core functional concepts made their way out. Then he used a framework called Haxe. And finally a version was written in pure JS. At the time, people at Facebook thought the entire idea was crazy and Jordan kept iterating worked on some APIs and recruited some others to help out. Out of that effort we ended up with what we now call React.
SML Haxe JS It took a couple attempts. The first version of React was actually written in SML. There’s no idea of a DOM or a browser here, but the core functional concepts made their way out. Then he used a framework called Haxe. And finally a version was written in pure JS. At the time, people at Facebook thought the entire idea was crazy and Jordan kept iterating worked on some APIs and recruited some others to help out. Out of that effort we ended up with what we now call React.
So we have the first 2 concepts in this solution. The other big thing in React is the Virtual DOM, which is actually more a side effect of making the rest work performantly than anything else. It turned out to be a great idea (and great marketing) but the other 2 core concepts here are the real driving forces in React.
Reusable Components So we have the first 2 concepts in this solution. The other big thing in React is the Virtual DOM, which is actually more a side effect of making the rest work performantly than anything else. It turned out to be a great idea (and great marketing) but the other 2 core concepts here are the real driving forces in React.
Reusable Components Explicit Data Flow & Ownership So we have the first 2 concepts in this solution. The other big thing in React is the Virtual DOM, which is actually more a side effect of making the rest work performantly than anything else. It turned out to be a great idea (and great marketing) but the other 2 core concepts here are the real driving forces in React.
Reusable Components Explicit Data Flow & Ownership Virtual DOM So we have the first 2 concepts in this solution. The other big thing in React is the Virtual DOM, which is actually more a side effect of making the rest work performantly than anything else. It turned out to be a great idea (and great marketing) but the other 2 core concepts here are the real driving forces in React.
10,000 components Today there are nearly ten thousand components in the Facebook codebase. We use it every day from user facing product code to internal tools. A few other companies use it too…
The other thing I wanted to call out was our commitment to open source. We haven't done the best job here with many discussions happening behind closed doors and code being exported to the public repository without chance for comment from our community. We're working on being better here. With little exception, all of our recent code changes have come via pull requests, even those from FB employees.
Where is React going? Now to talk about where we're headed. We have a number of big ideas I wanted to talk about, along with the usual crop of bug fixes. Some of this will be a part of 1.0. Others are just problems we’re working on without a specific milestone in mind.
Slow march to 1.0 Since launch we've been talking about 1.0 and what that means. Over the past 18 months we've taken some time to figure it out better. We've been solidifying the core concepts of React and refining the implementation. We’re learning as we go and moving slowly - we are using React extensively and know that large changes are difficult to deal with.
API Stabilization & Reduction A big part of this is API stabilization and reduction. One of my colleagues Sebastian Markbåge just gave a talk about JSConf about the philosophy here. Piggybacking on as many language features as possible results in lower cognitive overhead for people new to your codebase and in general, just for anybody reading your code. We spend just as much if not more time reading code as we do reading it. We know we've made mistakes. For example, the idea of a React Component Class is strange. I’ll get back to that in a minute.
ES6,7,* Facebook is a member of TC39, the committee working on the future of JS. We are actively participating in the standardization of new language features and giving feedback based on our experience. At Facebook we’ve invested heavily in the future of JS and we actually write code at Facebook that uses ES6 and even ES7 features. We polyfill where possible and apply transforms in other places.
); } }; This is how you create a React Component Class today. It’s not clear exactly what’s happening behind the scenes of createClass. Does it return a constructor? Or just a regular function? Can I use instanceof?
CSS in JS CSS in JS in another idea we've been working on. Christopher Chedeau gave a talk about this 2 weeks ago and the slides are online. I don’t have time to cover all so check them out if you’re interested. Setting and modifying style from JS has been possible forever.It’s not a new one, you've been able to modify the style of elements from JS forever. But moving stylesheets entirely to JS would result in a single place to make changes to your code, making it easier to build truly encapsulated components.
Web Workers Web Workers, for those who aren't familiar, basically gives you threads on the web. So in theory you can do really expensive calculations off the main thread, allowing the user to continue scrolling the page without jittering. We're exploring how we might take advantage of this to speed up React.
Layout & Animations These are hard problems, especially to solve in a declarative way. We’ve been learning from some other projects, namely Pop on iOS and Rebound on Android, to get some ideas and see where we can go. These are obviously critical things to solve and the intermediate solutions we have only get you so far.
M V C Remember earlier how I said that React is been just the V in MVC. The M and the C are also really important when it comes to building applications. There’s a reason Ember and Angular are popular. A lot of it is that they are really impressive technologies. But another piece people often overlook is that they prescribe how to do *a lot* of your front end. There are some decisions to make but in comparison React forces you to make many more. What router are you going to use? Is Backbone ok? Backbone has mutable models so how do I make that work? What about Meteor? Firebase? Parse? How do I do server rendering and actually hook it up? We’ve seen a lot of cool things coming from the community as people try to answer all of these questions. I’m not sure if we’ll ever necessarily have a single React “framework” but I have a lot of respect for people building frameworks and I think it’s an important area for us to explore.
? And lots more that I don’t have time to talk about. Better testing tools, improved documentation, immutable data structures, lots of community related efforts, and much more.
codehex
azukiazusa1
pylapp
niftycorp
assu_ming
prof18
fadis
philipschwarz
seike460
suzukimar
atinfinity
zerebom
zakiyama
samlambert
hursman
sferik
ddemaree
sachag
paulrobertlloyd
holman
ufuk
samanthasiow
addyosmani
tanoku