[JSConfUS 2013] Tom Occhino and Jordan Walke: JS Apps at Facebook

[Music] uh I'm Tom okino thank you Chris first of all uh I'm going to talk a bit about how we do JavaScript application development at Facebook we're going to do something a little different Jordan is actually also going to to present he's going to do some of the technical

stuff I'm going to talk about the fluffy I'll get it out of the way quick uh first of all we asked ourselves this question many many times how should we structure JavaScript applications and more specifically JavaScript applications that run in a web browser we're using node and doing all that fun stuff too but I'm more interested in the user interface side of things so that's what we're going to talk about today there are a lot of JavaScript Frameworks that aim to answer this question uh these Frameworks have allowed us to move the web forward as a real application platform if Peter Higgins is the room I want to call out that dojo is up here cuz Dojo did it

first as he would say or Dojo already did that um but the consensus is basically that an MVC style architecture is best and it's not just MVC right it's mvvm or as angular calls it model view whatever I really like that one I actually really like angular in the the declarative data binding I think that's kind of the Holy Grail in terms of apis all of these architectures in Frameworks have one thing in common though and that's models so typically models in these Frameworks Works

Implement observable objects with an advents API developers use bir directional data binding to bind their views to their models as your models change your views can be updated and as your views change they can update the models which then propagates out to other views excuse me so this observable model pattern encourages mutation though and mutation is complex so a few years ago starting with

our chat rewrite we tried to start structuring our application a little bit differently we wanted to minimize the amount of mutation that developers had to deal with mutation is a necessary evil you have to deal with it but we want to minimize the amount of mutation that developers have to code themselves so let me show you what I mean by that here's the structure for a simple application in this diagram you'll notice that all updates go through a single flow so all updates including user input they go through a single

Channel this is one directional data binding those updates eventually reach the views and the simplest way that we have found conceptually to structure and and render our views is to just try and avoid mutation Al together so what I mean by that is anytime any of your data changes just blow away your view completely and render it from scratch now I know what you're thinking that's not going to work right the Dom can be slow you know browsers are going

to be it's going to be prohibitively expensive to try and do this to try and just Reiner HTML everything every time anything changes especially in a real-time app or something that's really interactive so you know conceptually this is what we're going for though this is what we want we want to build something that gives us the conceptual Simplicity of rendering from scratch on every single event um but you know without the overhead because that's prohibitively expensive so about 18 months to 2 years ago and missing the

exact date uh we started working on a JavaScript library that helps us do that and we call it react so that was all the fluffy stuff uh and I'm going to let Jordan come up and talk about some of the the more technical details of this thanks all right so like Tomo was saying uh one of the things that we strive for when we when we're um building our component framework is that we want to minimize the amount of developer facing mutations uh that the developer exposed to and so react takes a approach in a few ways the first is