The Changelog: Software Development, Open Source - React, React Native, Flux, Relay, GraphQL (Interview)

Episode Date: March 27, 2015

Christopher "vjeux" Chedeau and Spencer Ahrens joined the show to talk about React, React Native, Flux, Relay, and GraphQL. They also announce on this show that React Native is now open source on GitHub.

welcome back everyone this is the change log and i'm your host adams dekoviak this is episode 149 and on today's show we have some awesome guests from facebook christopher chateau and spencer aarons both software engineers at Facebook on the React team. Got some great announcements today too as well. We talked about React, React Native, especially React Native going open source. The

announcement came yesterday at Facebook's annual conference for developers F8, as it's known. We also talked about Flux, Relay, and Graphl in depth great conversation today with those guys from facebook we also had some awesome sponsors for the show code ship top town and digital ocean we'll tell you a bit more about top town digital ocean but our friends at code ship specifically someone who's super impressed with CodeShip and how it helps them ship faster is a CTO at

Product Hunt and I quote at Product Hunt we use CodeShip as the backbone of our team's test and deployment processes and Andreas has lots of great things to say about CodeShip and the way they help them perform but specifically they're using Parallel CI a brand new feature that helps them deploy 10 times faster and if you want you and your team to ship faster, you have to run your builds in parallel. With Parallel CI, you can now split up your test commands in up to 10 test pipelines. This lets you run your test suite in parallel and drastically reduce the time it takes to run your builds. They integrate with GitHub and Bitbucket, of course.

You can deploy to cloud services like Roku, AWS, and many more. And you can get started today for free with their plan that gives you 100 builds a month and five private projects completely for free. Or you can use our offer code when you upgrade, and that code is thechangelogpodcast. And that's going to get you 20% off any plan you choose for three months. So head to codeship.com slash the change lobby to get started. And now onto the show. Hey everybody, we're back.

We got the folks from Facebook here talking about React.js. A lot of other fun stuff that's coming out of React.js, React Native, Flux, Relay, GraphQL, a lot of fun stuff. Christopher, you're here. And Spencer, you're here. Welcome to the show, my friends. Glad to be here. Yep, same here.

And Jared, we also got you on the call as well. We can't forget you, man. You're such an awesome man. Don't forget me, man. No way. We would never forget Jared. I'm excited to be here. I'm excited to hear about React.

So we've been planning this call, I think, behind the scenes for a better part of a month and a half. Just trying to pin down the best time to get you guys on the show to talk about what you're doing with React.js. Can we kind of intro each of you, sort of talk about the React team, and then we'll go into more of an introduction of what React is, and then go into the rest of the story. Yeah. So my name is Christopher, and I heard about React about a year before it was open sourced. And this was Jordan, who showed me a prototype of some crazy functional libraries that he was working on.

And his whole idea was to, we're going to re-render the entire app on every single update. And this sounded like crazy inefficient and everything, but I realized that if this was efficient, then it will solve so many problems with so many bugs that we have with apps and that are all related to updates. And so I didn't think about it for two weeks. And then I was like, oh, maybe I should try it. And I tried it. And even if it was super alpha, it was extremely fast.

Faster than my manual dog manipulation I could write. And I was hooked that day. And so for basically a year, I convinced my entire team and all the org to use React and I helped on the open source effort and this is how I got involved. And Spencer, how about yourself? So I definitely came from a different perspective. So I was actually managing the Facebook newsfeed teams

on iOS and Android at the time. And we were struggling with dealing with this massive app with hundreds of contributors. And our compile times had gotten astronomical. And it was very slow to iterate on the app and fix bugs and move things forward. And then I found out from some of these guys that had been hacking on this new React Native thing after React.js was getting pretty mature internally. And it was very impressive. They had this ultra-fast reload, so you could just change your product code and reload it right away and all this kind of good stuff. And I was like, oh man, we need this. So I switched from management back to coding as an engineer

and joined the project full-time to try and make it a reality internally and eventually for the community as open source. Awesome. So maybe step back a second. Let's talk about React itself and what it is. We've been tracking it on the changelog for some time and you can't ignore the groundswell of excitement around certain projects. This is one that's just been slowly building steam and everybody is quite excited about it. So why don't you all take this one.

What is it exactly and then why are people so excited about it? So what it is, it's a library to build user interfaces. And this is a big world and this is not a framework or anything, but this is a way for you to write user interfaces. And for user interfaces, it's basically like the DOM. So divs and spans and events. And the way you write it is, the first big fundamental pillar is it's in javascript

so there is no templating language like you don't have to use strings like this is pure javascript and you use javascript to create objects that are going to be rendered and one of the big twists is that you don't have an update function. So usually when you build your interfaces, you first render everything, and then you have to hook up all the events, and when something changes, you've got to find the right element and then modify it. And the really magical aspect of React is

you're going to re-render all the time, and inside of React it's going to do a diff between the previous version you re-rendered and the next version you rendered. And it's only going to apply those small mutations. And the great thing is that because it's so focused

on only doing this, then you can integrate it everywhere on top of any platform. So for example, at Facebook, we had many different libraries and frameworks and ways to access data, and we were able to plug React everywhere. And in open source, this is the same. And the great thing is, this is not only about the browser,

about the DOM, it's abstract enough to render any tree. And so we used it to render iOS tree and Android tree with React Native. So this is like the two minutes intro of React. A lot of things that come out of this virtual DOM, server-side rendering, descriptive warnings, custom event systems, things like that are what sort of people

clamor to. This came out of the ad org and really has done a lot for the business itself. One of the ad org and really has done a lot for the business itself one of the things was predictability and being confident with change can you talk a little bit about the predictability that came from this and how that's helped engineers be more more efficient and being able to have confident changes one of the great um success stories of react was an early one um which was that the ads product interface where small business owners and stuff would go to the website to place ads and manage their campaign

and stuff was an extremely complex web application. And there's tons of different features and all sorts of stuff you can do. And it had turned into this giant labyrinth that was extremely difficult to change without causing some sort of side effect bug somewhere else in the application because of this kind of imperative style of going in and manipulating different parts of the DOM and having to update a whole bunch of cascading bits of state here and there because you just changed one bit. And so when the team basically rebuilt it in React,

they found that their rate of new bugs being introduced had gone through the floor. So there was very few bugs coming into the system in the first place. And then also when a bug did come in, it was much easier to figure out what was going wrong and make a targeted fix really quickly. So bugs were resolved very quickly and without a lot of frustration. And then it even went to the point that new people coming into the company, very fresh, maybe straight out of college, actually felt comfortable in the code base because they could understand what was going on because of this declarative nature and componentization of the code, they could say like, oh, this is clearly what's going to happen if I make this change. And they didn't have to, you know, have years of experience with like the whole

labyrinthine system in order to feel like they're not going to break something by jumping into the code and adding a feature, fixing a bug or something like that. So that helped the team grow and move a lot faster and make a much more stable product that our advertisers really appreciated. That makes a lot of sense from an approachability standpoint for developers. I'm curious how designers take to it, people who are used to only working with HTML and CSS,

because as you said, it's all JavaScript. Components seem to break out really nicely. So in that regard, I think it would be more approachable, perhaps, than other systems. But how do you work a designer into the flow of working with React? Yeah, so one of the interesting things about Facebook is designers do not contribute to the code base. So designers do mugs to the code base. So designers do like mocks and like use like Quartz Composer to do like

really nice interaction and interactivities, but they don't actually like go in the code base and change things. So this has not been an issue like at Facebook. But Instagram, which we acquired a few years ago, on the other side, like the designers do change code regularly. And if you look at JSX and the component system, this looks familiar enough to be HTML. So they were basically able to jump in

and make design changes really easily. And also, one other thing I think we should talk about is designers are not inferior people that cannot code. There's this notion that designers, if it's JavaScript, this is the end of the world, they cannot do anything. And this is not true. I would say the previous environment of developing environment was too hard.

So you had to spend a lot of time being trained to write JavaScript. And what we've tried to do with React is to make it as simple as possible. And this is not like trying to do the lowest, like trying to appeal like the

masses, but this is to try to make a really good engineer even more efficient. And using this approach, we found that it was making the library a lot more approachable and designers didn't need weeks of training to be able to jump in the code base and change it. That makes sense. You mentioned JSX. Can you unpack that for us? So JSX is a syntax extension for JavaScript that instead of doing function calls to render your application, you use brackets, angled brackets, that looks like HTML. So the origin of JSX is back in the days in PHP version of Facebook,

we had a big security issue. So we used to use string concatenation in order to build the interface. And as you know, when you concatenate strings, it's super easy to introduce XSS vulnerabilities. We were basically just echoing out the strings. Yeah. And we couldn't solve this problem and like someone from the security team came up with this syntax extension from php

so instead of using string literals to like write html he augmented the syntax of php to write angle brackets and like being able to add attributes. And the interesting thing about this is now because it's inside of the syntax of the language, we know everything which is syntax is HTML and needs to be rendered as is, but everything else needs to be escaped. And so it solved all of the issues,

all of the XSS vulnerability issues that were on the website. And so this was a big win for security. But it turned out that now that you have this PHP object to render those elements, now we are able to write custom tags, custom elements. And so this is how we started with all the component effort. And now we're using components to render the PHP part of Facebook,

like the entire Facebook app. And afterward, we ported it to JS Script, which is JSX and React. Is JSX an optional component, or is it a required piece of React? Yeah, it's optional. It actually, there's just a static transform that translates it into the actual function calls it's making behind the scenes. And so you can just call those directly if you want and skip the JSX. Okay, so there's a build step.

Is that part of some tooling that you guys have released as well? Yeah, there's a JSX binary that adds a transform step to do it. And the interesting thing is because this is not required, then other languages that compile to JS, for example, ClojureScript or CoffeeScript, they're able to use React, but without the JSX part. And since React is really just a view layer, I haven't tried it myself,

but it seems like you can fit it in with many other toolkits, like an Angular or an Ember, if you are so inclined. Is that fair to say? Yeah, you can definitely mix and match. Because also React components are componentized, you can stick them into the tree wherever you want. So that's how it initially got adopted at Facebook, is that we had all this other crazy stuff going on, but you could be like, oh, I want to try this React thing, and you could just re-implement one little widget on your page,

and they would play nice together. Yeah, that was the initial implementation of React in Facebook was the comments feed, right? Yes. Yeah, so you can just pick a piece of the page and shove it in there and it kind of is isolated. That makes it really easy to pick it up and give it a shot without having to go whole hog into it.

Yeah, definitely. And also, it's two-level, so you can embed it anywhere you want. But inside of React, you can also make a component that is just a jQuery plugin or some arbitrary node. So you can plug it in,

you can have your custom code base on top of React and below React as well. Awesome. Well, I want to ask you about React Native. We're pretty excited about it, but let's pause first, hear a word from a sponsor, and when we get back, we'll talk talk about react native i want to share a more personal note today with you about our awesome sponsor top towel you've heard us talk about top towel several times for long

time listeners you know that top towel has been supporting the show for the better part of a year to a year and a half now if you want to go to their website while I'm talking here, it's T-O-P-T-A-L.com. It's one of the best places to work as a freelance software developer. We've been working with TopTalent, like I said, for about a year, year and a half now. And over this year and a half, I've gotten to know their co-founder, Brendan, very, very well. I love what they're doing for the software development community. They care deeply about software developers having awesome engagements to work on. And they also care about awesome engagements having really awesome software engineers to work with them.

So they really make the marriage between a business with great opportunities and an engineer needing great opportunities to work on. They make that marriage possible. Well, we took our relationship to the next level and went there ourselves we're building something very cool behind the scenes here at the change log to power the future of what we're becoming you're gonna love what we're doing we hired a software engineer through top tiles name's hafael so if you're a member and you're in the members only slack room say hi to hafael he's in there but i wanted to tell you just how deeply we care about our relationship with top tile and how much we trust who they are. And if you're freelancing right now as a software developer and you're looking for a way to work with top clients, maybe even us, on projects that are interesting to you, challenging, and using the technologies you want to use, I would go as far to say that TopTile is the place for you.

Head to T-O-P-T-A-L.com slash developers. That's TopTile.com slash developers. Learn more and tell them the change load sent you. So you mentioned earlier that you have these components, you have this declarative way of defining the components, and you've kind of abstracted that away from the actual rendering. And what falls out from that is the ability to render not just to the DOM, but to other view layers.

I think it was Flipboard who came out with React Canvas, kind of to much applause and to some controversy around is the web technologies good enough for 60 frames per second? Which is always fun to talk about. But you guys have taken that a step further. They're rendering it to Canvas, and

you guys at your conference in January, I believe it was, announced React Native. Do you want to talk about that for us? Yeah, so the general concept is that you still just have a view hierarchy. It just happens to be UIKit, UI views, or Android views, or DOM nodes. And the same React principles, React algorithms, they all apply to each of them. And so basically there's a bridge layer

that translates the JavaScript to the native platform, and then you have kind of like a CRUD interface of create, update, and we just use that to add nodes into the system, modify them, set properties, delete them. Yeah. And the rest is, you know, a bunch of platform specific native stuff to make the system work. But that's kind of the basic idea. When you came out with React Native, from what I understand, it's getting the best part out of native, but also getting the best part out of the web as well.

Can you talk about that a bit? Yeah, so one of the main things that was slowing us down on native, I mean, we could build beautiful apps that performed really well and were really great. But it was just a lot slower to develop and iterate. A lot of this was because our build times had gotten really slow. But just in general, it's not the web where you can just rapidly prototype and reload the page and all that kind of stuff. Yeah, I mean, we look to be able to solve this simultaneously, get the performance and the platform standardization of the native side, but then also the ease of development on the website with being able to reload. We also brought some other

abstractions, including layout system and styling. So now you can write something similar to CSS that's actually pure JavaScript to style your nodes, similar to style sheets. And you can use the Flexbox layout algorithms to lay out your nodes. So now instead of the standard, especially on iOS, of actually doing a bunch of arithmetic to calculate how the views should be laid out on the standard, like especially on iOS of, you know, actually doing a bunch of algebra or arithmetic to calculate how the views should be laid out on the screen. You can just say like, you know, flex direction row or column, and they'll automatically like stack up. They'll stretch to fill their parent or wrap text and all these kinds of things that you're used to on the web, which also takes a lot of the burden out of the kind of traditional native development.

So it sounds like it's maybe yet another preprocessor. So is that what you're talking about when it comes to an alternate way of doing style sheets? The way React works is the only interface with a DOM is three operations. One, which is create a DOM node and attach it somewhere in the DOM. The second one is update this DOM node and the third one is

remove the DOM node. Before that, there's all the React diff algorithm that outputs those three things. We are still using JavaScript and we're still using React and all of this, but we re-implemented those three things. And so we are still using JavaScript and we're still using React and all of this, but we re-implemented those three operations.

Instead of doing it for the DOM, we send them from JavaScript to Objective-C and in Objective-C we create a view, we modify the view, and we remove the view. Does that make sense? Totally makes sense. So, hmm, you're not running a web view inside of a native app. It's not like a wrapper.

It's actually just rendering native components. And so the goal, I'm trying to understand the big win. Is it just that you can use the web technologies, which you know and love, or is it cross-platform? What's the biggest win? So Jordan, who created React and was at the beginning of React Native, is obsessed with performance. And for months, he tried to get a 60 FPS list,

like infinite scrolling list like Newsfeed, on the web, and he couldn't get it to work fast enough. And so what he tried is he took the React native, like our very early experiments, and used the exact same code, but instead of rendering divs and spans and images, he rendered UI view, UI image, and UI label. And without changing anything, it got 60 fps without even trying and so this is how like the project really really started we had a confirmation that the browser is not like fast enough uh this is like how it started and then we were able to get a lot of wins because it turns out that all of the native UI components from iOS

are extremely well designed and well made and all the gestures are right and are very high quality. And while it's theoretically possible to implement those on the web, I've never seen anyone do it as well as the native counterparts. And so by being able to reuse them by default,

this is a big win for the project. And it's also interesting because I would say it's a broken glass effect. So because all of the core components are so high quality and so well made, the iOS community is extremely careful about making really well-designed interactions and things like this.

But if you look at the web, because there's no such example, it's okay to ship inferior quality apps. And we've seen this even at Facebook, on the website. We could make it a lot better, but we haven't done so because we were not pushed far enough by the platform

and the mentality and the ecosystem. You're saying the web has some broken windows, and so we're all just kind of adjusting to fit that ecosystem. That resonates a little bit. You also asked about the cross-platform nature. One of the big advantages we've seen is that now there's one unified development experience

independent of what platform you're running on. You learn JavaScript, you learn React, and you learn some of these style sheet concepts and abstractions. and that travels with you to whatever platform you're working on. Of course, the platforms also have a lot of platform-specific idioms, right? So the actual design and the way the app looks and feels and the way navigation works and those kind of things are unique. But now the actual code that you're writing and the way you're working and the tools that you're using are much more consistent. And so you can have the same developers more easily moving between platforms as they build out a similar experience on multiple devices or

operating systems or what have you. We also have the flexibility that we can reshare whichever code we'd like to. It very rarely makes sense to share all of the code, but the lower levels of application logic, like business logic, is usually the same. And it's decoupled from the view layer, right? And so that code can all just be shared across the applications. And then you can decide where in the stack you want to re-implement the presentation. And so we've actually been able to move around pretty quickly across platforms

without spinning up more specialized people that know the intricacies of the Android runtime and all that kind of stuff. Also, I want to add something on this, which is if people... I was on the photos team, and we had one big issue, which was that developers on iOS could not write anything on Android, could not write anything on the web.

So whenever we wanted to do a new feature, we had to staff three different people to work on the exact same thing. And the issue with this is now it makes silos. So now there's iOS engineers that are thinking about iOS and this mentality, and they don't talk to Android engineers

and they don't talk to web engineers. And so not only it takes three times the amount of energy to build features. But you also get a lot less communication between zoos and they get further apart. And this is not good because now you're putting people at war between each other.

Now, instead of having everyone wanting to build the best product, now you're going to compare between iOS and Android, oh, I'm the best. And also, as a mentality effect, it's not really fun to implement the same thing as someone else. Because you want to do something unique, and now, if you think it's best, now you've got to convince the two other people

that they also should do that. And so, because it's like a lot of people issues. Well, then you can't just... Yeah, you have to have so many people to implement a single feature because simply because of platform

differences, you're not really trying to do a right once run everywhere kind of situation, which is what Tom said in his keynote. You're really trying to do... Everyone understands how to use React, and React can work everywhere kind of situation, which is what Tom said in his keynote. You're really trying to do, everyone understands how to use React and React can work everywhere. So it's not like write once, put it everywhere. It's more like learn it once and then do it everywhere.

Write it everywhere. Yeah, which really, I was just going to say it really breaks down knowledge silos inside of an organization and brings all the engineers on the same page. That seems really great too for team building too, right? Because you've got really smart people on three different sides of the fence, basically, that are in their own silos and can't really mesh together,

get lunch together, talk through features together, and really even take it above and beyond the bar that you're already going to because they're in their silos and sort of camping out in their own areas. Yeah. And those experts also tend to be more fragmented themselves because now you're spreading the products across more people because you have the platform specific verticals, right? And so now instead of having one engineer that knows how to build this product super well on all platforms, you'll have three engineers that know how to build three different products each on their own platform. And so now any individual engineer is fragmented across PMs, designers, projects,

that kind of thing. Continuity, better team building, that's definitely the way to go. Jared, you got a question? Yeah, I'm just now starting to think, man, in a practical sense, using React Native, I'm wanting to get my hands on it now because I'm thinking, how do you use this thing?

Are you chilling? If you're doing an iOS app in React Native, are you chilling inside Xcode? Are you just having some JavaScript files and you have some sort of build tool? How does it work? The way it works is, most of it for the random developer is going to be JavaScript.

So mostly going to write JavaScript and React. Internally, we use Atom for debugging, but a lot of people use Sublime. Sublime's here. I use Sublime. So this is for the random developer. But then what we really want is you can access every single feature of native that you want.

And the way we did it was to implement a plugin system that lets you write arbitrary Objective-C or Java. And this means that if, for example, Apple ships a feature on APIs that is not available yet for a new upgrade, like, you can, like, bridge it. It's going to be a bit, like, verbose and complicated, but, like, you can do it.

And also, it's really useful for being able to run, like, really high-performance things. For example, like, image decoding. While there is ASM.S and this kind of thing, at this point, it adds a layer of indirection, and you want to be able to use a real thing with threads and with malloc and controlling the very low level. But then this is a use case for more advanced,

so you're going to do it less, but this is really what makes it stand out from the web as it is right now. Yeah. So you have that full power of the plugin system to write whatever modules you want. So you can just write random files that just have some JS function you call and executes the native thing. Or you can actually wrap view components. So say you already have an app and you wrote some really cool widget that you, you know, don't want to just throw the code away. You can actually just bridge it right into your React Native app and make it available so you don't have to just throw

all that out. Or if, you know, there's something about it that you need more closer access to, like, the native APIs, you can do that if you need. But because we made it as easy as possible to bridge in these new plugins, we're also hoping that the community can kind of expand that surface area really easily as well. And we can kind of build a community-supported library of all sorts of neat widgets and native capabilities and things like that that are really easy to just kind of drop into your app.

Well, now that we got pretty much everybody excited about that, let's get them excited about something else as well. You've got some dates, some dates coming up that are pretty important to you. What's going to happen on those days and what's so important to you? Yeah, so yesterday we open sourced React Native. So as of today, you should be able to just go on GitHub and npm install and start to use it. That's exciting. So technically, Christopher, you're speaking in the future to the past.

Yes. Because we're recording this in the past, but you're listening to this on a Friday, which is March 27th. So on March 26th, Facebook announced React Native, and it's open source. Well, you announced it a while ago, but it's open source now. Yeah, you guys announced it back in January, and here we are in March. It seems like, was there just some cleanup that had to be done,

some extraction that you had to pull it out? So the story behind this is, we organized the React.js comp, and we had no plan of open sourcing React Native. And we were like, we wanted to open source it at some point, but we were not ready. And one month before the

conference, we were like, this is the best place to announce it. There's no better place. And so we were like, there's no way in one month we're going to be able to make it open source ready. So what we did was we're going to clean up as much as possible and see the dates where we are. And we were not ready.

So we were like, OK, we are ready enough for people to trade, but not everyone. So we gave access to attendees at the conference. And then we were like, OK, we're going to work as fast as possible to make it ready. And now we're able to get something that we are proud of. Even if it's super early, you can start building up with it. Yeah, everyone at the conference who was at ReactConf back in January got access to the GitHub repo.

So you had it private. It was already on GitHub, but you kind of gave access to the GitHub repo. So you had it private. It was already on GitHub, but you kind of gave access early to those attendees. But yesterday, March 26th, you actually open sourced it to the world. That's correct. And this was not a really good place. And I don't recommend doing the same thing

because this is like... People were starving the gates, weren't they? Yeah. And this is making we're storming the gates weren't they yeah and this is like making so much hype and like yeah we really want like people to try it and see for themselves instead of like listening to us saying that this is the best thing in the world and this is what we've been trying to do is react is this is what we think but like please try it and make an opinion for yourself when you say try do you mean try it as in use it or try it as in like build something with it?

Because obviously they couldn't build something with it. But to try it, they could use Facebook groups was your first, as far as I can tell, was your first usage internally of React to building brand new or React Native, sorry. Yeah, I would say both. Like try to develop something with it. And if you're not convinced,

try the groups app or the Ads Manager app. And one interesting thing about the Groups app is it's half React Native and it's half just normal Objective-C. And what's interesting is try the app and see if you can detect which one is native and which one is React Native. And if you cannot find out the difference, and it means that we've done a good job, it means that

we are able to write native apps. I can't tell the difference, so you did a good job. I use it, I've been playing with the groups because here in my neighborhood, we actually have a Facebook group that we use for our neighborhood, and it's good for getting to know your neighbor for one and just kind of

keeping in touch with what's going on in the neighborhood. But we're me and my wife are always on it, just kind of keeping up with our neighbors and whatnot. So that's one of the groups I use quite a bit on Facebook. So I was like, ah, that's a good thing. And I've been using it for a couple of days now and really been enjoying

the push notifications. And I can't tell it's not that it's a half and half app at all. Well, thanks. That's the goal. I think, I think one of the reasons why people, people got so excited is that, you know, this, this is not an R and D project. I mean, it started off as one a while back, but one thing that I appreciate about what you guys do over there at Facebook with your open source is, you know, you do wait and you do use it in production and the term is dogfooding and of course we've heard that plenty of times but you have production apps that use React Native

this is not like, hey this might be a thing that works it's like nope, this is really a thing that works and we're using it and so that makes the announcement so much more tangible and people want to get their hands on it because you can actually do production things with that today. That's super exciting. We have a very firm commitment to our open source portfolio to only launch things that we really believe are very useful,

work well, at least for our internal use cases, but also that we think will be useful to the community as well. And so React Native is one of those. If we ended up not using it internally, we wouldn't have open sourced it because there must have been something not quite there about it. Paper doesn't use React Native, does it? No, Paper uses another library that we did open source called Async Display Kit. And so that came before React Native was even a thing at all internally.

And actually React Native is starting to think of a lot of similar optimizations that we can make inspired by the Async Display Kit open source library. For example, one of the things that traditionally makes apps slow or drop frames or whatever is doing the layout synchronously on the UI thread. And if you have a lot of complex layout to compute, it can take longer than one frame, and then you miss your frame deadline and drop a frame.

