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.
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.
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.
XHP we came away with 2 really important concepts that became essential to developing anything at Facebook: components and explicit data flow and ownership.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
}, render: function() { return ( <button onClick={() => this.setState({clicked: true})}> {this.state.clicked} </button> ); } }; 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?
} render() { return ( <button onClick={() => this.setState({clicked: true})}> {this.state.clicked} </button> ); } } This isn’t quite possible yet, but we’re getting there. We actually just landed initial support for rudimentary class support last week.
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.
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.
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.
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.
thehaigo
tsucchinoko
ysk8hori
0si43
cer
oniak3ibm
marokanatani
twada
ivargrimstad
tsoshiro
mayuki
maaretp
shlominoach
paigeccino
davidbonilla
lara
tenderlove
reverentgeek
geoffreycrofte
danielanewman
speakerdeck
sstephenson
pedronauck
csswizardry
