073 JSJ React with Pete Hunt and Jordan Walke

Download MP3



01:34 - Pete Hunt Introduction

  • Instagram
  • Facebook 02:45 - Jordan Walke Introduction 04:15 - React
  • React - GitHub 06:38 - 60 Frames Per Second 09:34 - Data Binding 12:31 - Performance 17:39 - Diffing Algorithm 19:36 - DOM Manipulation 23:06 - Supporting node.js24:03 - rendr26:02 - JSX30:31 - requestAnimationFrame 34:15 - React and Applications 38:12 - React Users
  • Khan Academy 39:53 - Making it work


Next Week

Grunt.js with Ben Alman


JAMISON:  Joe is Merrick’s personal assistant. CHUCK:  [Laughter] MERRICK:  No, we’re just in this little room and he had, he was like, “Yeah” JOE:   Want me to freshen up your coffee, sir? [Chuckles] JAMISON:  Feed me some tacos, Joe. [Laughter] [Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]  [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.]  [This podcast is sponsored by JetBrains, makers of WebStorm. Whether you’re working with Node.js or building the front end of your web application, WebStorm is the tool for you. It has great code quality and code exploration tools and works with HTML5, Node, TypeScript, CoffeeScript, Harmony, LESS, Sass, Jade, JSLint, JSHint, and the Google Closure Compiler. Check it out atJjetBrains.com/WebStorm.] CHUCK:  Hey everybody and welcome to episode 73 of the JavaScript Jabber Show. This week on our panel, we have Joe Eames. JOE:  Hey there. CHUCK:  AJ O’Neal. AJ:  Live again from Provo. CHUCK:  Jamison Dance. JAMISON:  Hey friends. CHUCK:  Merrick Christensen. MERRICK:  Hey guys. CHUCK:  I’m Charles Max Wood from DevChat.TV and we have two special guests this week. Pete Hunt. PETE:  Hey guys. CHUCK:  And Jordan Walke. JORDAN:  Hi. CHUCK:  Since you guys haven’t been on the show before, do you want to introduce yourselves? We’ll have Pete go first. PETE:  Sure. So my name’s Pete. I work on general React stuff these days. But my day job is building the Instagram web experience. If you go to Instagram.com, we have a bunch of frontend stuff you can play with and a bunch of backend infrastructure that supports all that. That’s what I mostly work on. We’re big users of React at Instagram so I ended up contributing a lot to the React core as well. JAMISON:  So did you come from Instagram or from Facebook and then to work on Instagram? PETE:  Well it was actually a pretty good story just in terms of the integration of the two companies. I was originally at Facebook for a couple of years and we acquired Instagram and they came in and they wanted to build a web presence. Facebook’s core competency is definitely web technologies and Instagram hasn’t historically focused on that. So we were able to take the Facebook web expertise and get Instagram up and running really quickly. I came from the Facebook side but the team is still very much a separate team, their own building, that kind of thing. So that’s my background. CHUCK:  Awesome. JAMISON:  Sweet. CHUCK:  And Jordan? JORDAN:  So I’ve been an engineer at Facebook for a few years now. And I focused mostly on building applications with JavaScript and also creating JavaScript Frameworks like React. So I’ve been working with Pete a lot and a number of other engineers building out this framework and fine-tuning it, optimizing it, and reaching out to the community trying to engage them and just see if it can reach a wider audience. CHUCK:  Awesome. One question I have really quick, Jordan. I was looking at the contributors on React and I didn’t see your account listed. JORDAN:  Where is that, on GitHub? CHUCK:  GitHub, yeah. JORDAN:  We have a different process for committing code to open source repos. We can commit internally or from the GitHub repo. Sometimes what you see is a large set of changes being synced from our internal repo up to GitHub. We’d actually like to improve that. It sounds like a really good idea. Just do GitHub as the authoritative repository. But we just have a little bit of work to get there. So sometimes you won’t see exactly the history. It’s not maintained correctly. CHUCK:  Oh, okay. So Pete’s getting all the credit then. Is that what you’re telling us? JORDAN:  Oh, that’s fine. PETE:  [Chuckles] I wrote a lot of the documentation and we’re moving over components to GitHub as the source of truth. So documentation’s the first thing that’s moved. So yeah, I’m stealing a lot of the blame. CHUCK:  Nice. Now I was looking at React and I have to say, on your page, or your guides, why React? That’s just an awesome title in and of itself. [Chuckles] CHUCK:  But anyway, it explains a little bit of what React is. When I looked at it though, let me put it this way. You say many people choose to think of React as the V in MVC. And then when I started looking at the code behind it and stuff, it really felt a little bit more like more than just the V. Because when I think of the V, I’m thinking templates and maybe a little bit of code to manage them. React looked like a lot more code and a lot less maybe markup. PETE:  Yeah. I’m speaking at JS Conf EU coming up and HTML5 Dev Conf, so I’ve been trying to figure out what the best way to message this stuff is. So I’m just going to beta test it on you right now and you can just give me some feedback. How about that? CHUCK:  [Chuckles] Awesome. Do we get slides? PETE:  You know, I only have my little outline in Google Docs right now. No slides yet. [Laughter] CHUCK:  Nice. PETE:  So we basically build applications as Facebook a little bit differently than your traditional MVC. But the way that most people use React in the open source community is as the View in and MVC framework. We’ve basically tried to build React such that it doesn’t matter how you’re fetching data. It doesn’t matter how you’re doing animations or AJAX or CSS or whatever, or even packaging your JavaScript. We’re just a way to efficiently render UIs and gather your user input, basically, handle user events. We’ve tried to really build a solid foundation for you to build your app how you want to do it. Just to give you a little bit of background about it, we started, Jordan actually started building React in 2011. At this point, it’s grown. We have hundreds of engineers at the company building thousands of components and we’re delivering this framework to hundreds of millions of end users. We support IE 8 and above and all recent mobile devices. We’re really, really concerned about performance. We can get 60 frames per second on a non-JIT iPhone, that kind of thing. I guess, does that answer your question? CHUCK:  Yeah, I think so. Can you give us a common use case for where people are using this? PETE:  Sure. A really common case is that somebody’s got a Backbone app. In my opinion, Backbone is a really, really great way to manage your data. Backbone models and collections make a lot of sense. But I think that one common place where Backbone tends to run into a little bit of problems is that its views system is pretty un-opinionated. When you’re really, really un-opinionated about something, it’s hard, if you just want to just get up and running and build something quickly. So we see a lot of people basically using React to implement their Backbone view. I think that’s the easiest way for people to get started. Backbone just gives you a DOM element and then all you have to do is pass that DOM element into React and React will render it and manage it for you. JAMISON:  So I’ve got to say, I think React is actually quite neat. I’ve got some questions though, particularly when it comes to some decisions you guys made about [getting]. It sounds like that 60 frames per second on a mobile device, if you guys are really able to do that, that is very impressive. JOE:   Yeah, can we get, I’m just thinking maybe there are some listeners here that don’t have a context for that. Could you give us an idea of how difficult that is to get 60 frames per second on a non-JIT iPhone? PETE:  Well, it depends on what you’re doing. For example, if you’re decoding lots of images, it’s really hard to do that. But the point is that the framework itself can run within a single requestAnimationFrame. There are also issues with garbage collection and stuff like that, but we’re basically trying to get it, the framework, as quickly as possible. That involves doing a couple of things. For example, the core is written to minimize the amount of garbage that we generate. So whenever we dispatch an event, for example, we’re pooling that event object. So every new event that comes in, every time you move your mouse across the page or something, we’re not generating new garbage. Or at least, we’re trying not to generate any garbage. We also do some really cool things with how we batch updates and how we batch reads and writes in the DOM. React is all about building components. And if you look at Facebook, for example, on every news feed story, there’s a little box where you can enter a comment and view comments and likes. If you drew a square around that, that would be a React component. Every single component on the page has a life cycle. We’ve basically built it such that at certain parts of the life cycle, every component on the page reads from the DOM and at another part of the life cycle, every component queues up the writes that it’s going to do to the DOM so that can actually keep them all batched. The DOM historically has been very, very slow and a source for not being able to get that 60 frames per second. So if you can batch those up together, you’re much more likely to be able to get there. MERRICK:  Awesome. I’m wondering, one thing that’s interesting to me is that React came out and you guys, I wouldn’t say shun, but you guys didn’t go with the two-way data binding. I think you articulate that was for the performance that you wanted to get. Either that or the maintainability of how it scales. Could you talk a little bit about that decision? PETE:  I think that Jordan’s going to probably want to take that. JORDAN:  I think there’s value in having two-way data binding but a lot of times, if you use two-way data binding, you’ll notice that a lot of the times it could have been expressed with unidirectional data binding. If we could just make that unidirectional data binding so easy because it’s a common case, at the expense of possibly deferring or just not yet solving the two-way data binding problem, it can get you to a place where you can develop applications very quickly. And you still have options for two-way data binding, but then the framework isn’t investing as heavily in those. So we do see value in that and I think that there’s room to experiment there. We’d love to see the community contribute and come up with ideas there. I would say that there are some downfalls when you just automatically reach to that two-way data binding paradigm. It’s inherently mutated. So unidirectional data binding can be functionally expressed, because functions have an input and they have an output. So that’s very much a one-way data binding. If you can express the majority of your application in terms of one-way data binding, you can write a very functional application that minimizes the amount of mutations. And the amount of mutations, when you increase the amount of mutations, your application complexity increases as well. So we’re like forcing function at this point to help you minimize the amount of application complexity that you actually build. MERRICK:  Got it. JAMISON:  You said that in lots of places, you can replace two-way data binding with one-way data binding. Can you elaborate on that idea? It seems like they’re [solving the][inaudible] JORDAN:  Oh yeah, sorry. I guess that was misleading. There are times when people use two-way data binding and what I’ve seen with more traditional two-way data binding MVC frameworks is somebody will jump to two-way data binding when they could have easily just used one-way data binding. They weren’t using the opposite direction of the binding. JAMISON:  Oh, okay. JORDAN:  They just naturally jumped to that. Now there are other cases where people use two-way data binding and you could still implement that in terms of one-way data binding with an explicitly passed callback handler that handles the attempt to change that value. So it’s just basically instead of having one value that’s like a model that can react to changes that you pass down, you just simply pass two values. One of them is a one-way data binding reactive value and the other is a change handler. So there’s a way to do it right now. The framework doesn’t automatically support this, though we could imagine creating a plugin that lets you do this. JAMISON:  Okay. That makes sense. MERRICK:  One of the other questions I had is React has this notion of updating the DOM on change events, so more of the Backbone views. That’s correct, right? PETE:  What do you mean by updating the DOM on change events? MERRICK:  Meaning, for example, if there’s a click event, I’m going to call setState which will then trigger an event which will call render. PETE:  So it’s not an event like a browser event. But the system will eventually flush to the DOM, yeah. MERRICK:  That’s what I wanted to ask, is I’ve seen some crafty things, particularly in the EmberJS framework where they’re queuing up these, they have this notion of a run loop and they’re queuing up all these state changes to flush them all at once. Is that similar to how you guys have implemented it to get the performance? PETE:  Yeah. I’m trying to think of the best way to explain this. Let’s see. Okay, so when the data changes in React, we basically, to support scalable application development, React’s guiding principle is mutation is evil and we should try to avoid it as much as possible. The idea is that if you’re program is in state 0 and then you transition to state 1 and then state 1 is dependent on state 0 and then you transition to state 2 which is dependent on state 0, it’s really, really hard to think about and really hold the whole possible states your program can be in in your head. That’s how you end up in jQuery spaghetti where you’ve updated the DOM and then you have to check all these other cases that you may have changed a node and insert it into the right place, that sort of thing. MERRICK:  Sure. PETE:  So React was designed all around that. Conceptually, how you build a React app is that every time your data changes, it’s like hitting the refresh button in a server-rendered app. What we do is we conceptually throw out all of the markup and event handlers that you’ve registered and we reset the whole page and then we redraw the entire page. If you’re writing a server-rendered app, handling updates is really easy because you hit the refresh button and you’re pretty much guaranteed to get what you expect. MERRICK:  That’s true. You don’t get into these odd states. PETE:  Exactly, exactly. In order to implement that, we communicate it as a fake DOM. What we’ll do is rather than throw out the actual browser html and event handlers, we have an internal representation of what the page looks like and then we generate a brand new representation of what we want the page to look like. Then we perform this really, really fast diffing algorithm between those two page representations, DOM representations. Then React will compute the minimum set of DOM mutations it needs to make to bring the page up to date. Then to finally get to answer your question, that set of DOM mutations then goes into a queue and we can plug in arbitrary flushing strategies for that. For example, when we originally launched React in open source, every setstate would immediately trigger a flush to the DOM. That wasn’t part of the contract of setstate, but that was just our strategy and it worked pretty well. Then this totally awesome open source contributor Ben [Alfred] at Khan Academy built a new batching strategy which would basically queue up every single DOM update and state change that happened within an event tick and would execute them in bulk at the end of the event tick. MERRICK:  Awesome. PETE:  That was a pretty huge performance win on our ads create flow, for example. You can imagine, since we’ve made all of this pluggable, we have some other cool ideas that might be interesting. For example, we just always flush at the end of a requestAnimationFrame. So if you get multiple AJAX requests coming back in a single animation frame, which is a pretty common thing to happen, it’s just as fast as if it was a single one. MERRICK:  Yeah, that’s actually a really interesting idea. Almost like you’re just going to mutate the state and paint it, kind of how you would implement a canvas app, almost. PETE:  Yeah. MERRICK:  Way more traditional UI. You get rid of a lot of the issues of writing against the DOM. PETE:  Exactly, exactly. I don’t know if Jordan’s going to agree with this, but there’s this guy online. I think his name is Fabian something and he deconstructs the Doom 3 engine source code and talks about how the game logic interacts with the renderer and interacts with the graphics card. And it looks very similar to how we structured React in that we have your application logic which is doing whatever you want, manipulating this fake DOM, and then we pass it to this rendering system that does that DOM diff and queues up those DOM operations. Then rather than OpenGL calls to a graphics card, we’re just sending DOM mutations to the DOM. So it was a nice validation of the structure of React. MERRICK:  Yeah, see that’s really interesting. I think it’s really great that we talked about this on the show because most people probably open up the React homepage and they say, “Okay, they’re adding a declarative aspect to Backbone,” but clearly you guys are doing  way more than that, which is awesome. JOE:  One of the things that struck me is you said that your diffing algorithm was really fast, which typically wouldn’t, it doesn’t sound like something that was going to be fast. Can you explain that a little bit more? JORDAN:  Yeah. It’s not just about the CPU efficiency but it’s also about memory efficiency. The key part here is that we’re not doing this with DOM constructs. When you manipulate a DOM node, you’re likely breaking outside of the BM into some native code. We believe that that context switching is actually very expensive. So we’re doing this in pure JS representations, which is already a win. But one of the interesting things is that by default, this algorithm is just heavily optimized because we’ve invested a lot in it and it’s very critical to our site. But there are also other hooks inside of the components that allow you to [poke]/guide that process along when it comes time to optimize. So by default, you can just assume everything re-renders and for most cases, you’ll never have to optimize anything. For your standard webpage, for your standard app that you’re building, you’ll never even have to think about it. But we give you a way to hook into the component. At the component level we give you a way to hook in and help tell React when it needs to update a certain part of the page and when it doesn’t. But the really cool thing is that that optimization code is totally optional and it can be added later and it doesn’t become a core part of your development paradigm. So you’re not prematurely optimizing your app when you don’t even know what the general structure’s going to look like. Does that answer your question? JOE:   Yeah, absolutely. That’s great. That’s great. It seems like a really innovative idea to do it that way as well. I really like that idea of just determining what’s different and what’s not and figuring out and repainting it. Obviously, when you think about implementing something like that, it sounds like, “Oh my gosh, it’s going to take me a year to figure that kind of a thing out.” CHUCK:  Did you write your own DOM manipulation library or are you using something like jQuery? PETE:  We have our own DOM manipulation library. CHUCK:  That’s more or less what it sounded like. JORDAN:  It’s just highly optimized for the case of these large flushes. If we used another library, it probably wouldn’t perform as well. PETE:  We don’t actually do that complicated of DOM manipulations at the end of the day. We’re setting inner html, adding/removing nodes, and modifying attributes on a node. And we have a giant file in there called, or it’s not giant, but we have a file called, I think it’s DOM mutation strategy or something, that basically says if you’re updating a style attribute, this is the fasted way to do it, and all that kind of stuff. So it is abstracted. JORDAN:  Right. The event system though, is interesting in itself. It’s completely synthetic and it’s actually pretty standalone. You could imagine using just the event system in another framework. What it is, is it completely re-implements bubbling, capturing and stopping the propagation, in a completely virtual way that doesn’t rely on any DOM nodes at all. So what’s cool about that is it has an injectable plugin system where you can write your own events. For example, we have an event called onEnter, onLeave, which is like Microsoft’s enter/leave events, but it works on all browsers. And you can just gracefully inject these plugins that sit there and listen to this raw stream of low-level keyboard and mouse events and infers higher-level ones. So you can write your own, either double tap or long press or anything like that and then share it with other people so they can easily use it. MERRICK:  That’s really cool. And one thing I really liked, and maybe I’m off base on this, but I believe you guys actually hoist all the events, right? That’s something I think is really neat about the way you guys do it, is you actually hoist all the event listeners up for performance’s sake. JORDAN:  Oh yeah. PETE:  Oh yeah. Yeah, it’s all just a single, almost all the events are just listening on the top-level document. So you get the event delegation performance boost for free. You don’t even think about it. MERRICK:  Yeah, which is just awesome. PETE:  So another cool thing that is implied by this is I have a branch, I’m not sure it’s really worth doing at this point, but it only took maybe a day or two to get your entire React app running in a web worker which has pretty cool implications because we’re pretty paranoid about performance. And if you only do the DOM manipulations in the main thread, then it makes scrolling a lot smoother and that sort of thing. So the reason we’re able to do that so easily is for a couple of reasons. First of all, React barely knows that there’s a browser. Only the event plugins know about the browser and the fundamental DOM manipulation library knows about the browser. Everything else is in this synthetic fake browser world. So that’s pretty sweet. The second thing that lets us do that is since we have not committed to a standard way to do two-way data binding, the framework itself is never reading directly from the DOM. The users themselves have to read from the DOM. A lot of the pain of keeping the DOM and the virtual world synchronized is a lot easier without using two-way binding. MERRICK:  Yeah. So one other thing I’ve got to ask. If you have all this virtualization, et cetera, you’re working with strings, it seems like you guys wouldn’t be far off from being able to run in the Node.js runtime, so people could render the React apps on the server. PETE:  We already support that. That is a feature in 0.4 that came out a month ago. We fully support running in Node.js. MERRICK:  That is awesome. AJ:   Wow. JORDAN:  If you stay tuned, within the next week, we’ll likely be open sourcing a starter app where basically it’s one-click or nmp install and you have a fully server-rendered application with simple routing to pages. You just write your components as if you’re rendering them on the client and they just work on the server. They just work on the server, the markup gets send over to the client, and the event handlers get wired up automatically. You don’t even know it’s happening. MERRICK:  That’s awesome. CHUCK:  That is amazing. PETE:  And have you guys heard of Airbnb’s rendr framework? MERRICK:  Yeah. PETE:  So there were like, I was working on the server rendering feature internally and then they launched that. I was like, “Man, they stole our fire,” because they have a really awesome, “Oh, it runs both on the client and the server. You don’t have to think about it.” So I ended up meeting up with those guys and Airbnb and within our 30-minute meeting, we were able to get React rendering within rendr. And rendr, if you guys aren’t familiar with it, is just a way to run a Backbone app in Node.js or in the browser. So there are a lot of cool advantages for those listening that don’t see what’s so exciting about server rendering. We can serve up the server-rendered page to Google Bot, for example and get your ranking up because Google Bot penalizes client-rendered pages because of performance. You can also get that really, really fast first page load experience. So imagine you write your JavaScript app just like you normally would or your React app just like you normally would. Then you just flip the switch to turn on server rendering and suddenly you don’t have to wait for the JavaScript to download for your user to see the initial page. You can also manage tradeoffs on mobile devices. So for example, some mobile devices might not want to render certain components in JavaScript. You might want to render them in the server and just parse the html. We can do all of that. And it’s actually a pretty elegant situation where you simply tell React, “Here’s my component and I want you to render it into this DOM node.” And the first thing that React is going to do is it’s going to look at that DOM node and be like, “Hey, does it look like React generated markup in this DOM node?” and if it’s not there, it’ll generate the markup for you. If it is there, it’ll skip the markup generation step, just register the event listeners, and you’re good to go. And we have a way of basically hashing the markup to ensure that it’s correct and that kind of thing, that’s really fast. MERRICK:  That’s awesome. PETE:  Yeah. JAMISON:  That’s really impressive. MERRICK:  Yeah, that’s super cool. I think one other question. You guys have this optional JSX. Traditionally in the web community, and this is probably more FUD than anything else, but there’s this huge aversion to XML. JAMISON:  Yeah, that was a bold move to put the letter X in there. MERRICK:  Yeah, so my question is do you find that most people are writing with the JSX syntax or without it? And why do you have that declarative style? Is it composable, et cetera? JORDAN:  I think I would say, Pete you can correct me if I’m wrong, but I’d say over 60% of people give it a shot and they stick with it. Then some people just choose not to and that’s totally cool. Is that about right, Pete? PETE:  It’s probably more than that. I think the people that tend to not use it are using CoffeeScript or something. JORDAN:  Okay, yeah. So a lot of languages had this embedded XML syntax. Scala has it, ActionScript 3. And I think there’s some part of that that’s actually good and some part of that that’s actually bad. One of the things that I don’t appreciate in languages that embed XML is that they typically have this whole other semantics to it. It’s a runtime. It’s a library and it’s not just a syntactic sugar. And E4X, which is a variant of JavaScript that had this exact syntax, it also came with this other weird operational semantics that was totally different than regular JavaScript, had its own runtime library. It was just a mess. But we actually liked the look of it. And I think a lot of people liked the look of it. And that’s why they like templates. So what we built with React is not about the syntax. It’s more about functional programming. It’s about minimizing state mutations. It’s about the virtual DOM. But for people that really just love their templates and they love how they look, we wanted to give them a way to be able to structure their JavaScript applications without giving up that very balanced structured look of their application. So if you were to write a large app in React with just JavaScript and no syntax extension, you’d notice that it gets difficult to balance those braces with your eyes as your JSON gets really large. Have you ever noticed that? MERRICK:  Yeah, for sure. JORDAN:  So then the JSX extension, it just simply helps your eyes balance, “Okay, well this is the start of that div and this is a span embedded inside of that.” It’s not meaningful to the framework at all. We use it internally so we though, “Hey, why not just open source this too and see if people like it.” PETE:  Yeah, and the XML part is just because XML has a very strict notion of opening and closing a tag. Since we basically just translate this markup straight to JavaScript function calls without any sort of crazy transformation, it’s just a little more explicit where your parentheses are going to open and close. MERRICK:  Does it allow nesting? Because all the examples seem to show just one instance of a component. So it’s like, “Here’s how you would implement a hello message and then this is the declarative way to consume it,” and I guess I’m wondering can you put a hello message and then put something else inside of that and put something else inside of that with some attributes, et cetera? PETE:  Oh yeah. This is the big advantage of components over templates. We got a lot of flak for not embracing templates and mixing our markup and our logic in the community initially and we did a pretty poor job of messaging why we think that’s a good idea. We’re big proponents at Facebook for separating concerns in a way that makes sense. So we basically think that separating your markup and logic, that’s not real separation of concerns. That’s separation of technologies. If you think about separation of concerns in terms of coupling and cohesion, like the display logic that drives the markup is going to be intimately coupled together. They are a cohesive unit because they’re both displaying the data. So we basically combine them into a notion called a component. And a component is just a way to render one part of your UI. And one really, really powerful part about components is that they are composable, so you can nest one component inside another and build components out of other components and they’re all reusable. So we think that that’s a huge advantage over templates and you basically use components to separate your concerns. We don’t think that the framework or the library can separate your concerns for you. We just want to give you the tools that are powerful enough for you to do it for your application. So to answer your question, yes you can and we encourage it and we think it’s really, really important. MERRICK:  Awesome. AJ:  So if I can butt in here for a second. I want to go way back to earlier where you were talking about requestAnimationFrame and optimization and I have not yet used requestAnimationFrame. When I first started hearing about it, it was just something that was experimental. It sounds like now, it’s probably been a year since I’ve heard people really, the big buzz about it. So can you explain a little bit what requestAnimationFrame is and how you’re using it to get performance? PETE:  Sure. So we’re not actually using it in React to get performance. We haven’t really found a need for it yet, but it’s an area that we are exploring and experimenting with. What requestAnimation does is it basically says, it’s a function provided by the browser and it takes a function that you pass in. AJ:   So is it like window[dot]requestAnimationFrame or window[dot]document[dot]? PETE:  It’s actually, I think in mobile browsers, it’s window.webkit.requestAnimationFrame and moz.requestAnimationFrame but in Chrome I think it’s un-prefixed. But yeah, it’s on window. AJ:  Is that for the whole document or is it for a specific subset? PETE:  It’s for the whole window. AJ:   Okay. PETE:  So the idea with requestAnimationFrame is it will call your function to run right before the browser paints the next page. So the browser paints at 60 FPS so it will call your function within the next 16 milliseconds. And a lot of people are using it to do frame by frame animation and that sort of thing. The reason why I mentioned it earlier was we were talking about batching up operations and doing them all at once to save on performance. So you can imagine, if you do a data fetch and you’re fetching a bunch of data, maybe it’s a Backbone model or something, potentially that might trigger a lot of change events on your Backbone app. Now, if we were using a naïve strategy, every single time one of those change events fires, it would mutate the DOM. It would basically do that diff of the trees, compute the DOM mutations and then execute those, flushes DOM mutations to the DOM. And it would do it for each one of those change events. If we were to theoretically implement one based on requestAnimationFrame, we could basically wait until all of those change events have happened and then do the diff and then flush the DOM. This is not a feature that’s currently in the open source. It’s something that we’re experimenting with. But I think we’ve all thought that it’s an interesting idea and it’s a way that we could get some more performance and it’s a pluggable part of the API. So someone in the community could go and build it. AJ:   So off of that, have you guys had the experience where, in Chrome in particular, have noticed that you get artifacts? Like if you scroll down a page too quickly or if you’ve got one of those CSS selectors where it’s every nth row of a table and artifacts are left over. Do you ever experience that? PETE:  What sort of artifacts? Paint artifacts or the DOM is out of sync or something? AJ:  Yeah, like one of the nth rows is grey when it should be white, or you scroll and part of a text gets stuck in that place where it was where nothing should be. Because I’ve encountered this when I’ve been changing five things at a time, which to me doesn’t seem like a lot, but it just makes me wonder about maybe the requestAnimationFrame would solve that. PETE:  For us it’s more about the general idea of batching rather than requestAnimationFrame. AJ:   Right, right. PETE:  I’m not sure. It really depends, I think, on the individual situation where you see that. And I could probably speak further if I had an example in front of me. JAMISON:  So I want to jump in and ask a little bit about React with other JavaScript frameworks or technologies. At first glance it looks like, “Oh this is a great way to handle the rendering portion of your application.” But some of your comments have made it sound like you described how you think the divide between logic and templating is artificial. So how do you see React fitting in with applications? Do you use it as a view layer and use something else to hook together your application? Do you build your entire app just completely with React? How does that work? JORDAN:  You know a lot of people are used to having this, as you described it, this artificial divide between a view and then something that controls that view. I think that’s a great place to start. In fact, a lot of times, Pete and I will start that way when we build an application. But then we realize that this controller logic that’s controlling this view, that’s actually something that we want to be able to reuse. So we want to be able to nest that inside of maybe another view. Then we realized that that line that we usually started with between that view and that control logic, it was artificial to really consider that special when we want to package up that whole thing into another component and embed that somewhere else. Does that make sense? And Pete, do you agree? PETE:  Yeah. That’s going back to composability and components being the language in which you express your separation of concerns. I could chime in about the Instagram-specific use case. JAMISON:  Sure. PETE:  When we came to Facebook, I joined the Instagram team and Facebook had deployed React on a couple of smaller components, but it hadn’t really been used on a huge app yet. So we ran with it and took it really, really far. For example, Instagram.com is like a “single-page web app” in that we actually do run Backbone router and when we get a route change event, we just call setstate on our overall page chrome component to switch pages. We basically, I’ve glued Backbone router to a controller component or a component that fulfills the role of a controller. Then in terms of how we manage data fetching, we use Backbone models in some places. But we’ve adopted just more of a, since the Instagram data model is not particularly complex, we can get away a lot of times with just simple AJAX requests to the server and back. CHUCK:  Awesome. I’m really looking forward to playing with this a little bit more than I have and digging into it. Are there any other aspects of React that we haven’t talked about that are interesting? PETE:  Jordan, do you have anything you want to cover? JORDAN:  No, I think React’s actually, as intricate as the implementation is, the API and the paradigm is incredibly simple. It’s just functions that compose other functions basically. And those become your components. And if you can just grasp that very simple paradigm and run with it, you can actually get really far. So from here, I think what you just have to do is try it out and try building things with it and that’s how you gain a really deep understanding of it. PETE:  Yeah. It’s relatively new in the open source world. I think we launched it a couple of months ago. But we have been building it for a long time. And we do have lots of engineers of varying degrees of skill with JavaScript using it. And we also have designers regularly contributing tweaks to React code and stuff like that. So even though we’re fairly new on the scene, we do have a lot of boots on the ground experience using this in real apps. JAMISON:  Is it used for most new JavaScript stuff at Facebook or is it there’s a group of people who choose to use it for the JavaScript but it’s not everyone who’s doing JS is using it? PETE:  Jordan, correct me if I’m wrong, but I think that all new JavaScript app products on Facebook are using this, right? JORDAN:  I don’t really run into people that often that don’t want to use it. So yeah, I think there might be a couple of places where it just doesn’t quite make sense yet, just because it’s an existing project or something. JAMISON:  Sure. PETE:  But yeah, we’re using it for our flagship stuff. When you want to create an ad on Facebook, we’re building that with React. That’s a pretty important thing for us as you can imagine. Liking and commenting on Facebook is all powered by React. That’s another hugely important thing for us. Basically, tons of new projects are using it on Facebook. CHUCK:  So half the web is using it because Facebook is using it. [Chuckles] JAMISON:  Yeah, that’s it. Even if you say, “Oh, no one besides Facebook uses this,” that’s hundreds of thousands of engineers, right? That’s a lot of people still. CHUCK:  And it’s millions and millions of users. JAMISON:  Yeah. Do you know if people outside of Facebook and Instagram that are using it? PETE:  Yeah. I know that Khan Academy has contributed a lot back to React. I think that they’re rebuilding a ton of their stuff in open source, actually, in React. So if you go on GitHub search and you type React.createClass which is our way that you create a React component, you’ll just see tons of production code that Khan Academy is building. And you can see this is how a real complex web app uses React. They’re the biggest one that I know, but we have a lot of people who are active on the Google group and on Twitter and that kind of thing. CHUCK:  So I want to go a little bit deep. I haven’t looked at the source code for React. But you mentioned just briefly that you weren’t using another DOM library like say jQuery or something, so that means that you probably had to deal with all of the idiosyncrasies of making this work on different browsers, different platforms, and different devices. Has that been a real pain point for you or is it sort of well-documented if you go and dig through jQuery source? How did you do that? PETE:  Well, first of all, there’s a huge team that contributes to React. It’s the Facebook user interface engineering team, product infrastructure team, Instagram web. We’ve all been through the trenches. There’s a lot of institutional knowledge there because Facebook targets IE 8 and above. Note a couple of things, we already had a bunch of DOM manipulation libraries at Facebook that worked really well. I think the biggest thing is that we have a very, very popular web app. We push out, basically the master of React every week to all of our users and we support IE 8 and we have really good logging. If we break something in some weird browser, we know really quickly. That’s a pretty nice way to go about it. JORDAN:  Also, QuirksMode.org is your friend. They basically have all of the different browsers. It’s an excellent site. Between that, looking at the jQuery source code and accumulating all of that knowledge, we’re definitely standing on the shoulder of giants [of] other framework developers that have figured a lot of this out. CHUCK:  So you mentioned QuirksMode. Do you write any of this in strict mode? PETE:  It’s all strict mode. JORDAN:  Yes, it’s all strict mode. But the website itself is a really good hub for documentation about all the different browser quirks, what works where, and it’s definitely a favorite of mine. CHUCK:  Awesome. MERRICK:  Is there a performance implication of using the JSX and do you guys have a precompiler to resolve that? PETE:  Yup. We ship a command line tool. You just nmp install react-tools and it’ll give you a JSX command that will take your JavaScript file with JSX in it and it will turn it into regular JavaScript with just function calls. And we’ve paid pretty close attention to making sure that your line numbers will always be the same. So there are a lot of people that will write their files with JSX in them and name them .jsx and then run this command on all of their .jsx files and translate them to .js files. Then you could run your standard linting and packaging tools right on your tree. If there’s a lint error, you can look right at the correct line in your jsx. MERRICK:  That’s pretty cool. So I know that a lot of the precompilers end up like handlebars. You have RequireJS integration. Does React also support that kind of thing? PETE:  Internally we use CommonJS modules so if you build, if you git clone the repo and you run our grunt task, you’ll get a directory full of CommonJS modules. I don’t work on the open source packaging too much but I believe that the CDN hosted version that you download is like a UMD, which I think is usable from RequireJS and Browserify and Node and all that stuff. MERRICK:  Yeah, global all that. Awesome. PETE:  But I’m not the expert on that. I might be wrong. MERRICK:  Well that’s great. PETE:  We really want to play nice with all other tools. We don’t want to solve every single problem. And if you want to use React, you shouldn’t have to use our build system too. You know what I mean? MERRICK:  Yeah, that’s awesome. CHUCK:  Cool. Well it’s been a pretty awesome discussion, but we’re running out of time. So I’m going to push us over to the picks. Joe, why don’t you start us off this week? JOE:  You always make me go first, Chuck. CHUCK:  I do? JOE:  You do. JAMISON:  Because he loves you the best. JOE:  I think that’s because he hates me the most. CHUCK:  Nobody can steal your picks if you go first. JOE:  Have somebody else go first. CHUCK:  Jamison, what are your picks? JAMISON:  [Chuckles] He’s like, “I’m fed up with this crap.” CHUCK:  [Laughter] JAMISON:  Alright. I have three picks. My first pick is a slide presentation by a local developer named Ben Mabey who is brilliant. It’s just a little, well not little, it’s 300 slides long so it’s enormous. But it’s a really in-depth intro to Clojure. It was done at a Java users group, so it’s from the perspective of Java developers. But if you know a little bit of Java, it should be pretty comprehensible, even if you’re not a Java developer. And also, Ben is amazing. My next pick is just the JSConf 2012 videos. I watched the React presentation that these guys did at JSConf then I started watching some other of them as well and they’re just awesome. JSConf is, in my opinion, the best JavaScript conference. So it’s sweet that they put all their videos up for free. And my last pick is kittens. I just got kittens last Saturday and I’m like that new parent that can’t stop showing new videos of their kids and pictures and everyone’s like, “Oh my gosh. Yes you have a kid. Okay.” But that’s me with kittens. Those are my picks. CHUCK:  Alright, AJ, what are your picks? AJ:  So I’ve been watching the PBS Idea Channel on YouTube and they recently just put up a video on, is the internet kittens? And going into the semantics of how you define what something is and the relationship between kittens and the internet and also mentioning that Google’s artificial intelligence cluster that they created recently some 16,000 clustered node, when it was given a bunch of random images from the internet, was able to categorize the kittens just because there are so many of them. So they just have a lot of interesting stuff on the PBS Idea Channel and so it’s just something fun to watch for five or ten minutes here and there. Also, I finally actually set up a website with SSL with my own certificate and instead of having to pay the average $100 - $300, I got a free trial one from Komodo and it was a pretty painless process. It was really easy to set up with Node because they have instructions on the site exactly what you need to do with all the different pem files and all that. So that was cool. I appreciate their free trial. I think it’s 90 days or something. But it’s enough to play with it and decide whether or not you want to use it and get familiar with the process. Then lastly, I deejay and I was deejaying my friend’s reception last week. I commonly run into this problem where I’ve got the mic but then the volume control is over at my computer and I’m over by the bride and groom and the computer is over in some inconspicuous area. So I’m not able to control the volume. So I got frustrated about that, after that, and then I went home and I wrote an app for controlling the volume on my Mac from my phone. And it was cool. Then I made a little turn server, well not really a turn server but like a turn server, a port forward mechanism that sits out on the VPS so that I can control it even when there’s no Wi-Fi on my phone because the phone doesn’t get Wi-Fi very good. CHUCK:  Awesome. Merrick, what are your picks? MERRICK:  So my first pick is JS Git by Tim Caswell. He gave a short presentation here about that. Very interesting stuff. He’s trying to implement Git in JavaScript with multiple platform support, so not just the browsers but Node, which is interesting when it comes to different storage strategies, et cetera. So that project I think is just awesome. My second pick is vim-airline. If you guys are powerline users and you don’t use it for tmux or any other of those shells, I would definitely recommend switching to airline. It’s all written in vim script. You don’t have to have any of the Python bindings. So I think that’s awesome. And yeah, those are my two picks. CHUCK:  Awesome. Joe, what are your picks? JOE:  Alright. I’ve got three picks. My first pick’s going to be soccer. [Chuckles] CHUCK:  I love soccer. I wish I had more money for soccer. JOE:  Yeah. I know. It definitely draws a lot of my paycheck. But I love soccer. I have season tickets to the local MLS team, major league soccer team. And specifically, I’m going to pick the MLS Live service. The URL is in the show notes. It’s live.MLSSoccer.com. Basically what they give you is the ability to watch every soccer game every week, there are 17 of them in the major league soccer, a 15-minute version of the game. So just all the more interesting action. So I use that and pretty much watch every game every week and just love it. For those who might find soccer a little bit boring, that gives you a version of soccer that’s a lot more exciting. I wish that the NFL offered that, because four hours just to show one hour of actual action is a bit much for me. And then I’m also going to pick the book Seraphina, which is like a young adult type novel. But it was absolutely awesome. I zipped through it. It was four or five hundred pages. It was actually quite long. But I just plowed through it because I really enjoyed it and thought it was well-written. MERRICK:  What’s it about? JOE:  So it’s about these humans and there are dragons that could turn into humans and they’ve made peace but now there’s somebody trying to destroy the peace and this girl who’s caught in the middle of trying to keep the peace. It’s just a great story, just very well written, great characterization. I didn’t feel like it was pandering to the young crowd, but it was well written so that a teenager would enjoy it as much as an adult. Much like Harry Potter. I just thought it was a brilliant book. MERRICK:  Cool. JOE:  And then my last pick is going to be ng-conf for the few people who listened to this episode and haven’t listened to the last couple of episodes. I’m picking it yet again, ng-conf.org. It’s an Angular conference. It’s going to be two days of listening to the Angular team from Google talk about Angular and other Angular experts talk about Angular. It’s going to be help in Salt Lake City, Utah in January of 2014. It’s going to be absolutely awesome. I’m having an absolute blast helping to organize for ng-conf. JAMISON:  That is not a phrase I would expect to hear. You’re having a blast helping to organize a conference? [Laughter] JAMISON:  I’ve heard that’s always been a thankless arduous task. MERRICK:  [inaudible] I think it’s been a blast, yeah. Oh it’s been ton of fun, actually. JOE:  Yeah. It is a lot of work. It’s eating up a ton of my time. But it’s really fun to create something and to build something bigger than yourself. And the guys that I’m working with are completely awesome. MERRICK:  Aww. JOE:  So ng-conf.org. That’s in the show notes. CHUCK:  Terrific. JOE:  Follow us at @ngconf on Twitter. CHUCK:  Alright. Well I’ll go ahead and go next. One pick that I do want to make is that I’m still looking for work. So if you need to hire me, I do JavaScript in Ruby. I’m picking up iOS programming. So feel free to give me a call or email me and let me know if you’re interested. Other than that, I’m going to pick a couple of things. I’m pretty sure they’ve been picked on the show before, especially since we talked about screencasting last week. But I’ve been doing quite a bit with the screencasting lately, so I’m going to pick ScreenFlow. And the other pick I’m going to have, I used this for my Ruby on Rails course. It’s GoToMeeting. Both of those are just awesome. They’re great tools. They make it really for me to put on presentations for my students and then ScreenFlow lets me record it and put it up. Pete, why don’t we hear your picks next? PETE:  Cool. So someone mentioned cats earlier and it just made me think of this Instagram account that I follow that I’m really interested in. Instagram.com/syriandeveloper. He’s a software engineer who lives in Syria and is watching all of this madness unfold and it’s really interesting because you’ll go from photos and videos of riots and destruction and stuff like that to him messing around with his cat. You know what I mean? A very standard internet style. So it’s like this really humanizing element to some stuff that you wouldn’t normally see. So definitely check that Instagram account out. The next pick I have, it’s probably something that everybody uses, but is jsFiddle. I found that more and more of my development is sadly taking place in jsFiddle. [Chuckles] PETE:  Just because it’s a great platform for experimenting and sharing. I just use it a lot to share ideas with people. So I definitely have to give a shout-out to jsFiddle. And the last one is this app called Hotel Tonight. Especially with people using smart phones and stuff, we’re gradually moving to this world where you don’t have to plan ahead for anything. And Hotel Tonight definitely takes it a step in that direction. You can book a decently priced hotel the same day, which is pretty crazy. JAMISON:  That’s saved my butt one day at a conference. I was staying at an Airbnb house with a married couple and the married couple broke up while I was there and it was really awkward and I left them. [Laughter] JAMISON:  So I had to get a hotel room. That’s what I used. JOE:  Oh my gosh. PETE:  That’s the worst. So those are my picks. CHUCK:  Because all of a sudden the husband wanted the couch, too? [Chuckles] CHUCK:  Alright. Jordan, what are your picks? JORDAN:  I actually was going to say vim-airline. I think it’s a great vim plugin. Everybody should check it out. It’s lightweight. But non-technology related, I’ve been enjoying Green Flash Brewery lately. And one beer that they produce in particular is called Palate Wrecker. And the name is pretty indicative of what you should expect. It’s a very, very bold IPA. And after you have this beer, you just can’t have any other beer because every other beer just tastes like water. So I definitely recommend checking this one out. So apart from that, I would say all things vim. I’m so appreciative of vim. It’s made my life so much better and it’s improved the lives of so many developers. And after you use it, it just becomes this extension of your body. And you can’t use any other editor. So there are a lot of people trying to bring the vim key bindings to other editors. One of them is called Vintagious and it’s a Sublime extension that lets you have a very vim feel and I wanted to plug that and see if people are interested in that product on GitHub. So fork it and try it out. CHUCK:  Awesome. Alright, well thanks for coming guys. It was a terrific discussion. And hopefully, we get a few more people out there looking at or trying or even using React in production. PETE:  Yeah, thanks for having us. MERRICK:  You guys are great. JAMISON:  Yeah, this was great. There has been a lot of technical knowledge bombs dropped. There’s tons of stuff spinning around in my head right now. So this has been really good. CHUCK:  Yeah. PETE:  Well, we’ve got a Google group and an IRC channel on Freenode. So feel free to drop by. It was super fun talking to you guys and I hope that we can talk in the future, too. JORDAN:  Yeah. CHUCK:  Awesome. Thanks again. PETE:  Alright. Have a good one, guys. JAMISON:  You too. AJ:  Ciao. CHUCK:  See you all next week.

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.