What Async Display Kit did for paper is make it really easy to compute your layout on a separate thread and allocate nodes and do all this kind of stuff in the background without blocking your UI thread. And React Native gives you a similar capability. So we mentioned earlier that we have this flexbox style layout paradigm. So you write like flexbox style rules and your styles, and then the system computes the layout, like the frame positions and all that. All of that layout calculation is also done on a

background thread rather than on the main thread. So even if your layout is very complex and it takes a few frames to compute, we're not going to be blocking your scroll or whatever while that happens. So we have kind of a synergy between our different libraries, even if they're not actually sharing any code, just based on their time lineage. So React Native supports iOS and Android out of the box. Any other platforms that support or in the pipeline? Yeah, so Android hasn't shipped yet. We're working on an app now, and it's not part of the open source yet. But we're working very hard to ship that app and get it into the open source for the community.

So for the release, the initial release is iOS first, then Android later? Yeah. And this goes back to your remark that we only open source things that we use in production. We don't have an Android in production, so it doesn't make sense yet to open source it. And right now we don't have any other plans,

but we really designed the systems to be modular. So it shouldn't be that hard. Like it's going to be a lot of work, but like the system is designed to support like a Windows phone, like 10 then or something like if you have like other platforms and we see it with React. React, there's a React canvas backend. There are some people that did React's OpenGL backend,

some SVG backend. So this is open-ended. Especially you mentioned something there that Stenaka kind of had earmarked to talk about, which was the blocking portion of a garbage collection of JavaScript, running that in the same, the main thread, and what that means for frame rate. And Jared, you mentioned earlier about Flipbook and React Canvas and whatnot. Flipboard.

Flipboard. What did I say? Flipbook. Flipbook. Yeah, that was pretty close. Close enough. I don't use Flipboard, so that's why it's a flipbook to me. Facebook, flipbook, we're all about the books around here. My bad.

But talk about the non-blocking aspect on things like garbage collection and what that means for frame rate and what that means for the animations and transitions that React Native allow. Yeah, so right now, like I said, the layout and all that is done on a background thread, but all the JavaScript is also executed on a background thread. So the way the system is architected is that everything goes across a serializable asynchronous bridge

between the native runtime and the JavaScript engine. So this means we're not doing any custom synchronous hooks. It's literally just serializing the commands into JSON and passing those back and forth. So that means the JS can take as long as it needs to compute a batch. And the interface is free to scroll and respond while that's happening. Obviously, if you have critical things with JS in the loop, then it can get stalled. And right now, we've done a lot to make sure that's not the case. But we'd like to actually lift that restriction and potentially introduce some multi-threaded JavaScript architectures and some other optimizations there so that we can make it a little bit

easier to run critical sessions in your javascript yeah and also you mentioned a garbage collection and we were super afraid at the beginning that oh we're using javascript we're going to be hit by the garbage collector but it turns out this has never been an issue so far like we've never dropped a frame because of it. And one of the reasons is we're using JavaScript core and it has a multi-threaded garbage collector and it's concurrent

so that your JavaScript can run and the garbage collection is going to run at the same time. It's not going to block except for the sweep phase. But the sweep phase is chunked and has a deadline limit. So in practice, this hasn't been an issue.

That's good to mention that because the show just before this, episode 148, Jared wasn't on the call, but I had a call on the topic of Go with Andrew Geron. And one of the things they're doing with Go is opening up to going to mobile, more or less, iOS and Android support. And one of the things we talked about was the concurrency in Go and garbage collection and the importance of that and how that sort of pauses the application

or pauses that thread. And even for a few milliseconds, of 10 milliseconds, and then that provides that pause that sort of drops your frame rate. Next thing you know, your transitions aren't the way they should be. Your animations get blocked and you have sort of a kludgy UI and a kludgy UX. So that's a pretty important feature there. We're going to take a quick break, come back and talk about Flux, Relay, and GraphQL,

some highly important topics that are pretty fun to talk about. So we'll be back in just a sec. Over 400,000 developers have deployed to DigitalOcean's cloud. DigitalOcean is a simple cloud hosting provider built for developers. In 55 seconds, that's all the time it takes, you'll have a cloud server with forward access, and it just doesn't get any easier than that. Pricing plans are super inexpensive,

just $5 a month for half a gig of RAM, 20 gigs of SSD drive space, one CPU core, and one terabyte of transfer. All DigitalOcean servers run on SSDs. That means they're blazing fast. They have tier one bandwidth support and come with private networking. Use our special link to get a $10 hosting credit

when you sign up. Head to thechangelog.com slash digitalocean to get started and now back to the show. Alright, we're back. Flux, Relay, GraphQL. Where should we begin with these three topics here? Maybe with Flux.

So, the history of Flux is the team that was working on chat, they had one big issue, which was updates were out of sync. So, for example, you had a notification, a chat notification, someone sent a message, and you need to update the chat tab at the bottom right of the screen

and the buddy list at the right of the screen, and the notification icon, and like many other places in the UI. And the way it was organized before it, anytime there was an update, you needed like manually in the code to go to all of those places and modify the downloads.

