$30 off During Our Annual Pro Sale. View Details »

React Through the Ages

React Through the Ages

A brief overview of this history of React, where it stands today, and where we're headed.

This talk was presented at dotJS on November 17, 2014.

Paul O’Shannessy

November 17, 2014
Tweet

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

  3. A JavaScript library
    for building user interfaces.

    View Slide

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

    View Slide

  5. Where did React come from?

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  11. echo ;
    It looked something like this.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  35. Where is React today?

    View Slide

  36. 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…

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  44. var ClickButton = React.createClass({
    getInitialState: function() {
    return {clicked: false}
    },
    render: function() {
    return (
    onClick={() => 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?

    View Slide

  45. class ClickButton extends React.Component {
    getInitialState() {
    return {clicked: false}
    }
    render() {
    return (
    onClick={() => 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.

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide