Slide 1

Slide 1 text

React Through the Ages Paul O’Shannessy (@zpao)

Slide 2

Slide 2 text

What is React? Before we get started, here’s a really quick overview for those of you not familiar with React at all.

Slide 3

Slide 3 text

A JavaScript library for building user interfaces.

Slide 4

Slide 4 text

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.

Slide 5

Slide 5 text

Where did React come from?

Slide 6

Slide 6 text

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.

Slide 7

Slide 7 text

And after lots of research and experimentation (and the right photoshop filter) he found the secret.

Slide 8

Slide 8 text

And after lots of research and experimentation (and the right photoshop filter) he found the secret.

Slide 9

Slide 9 text

Really? No, but that would be pretty crazy, right?

Slide 10

Slide 10 text

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.

Slide 11

Slide 11 text

echo
; It looked something like this.

Slide 12

Slide 12 text

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.

Slide 13

Slide 13 text

And here’s how it looks in the page. Obviously it’s much more complex than just a single button.

Slide 14

Slide 14 text

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.

Slide 15

Slide 15 text

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.

Slide 16

Slide 16 text

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.

Slide 17

Slide 17 text

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.

Slide 18

Slide 18 text

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.

Slide 19

Slide 19 text

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.

Slide 20

Slide 20 text

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.

Slide 21

Slide 21 text

So we keep the first lesson from XHP but forgot the 2nd.

Slide 22

Slide 22 text

Reusable Components So we keep the first lesson from XHP but forgot the 2nd.

Slide 23

Slide 23 text

Reusable Components Explicit Data Flow & Ownership So we keep the first lesson from XHP but forgot the 2nd.

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

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.

Slide 26

Slide 26 text

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.

Slide 27

Slide 27 text

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.

Slide 28

Slide 28 text

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.

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

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.

Slide 31

Slide 31 text

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.

Slide 32

Slide 32 text

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.

Slide 33

Slide 33 text

:shipit: So then we shipped it. First in ads, then news feed and Instagram, and then more and more.

Slide 34

Slide 34 text

:shipit: So then we shipped it. First in ads, then news feed and Instagram, and then more and more.

Slide 35

Slide 35 text

Where is React today?

Slide 36

Slide 36 text

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…

Slide 37

Slide 37 text

Aha! AirBnB AnyList Atlassian Beyondpad Brigade C5/mail CloudFlare CMN.com CustomInk Distiller EMEX ENCODE Facebook Factlink FiftyThree/Mix FINN Flipkart GetStack HackerOne Html2CoffeeReact ICX Instagram Instructure Iodine Itele Khan Academy Kupibilet LockedOn Madrone Software & Analytcs Maxwell Health Minerva Project mPATH Netflix NoRedInk Orobix PaddleGuru Palo Alto Software Patience PivotalTracker Pixate Planning Center Online Podio Posiq Quizlet QuizUp Rally Software Recurly Reddit Redfin Room & Board Rotaville Rota Software rtbl Rushmore Sauspiel SberBank the Scribbler SellerCrowd SmugMug Sonian Stampsy Storehouse Swipely The New York Times The Scribbler Timerepublik TvTag Uniregistry University of Cincinnati Venmo Versal Vida Digital Yahoo Zendesk

Slide 38

Slide 38 text

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.

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

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.

Slide 41

Slide 41 text

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.

Slide 42

Slide 42 text

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.

Slide 43

Slide 43 text

ES6 Classes One place we’re making use of new language features soon is ES6 classes for the creation of Component classes.

Slide 44

Slide 44 text

var ClickButton = React.createClass({ getInitialState: function() { return {clicked: false} }, render: function() { return ( this.setState({clicked: true})}> {this.state.clicked} ); } }; 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?

Slide 45

Slide 45 text

class ClickButton extends React.Component { getInitialState() { return {clicked: false} } render() { return ( this.setState({clicked: true})}> {this.state.clicked} ); } } This isn’t quite possible yet, but we’re getting there. We actually just landed initial support for rudimentary class support last week.

Slide 46

Slide 46 text

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.

Slide 47

Slide 47 text

var styles = { container: { border: '1px solid #000', borderRadius: '3px', color: 'red' }, active: { color: 'green' } }; return Here’s how it might look.

Slide 48

Slide 48 text

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.

Slide 49

Slide 49 text

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.

Slide 50

Slide 50 text

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.

Slide 51

Slide 51 text

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

Slide 52

Slide 52 text

github.com/facebook/react If you’re interested in getting involved, find us on GitHub. Thank you!