And this was horrible because things were getting out of sync all the time, and it was super hard to know why and to traverse all the issues. And so the idea that they had is we're going to have a centralized place where we're going to have all

our data, and we're going to use something called a one-way data flow. So instead of having, like, the model that talks to the view, that talks to the model, that talks to the controller, and in all of those places, there's going to be only one way to do it. When the view does an event and the view changes,

you're going to send an action to the model, and the model is going to call the view again and like only it only goes in this one direction and it's solved like all of the issue but what it meant is that they had to re-render the entire thing like basically all the time and in parallel there was this react library that we was working on at facebook which which was like, we're going to re-render everything all the time, and it's going to be fast enough. And the two actually converged,

and they were a good fit together. So you can use the one-way data flow architecture of Flux with React to render, and they work really well together. So Flux was, it's kind of, would you consider it an architecture or an implement?

Yeah. It's not a specific tool. It's a way of going about things, similar to how Model-View-Controller would be a way of organizing your application. That being said, you guys, Flux is a thing that you guys do with your web apps and your React apps.

And so you provided Flux as kind of a, was there a specification or just some documentation on how a Flux application will work? And then you guys had your own implementation? Yeah, so we have a website, facebook.github.io.flux. And we have only one part of source code, which is a dispatcher. And then the rest is documentation

of how we designed the system internally. But this is like create actions, mutations, things like this. It's basically like a way for you to architect your app, but there's no specific code. Is that because it's so application specific, the way you end up going about it? Yeah, there's no stores, there's just JavaScript objects. And actions, there's just JSON payload.

So there's not that much code. But there's a lot of Flux libraries that try to implement the Flux pattern that will give more concrete things. So you may want to start with them if you want. Yeah, there's a whole list of them. Yahoo has one. The best thing about these is the names that came out of it.

You got Flux, you got Reflux, Flumix, Marty.js of course, McFly, Material Flux. You got a whole ecosystem of Flux implementations. And in fact, I think we even covered in Weekly a Flux comparison, which is a repo on GitHub. If you search Flux-comparison,

a guy who basically went and implemented the same app across all these different Fluxes. So, vibrant ecosystem of Flux, isn't there not? Yeah, one of the interesting things is, so when we open source React, we just said, oh, we're using this internally, Flux, and on IRC we were talking about it, but we didn't care that much

because we just wanted to focus on the view. But the demand was so crazy. And so one engineer at Facebook just did a blog post about Flux, just saying how it's working so that people can have a reference. And everybody jumped on it. This was like if Facebook was the messiah, this was the way to go. So I would say this went a bit overboard. This is how we are doing it and it's working well.

We hope it's going to work well for you. Again, we don't know your specific use case. Then you guys shortly thereafter started talking about another thing, which seems to be, I don't know if you call it a spiritual successor or maybe just inspired by Flux. This is actually a framework now. This is not just an architecture.

It's called Relay, an unreleased framework announced probably around the same time as React Native, which appears to be kind of doing the same stuff that Flux is architected to do as far as actions, data fetching, and so on. Can you talk about Relay? Yeah, a lot of the philosophies are very similar. It has the one-way data flow and these kind of things,

having a centralized store for all your data. But one of the problems we ran into with the Flux architecture was keeping our client and server code in sync. Especially the way our chat system was engineered is that basically the server endpoint, there was just one, would basically have to prepare all of the data that the client could potentially want

and package that all up and then ship it down to the client in one big bundle. And if you changed anything on the client, it was very difficult to make certain that that data is going to be available from the server. And then when you're looking at the server, like, oh man, we're fetching all this stuff. Is some of this wasteful? Can we get rid of it? It was very difficult to make sure that that piece of data is never going to be accessed by the client. And so keeping those in sync was very difficult and it led to bloating the responses because in order to be safe and make

sure we didn't introduce bugs, we were more conservative with removing data from the payload. And so what Relay, which is tightly coupled to GraphQL, enables us to do is that the client actually specifies every single piece of data that it wants with the query. And so it basically requests it explicitly from the server, like, you know, I want, you know, the actor and I want their name and I want their hometown and their phone number, but I don't care about their birthday or whatever, right? And then the server can prepare that request specifically for that

client and send it exactly what it asked for. And so now the overfetching problem is gone, the synchronization problem is gone, and the interaction there ends up being a lot more efficient and easier to work with. What that also means is... It kind of acts as a wrapper around the React component, right? And so because of that, just waiting on that data, it's kind of a prerequisite for the component to render.

So React can basically just chill there, wait until it's all resolved, and then finally render. You shake out a lot of complexity in dealing with transition states and loading spinners and stuff like that, right? Exactly, yeah. The React component declares exactly what data it needs from the server, and then the Relay framework makes sure that all of the different components that are going to be rendered together in that page load or that view, it combines all of their data fetching into one query and then fetches that in a batch. And then it also manages updates and all these kind of things.

So if you're doing an infinitely scrolling list and you want to scroll load some more data, it'll handle changing the cursors for the query and appending that data and then updating only the components that need the updated data and things like that. And you say it's tied to GraphQL, which to me I think is like, you have REST,

and then you have this other way of querying an API. Yeah, so the idea behind GraphQL is, so the REST endpoint, it gives you the path to an element, but it doesn't say what attributes you want from the element. And so what GraphQL does is, it lets you specify the path, like the exact set of attributes that you want from the element. And so what GraphQL does is it lets you specify the path, like the exact

set of attributes that you want. And another benefit of GraphQL is, by nature this is hierarchical, so you can dip down many times, and it solves the program

called n plus one fetching program. So if you want to fetch a list, and then each element of the list, and for each element, like another list, if you are using the traditional rest endpoint, you first need to fetch the list, and then do 20 queries for each element, and then for each element, do like 20 other queries, and GraphQL makes it all go into one single query. So whereas you normally would get

a singular REST resource, this is like grabbing a tree, basically. And you get it all in one query, which is great for performance. Is GraphQL, what, you guys just came up with that? Is there prior art or is this in the wild out there? So the history of GraphQL is when we

re-implemented the iOS app from web to native, we needed a way to fetch data and what we needed was to get a JSON and the engineers working on GraphQL said, oh, but I know I want this JSON, so what I'm going to do is just going to remove all the values and keep the shape and they decided this was GraphQL.

And this is as simple as this. And they've been using it on the Newsfeed iOS for three years now and it's spread like all the iOS apps is using GraphQL, the Android app is using GraphQL. And the reason why we didn't talk about it yet is because if you want to implement GraphQL, you need to change your entire backend

because now your backend has to talk GraphQL. And we didn't think it was like enough changing our backend just for GraphQL without any library. But now that we are integrating GraphQL with Relay, we think the benefit is big enough so that we can convince people to change their backend to use GraphQL because their code is going to be much better. So GraphQL, you guys obviously have your own implementation if you've been running it in production

for a few years. Is that something that's going to be available or is it already available? Yeah, so the tricky thing about our implementation is our implementation talks to our Facebook stack and PHP and things like this. And this is not reusable.

So the way we're going to open source this is we're going to give a specification of the language, so grammar and what things mean. And we're going to provide custom implementations for popular things. So we're going to have a node module that knows how to take a graphical response and talk to MySQL or Postgres or MongoDB

and return it. From this prototype reference implementation, then people are going to be able to use it to adapt it to their backend. Great, so there'll be a specification and an implementation out there.

I tell you what, you guys announced React Native, you got Relay coming out, you got GraphQL coming out. You're really good at building buzz for your open source products. You were able to announce React Native is now available, which means most of our listeners have already quit listening and they're out there playing with React Native. I asked on Twitter last night

if people had questions for the React team, and it was, when can we get Relay? When can we get GraphQL? They're chomping at the bits. Can you give us anything as far as what we're looking at for these frameworks and tools? So a few months.

A few months. Yeah. Same, we announced Relay, but we didn't expect, like, that crazy amount of hype from it. So we're like, oh, we're going to explain, like, GraphQL and Relay. And, like, people are going to, like, say, oh, yeah, this is a good idea, and then, like, move on.

But, like, they didn't, and now, like, we're asked, like, every single day, like, when is it coming out, when is it coming out. So, like, the entire GraphQL team and Relay team shifted focus. They stopped doing any development and they're just focused on open source. So in a couple of months, we're going to be able to use it. Sorry for the wait. I think you guys will know better next time.

Next time you pre-announce something that they'll be knocking your door down. You've got flamed a little bit, too, on the pre-announce even of React Native, too. How can you announce something that's not actually out there yet? Although you do have an app in the wild, so that does make some sense. It seems like with GraphQL, I'm not obviously here to prioritize your guys' workloads or anything, but similar to how with Flux, you guys release Flux as an idea, as a description. GraphQL obviously will need some sort of specification if it's going to have multiple implementations. If the specification could at least be up front as far as that,

then other people could hop on it. Because obviously everybody has their own backend stacks and data stores. So we could start having that ecosystem similar to Flux's, perhaps, while we wait for your guys' canonical implementation. Yeah, that's definitely the first step. And the guys are working on coming up with the full spec

for the language. But unfortunately, it came about pretty quickly when we were first implementing it, racing to build the new iOS app. And there's definitely some warts. So they're working on trying to smooth out some of those warts that we've been living with for a while so that the community doesn't have to deal with them. And so they're trying to figure that out as quickly as they can, and then they'll put something out there. It sounds like you guys might have gotten kicked out of your room too during this conversation.

You guys moving around over there? Yeah, we did. Well, that's actually good timing anyways because we're about to close up. We could probably drill a little further on a couple of thoughts here, but one of the things that you guys pointed out, I'd love to have you back on the show whenever this becomes more and more real

around React Native as the component library whenever that's you know whenever you can release something new about that please keep in touch because that's something that's you know for me particularly is is uh perk my ears up because i was thinking geez that'd be so nice to to be able to you know learn one place to use react js and um and have that library available. But well, guys, thank you so much for joining me and Jared on this call today.

I know that, uh, everyone's pretty excited about react itself, but then also react native coming out, uh, huge announcement flux, uh, the,

the idea there, but then relay coming and graph QL coming later, uh, in a few months, that sounds pretty cool. So let's close the show there. And with that, uh,

thanks everybody for listening and we'll we'll say goodbye now so goodbye great thanks for having us I love you.