The guys at DevChat.tv hosted a pretty interesting podcast about React with Christopher Chedeau and Jordan Walke, two engineers of the React team.

We invite you to check their JavaScript Jabber series where they offer a nice transcript of their episodes.
We're hosting here the one about React Native aswell.

CHUCK:  Do you want to introduce yourselves really quickly?

CHRISTOPHER:  Yeah. So, my name is Christopher and I’m on the React team. And three months ago I had this crazy idea of doing a React.js conf. And then I spent the last three months just working on it. And I didn’t do a lot of code in the past months. But [it’s good] now, it’s over.

JORDAN:  Yeah. And I’m Jordan. And I work with Christopher. And I’m on the React team. And both of us have been working on React Native in addition to Christopher working on the conference.

CHUCK:  There are so many native jokes I want to make about that, but…

[Chuckles]

CHUCK:  About React going native. Anyway, that’s awesome. So, were there any big announcements at the conference?

CHRISTOPHER:  Yeah, I think so.

[Chuckles]

CHRISTOPHER:  Yeah, there was the React Native big announcement. So, it lets you build applications on mobile and using native widgets, but using JavaScript and React. And the second one was GraphQL and Relay. This is an extension of Flux so that you can build all your data fetching pipeline right within your components.

JAMISON:  So, you said that three months ago you got the idea that you wanted to do a React conference.

CHRISTOPHER:  Yeah.

JAMISON:  Did you have any idea how much work it would be or were you just like, “Oh, I’ll call some people and we’ll throw some event together.”

CHRISTOPHER:  Yeah, so I didn’t realize but my manager was like, “Yes, it’s a good idea. But no, you’re not going to do anything else but the conference.”

JAMISON:  [Chuckles]

CHRISTOPHER:  And I didn’t [believe him] at the time. But now I do. And he was right. But as soon as he said yes and I got help from the entire Facebook company, from legal, from events, from all [inaudible], they’re really good at making things happen.

JAMISON:  So, I was there and it was fantastic. All the speakers were great. It seemed like a really well-run conference. So, your hard work paid off.

CHRISTOPHER:  Thanks. Yeah, there’s one thing that I think I’m the only one doing for the conference, was I scheduled rehearsals for every single speaker, even excellent ones. And I did it one week before. And I feel like it really helped raise the quality of the talks. So, if you’re organizing a meetup or a conference, I think this is good advice.

JOE:  Yeah, that’s awesome, awesome advice.

JAMISON:  It seems like it forces out the people that wait to do their talk until the night before.

CHRISTOPHER:  Yeah.

JAMISON:  Then they have to do it the night before rehearsals instead of the night before the conference.

JOE:  Right.

DAVE:  Yeah, perfect.

JOE:  Yeah, and I really liked, you guys had a really cool venue, too.

CHRISTOPHER:  And one interesting thing about the venue is it’s actually the café of Facebook. And at first when we organized the conference we wanted to do something small. And we found the biggest room at Facebook. And it turns out that the demand was insanely crazy. All the tickets were sold instantly. And so, we had to find a backup plan. And we basically converted the entire café best as we could. And I think it went well.

JORDAN:  Yeah.

DAVE:  How did you get that really cool React logo behind the speaker?

CHRISTOPHER:  We’ve got a nice team of special effects for conferences. And we just asked them, “Can we get some cool logo on the stage?” And they were like, “Yeah, sure. We’re going to”…

[Chuckles]

CHRISTOPHER:  [Laserdize] the React logo, and they put it there.

JORDAN:  They laser-cut it?

CHRISTOPHER:  Yeah, laser-cut it.

DAVE:  Nice. And who gets to keep it after the conference?

JAMISON:  [Chuckles] Yeah, is it hanging up in your apartment?

JORDAN:  Christopher. Christopher kept it.

[Chuckles]

DAVE:  Good call, Christopher.

CHRISTOPHER:  It’s in my house just below a poster of, what would you do if you weren’t afraid?

JORDAN:  The iconic Facebook red print poster, yeah.

CHUCK:  Well, all I have to say is if you’re doing special effects next year, I want to see Iron Man at the conference.

[Chuckles]

CHRISTOPHER:  I’ll think about this.

JORDAN:  Pyrotechnics.

CHRISTOPHER:  Yeah, we should do that.

[Chuckles]

DAVE:  My only complaint about the React conference was that I didn’t get a ticket.

[Chuckles]

CHUCK:  Aww.

DAVE:  Many complaints.

JAMISON:  I’m so sad.

CHUCK:  I didn’t either.

JAMISON:  So, Jordan you were the, you’re like the Steve Jobs for the React Native announcement. How did that…?

CHRISTOPHER:  What?

JORDAN:  Well, I actually didn’t present anything. Tom O. presented the React Native one.

JAMISON:  Oh no, I’m confusing you. With the magic of editing, this never happened.

[Laughter]

DAVE:  We’re keeping it. We’re keeping it. Crap.

JORDAN:  But Tom O. did a good job and I was really impressed with the delivery.

JAMISON:  But you were the power behind the throne feeding in the lines, then?

JORDAN:  Oh yeah, sure. We’ll say that.

[Chuckles]

JAMISON:  Okay.

JOE:  Cyrano de Bergerac going on there.

[Chuckles]

DAVE:  For our listeners who don’t know can you just tell us, what is React Native? Give us a little more detail.

JORDAN:  From the beginning React had always anticipated being able to target multiple backends. And we’ve had some good experiments with Canvas or even some GL experiments I believe. But the way React works is you program these modular components and they encapsulate everything that your component needs to worry about and doesn’t leak much of those implementation details out of your component. And then at the end of a component event loop what comes out of it is this set of mutations that need to be applied to the DOM or some backing tree structure.

And so, React has always anticipated being able to take this stream of updates and creates and moves and apply them to a different underlying I guess view hierarchy. And so, all that React Native does is it replaces the DOM manipulation with UIKit manipulation or Android view manipulation. And so, by doing that you’re able to use the same APIs that you already know today for React and be able to build native applications on iOS and Android that feel native and authentic to the platform and perform well. Does that answer your question?

DAVE:  Oh yeah, definitely.

JAMISON:  So, I’ve heard from a lot of people, is this PhoneGap? Is it running in a web view? And it’s not, right? It’s using the native rendering layer. Is that correct?

JORDAN:  Yeah, I’m glad you brought that up. There’s no DOM involved at all. There’s no WebKit. There’s no PhoneGap. There’s no web browser. It’s just pure JS that powers purely native views.

AJ:  But it is running actually JS on the device itself? It’s not like it’s transpiling or compiling into native code fully?

JORDAN:  Yeah, that’s correct. It’s not transpiling. It’s using just JavaScript core.

JOE:  So, can you update the code on the fly?

JORDAN:  We have a really rapid development cycle with React Native. So, you can make code changes and refresh and reload without having to recompile everything. And that’s really quick. So, in that sense, yes.

JOE:  Awesome.

JAMISON:  Joe, it sounds like you’re asking about pushing updates to the app store though. Is that what you meant?

JOE:  Well, yeah. So, do you have to go through the typical process of pushing, every time you change code, you don’t have to push it all the way through the app store?

JORDAN:  So, that’s my understanding is that you do have to go through the typical app update cycle that you would do with any other native app because it is a native app on the platform that you’re targeting. When we’re talking about rapidly reloading code, we’re most interested in that really fast developer cycle so that you can get your app out there to the app store much quicker.

JOE:  Interesting.

JAMISON:  But it’s not going to load the JavaScript from the web or something?

JORDAN:  No. We’re not really interested in that. We’re definitely more interested in the developer cycle because that’s where the majority of your time is spent, is developing this app, getting it stable, and reloading constantly as you get there. I think that’s the higher order bit.

CHUCK:  I’m still trying to get my head around this. So, it’s written in JavaScript but it doesn’t manipulate a DOM. It actually just manipulates the view?

JORDAN:  Yeah. That’s exactly how it works. So, if you look at what happens in React today for the web, you’ll just see there’s this part of the code where it runs a reconciler algorithm after your component does some state update. And it’s about to make these mutations to the DOM. Well, it’s a really nice funnel where all these changes go through. And you can instead of just manipulating the DOM you can just send these update commands over to UIKit, which is native code for example. Does that make sense?

CHUCK:  Yup.

DAVE:  And to be clear, there is a bunch of Objective-C code for iOS and Java code for Android that’s powering this at a bootstrap layer, right?

JORDAN:  Yup. Yeah, exactly. We have these wrappers around each of the view. A lot of that’s implantation detail at this point and it will change. The semantics of it are that when you create a capital V view in React Native, that is going to instantiate some actual platform view that has all the platform accessibility on it that you would have. It has all the platform I guess…

CHRISTOPHER:  Look and feel.

JORDAN:  The look and feel in some cases. It has integration with their event system so that when you pull down the drawer from the top in iOS you get touch cancels, stuff like that.

DAVE:  So, it’s pretty clear to me that you’re not going to take your web React code and just magically run it on your phone and have a native app now.

JORDAN:  Yeah, exactly.

DAVE:  But what about between mobile platforms? Can I write an app for iOS and have it transfer over to Android and vice versa? Or do I have to still write two pieces of code for the two different platforms?

CHRISTOPHER:  So for this, the idea that you should only, you should write two separate codebases, because we’re not into the write once, run anywhere. But we’re into the, learn once, run anywhere. But we actually want to make this progression from writing it in one platform like for iOS and then porting it to Android.

So, our current [inaudible] with this is if you write an app using React Native for iOS and you run it in Android, it’s going to work. It’s going to run and compile. But every native component that’s from iOS, we’re going to have like a polyfill for Android that’s barely working and just, and [red] and don’t use it. And then like our current thing is now that you got this base thing that’s kind of working, then you can start changing all the iOS native components to Android and make sure the look and feel is correct and it looks like an Android app.

JORDAN:  Right.

CHRISTOPHER:  So, it’s not going to be a one-click process, you’ve got an Android app. But with enough effort you’re going to be able to convert the app, making look and feel great, without having to rewrite the entire app.

JORDAN:  Right. And a couple of other things I’d add is people actually don’t want to write once and run anywhere. They want to redesign their app for each platform, and that’s a good thing. And now we’re even starting to see that even within one single platform. You don’t just want to write one app and then run the same app on iOS or on iPhone 6plus and then in iPhone 6 because the screen dimensions are different and you want to utilize that space differently. So, that’s not even something that’s highly desirable to be honest. And so, we don’t want to really commit to doing that. And we want to focus on doing other things well.

That being said, so even though we’ve told people this is a, learn once, write anywhere, people still will misconstrue that. And we’ve seen this blogpost that was about, you know, you’re never going to be able to write once and run anywhere. And we explicitly said that we didn’t want to do that. And so, I think it’s appropriate to…

[Chuckles]

JORDAN:  Set expectations this way, because no matter what people are going to I guess claim that you’re promising to do something more grandiose than you’re actually trying to do. So, I think this is an appropriate way to message the project.

DAVE:  Okay, so let me just make sure I understand. I’m going to be able to write a web app and take the same code…

[Laughter]

DAVE:  And put it on the Android phone.

JORDAN:  You got it.

[Chuckles]

DAVE:  And on iOS. Am I getting it? Because I’m just about to publish my blog article right now.

[Chuckles]

JAMISON:  Hit that button.

JOE:  I already tweeted that.

[Chuckles]

CHUCK:  And I like the approach, because people aren’t going to be pissed at you, Dave. They’re going to be pissed at Facebook.

[Laughter]

DAVE:  Boom. By the way, I was penning the term, when I heard the announcement, ‘trisomorphic’. And I was like, totally wrong.

JORDAN:  There you go.

CHUCK:  Oh, dear.

DAVE:  Totally wrong.

[Laughter]

JAMISON:  So, I heard a rumor that the announcement of React Native happened last minute. You’ve been working on it for a long time but you just decided a couple of weeks ago to open source it and announce it right now. Is that true?

CHRISTOPHER:  That’s correct. So, we’ve been working on this for a year and a half. The first hackathon where we tried it was a year and a half. And then we got many different projects that came in and came out. And a few weeks ago, we were like, React.js Conf is the best venue to open source this. And we cannot not do it.

JORDAN:  Yeah.

CHRISTOPHER:  And we wanted to open source it since the very beginning. But in three weeks, you’re not able to do a proper open source release. It’s not enough time.

JAMISON:  Right.

CHRISTOPHER:  And so, what we decided to do was we were not ready yet to open source it for real to everybody. So, what we did was to make a private repo where we can show something, to show people, and then get our house in order. And in a few months when we think we’re ready then we’re going to open it to everybody. So, it really sucks to be in this kind of position where it’s half open source, half not. But it was the best [inaudible] that we found.

JORDAN:  Yeah. It was either that or not share it with anybody. And if there was a set of people that were going to be really gracious with us and helpful, it would be the people who attended React Conf. So, we decided to open it up to those people just to start with, because we would likely benefit from their help and feedback the most.

AJ:  So, I’m curious. What’s the benefit of not open sourcing it? You say that it’s kind of a, you want to make sure it’s done right.

JORDAN:  Yeah.

AJ:  What does that mean? Because what I hear in open source is, release early and often.

CHRISTOPHER:  Yeah. So, right now for example we have a script that takes our files from Facebook and exports them to the open source. But we have no way to take pull requests or do it commit by commit. Basically we don’t have any way to get pull requests from people and to push our updates to people. So, it really sucks for an open source project to be like a one-time code drop. So, we are really working tuning for this, for example.

AJ:  So, it’s not something you could put in GitHub?

JORDAN:  Well, we’re at a very large organization. And like you said, we’ve actually been using this for a while. So, we depend on this for real apps. And we don’t really like to just open source stuff that we don’t feel confident in. And so, if we’re… sometimes we might if we want to enlist some help. So, the downside of that is that we depend on this for things internally in real apps that we’re building. That’s going to add some unnecessary friction and we don’t want to cause any sort of trouble to the teams that depend on it internally either. So…

AJ:  I see what you’re saying.

JORDAN:  Yeah, so putting things on GitHub, if that was GitHub first all along that might have caused some trouble for them. And so, I guess you see the tradeoff of open sourcing things that are actually used in production by a company that actually serves billions of people. It’s a lot more difficult than a small hobby project for sure.

CHRISTOPHER:  And also we have got a lot of dependencies from all the Facebook iOS stack. For example we use, before we open sourced we used the Facebook image companion because images off-thread. Same for the text rendering, we use the Facebook one. And they have very deep dependencies of the entire Facebook stack. So, it was some work required to extract all of the dependencies and make sure they are being… you can use them without the Facebook stack.

JAMISON:  Okay. So, let me try and summarize this to make sure I understand. Instead of just throwing out everything that you had onto GitHub because it has so many dependencies to private code and is used by all these teams in your internal source control repos and stuff like that, you went through one time to manually pull out the Facebook-specific stuff?

CHRISTOPHER:  Yeah.

JAMISON:  And that’s why this is the code drop and you’re not going to be building off of what you shared with people. You’re showing it to them while you prepare the rest of it.

CHRISTOPHER:  Yeah.

JAMISON:  Okay. That makes sense.

CHRISTOPHER:  In the next few weeks we’re going to clean up all the other stuff that we have. And one by one pull them to the open source. And our goal is that at some point in the future we’re going to in summary use the same codebase as the open source one.

JORDAN:  So, we would be GitHub first even for internal use. We’re just not there yet and it takes a while to get there internally.

JAMISON:  That makes a lot of sense. I had some of the same concerns as AJ before where, why don’t you just make it all open source? But I can see that.

DAVE:  Though I have a question for you about specifically iOS. Does Apple have a problem with apps written and published to the app store in this way? Or are they good to go?

JORDAN:  I have no idea. And I really shouldn’t comment on that. But I do know there are tons of apps out there that do use a JavaScript engine to power it, even without a DOM. So yeah, you could probably just google around and see what apps do you use JavaScript.

CHRISTOPHER:  And also, we submitted the groups app, the Facebook one, using React Native to the app store and it went through.

JORDAN:  And you know, Apple has provided a really awesome JavaScript engine in iOS 7. And that’s just a standard SDK that you can build apps on. So, this is encouraged in that way. And I’m really impressed with the quality of JavaScript core. It’s served us very well. And I think it’s a tremendous engineering feat, how well that performs.

DAVE:  So, one of the things that I really enjoyed, Christopher, in your talk was your section about CSS which traditionally CSS is not part of a native application development at all. Can you talk about what you did there?

CHRISTOPHER:  Yeah. So, one thing we realized at Facebook from people coming from web and going to iOS is that to do any kind of layout you’re basically back to manual mode. So, you’re back to position absolutely everything. And this is a lot of work, pages of pages of mass. And especially with slow build compile step. And people were very, very frustrated. And so, what we wanted for React Native is to take the best of both worlds. So, on iOS we’ve got the performance. We’ve got the native components. But on the web, we’ve got the fast iteration cycle and we’ve got the CSS and the layout.

And so, one part of the layout which is super important is flexbox. And if you’ve never tried flexbox, you should start now. It’s that good. But we had an issue which is that there is not flexbox implementation in native. And extracting it from the browser is really complicated So, I just re-implemented flexbox. And so, the great thing with this is that we can now use flexbox inside of React Native to build native apps.

JOE:  Wow, that’s kind of crazy. Was that hard to implement?

CHRISTOPHER:  Actually it wasn’t that hard. And the way it works is the interface is super simple. So, you get a tree of styles. So for example, your tree of nodes and with margin, padding, and all of this. And it outputs a tree with the same shape but the values are top, left, width and height for every single component.

And so, in order to implement this, what I did was I took this tree as input and I created real DOM nodes with real styles and I gave them to the browser. And then from the browser I asked, what are the top, left, width, and height of every single element? And using this setup I was able to make sure that my implementation was giving the same result as the browser. And so, then in TDD style I was able to add new features and see what breaks. And in about two weeks I was able to reproduce the feature, the flexbox I wanted. So, once this was set up, it was super-fast.

DAVE:  Christopher, I thought your testing approach for developer this was really novel. Can you talk a little bit about that?

CHRISTOPHER:  Yeah. So, I can test against a browser. And one cool thing is at some point I didn’t know where my implementation was failing. And so, what I did was to generate random trees and pass it to my implementation and the browser. And the great thing with this is now I have a bunch of random tests. And some of them are going to fail. And so, I pick the first one that fails. I reuse it to make it easier to reason about. And then I implement it and fix it. And I do the same. I take the first one and I debug it, fix it, take the first one. And at some point there would be no failing tests. And so, at this point I was pretty confident that my implementation was working for all of the attributes I was supporting. And so, I did one new attribute and then I did the same. And that’s it.

DAVE:  So cool.

CHRISTOPHER:  Yeah. This is a good example of how you can use TDD. Some specific use cases and it’s working very, very well.

JAMISON:  Did you just laugh maniacally to yourself when you thought about that?

[Laughter]

JAMISON:  How am I going to do this? I know. Muwahahahaha.

CHRISTOPHER:  The crazy part about this is at some point I did work in JS. But we wanted it in C. And so, I started doing a port of it in C because I didn’t use any, I didn’t do any dynamic allocations or use any fancy JS feature. So, the code looked like C. And when I got my port, my C port running, I compared the two versions. I was like, whoa. They’re really similar. And so, what I did was to use some reg exes in order to convert from one to the other. [Chuckles]

DAVE:  My gosh.

CHRISTOPHER:  And I wouldn’t recommend using reg ex to do this kind of thing. But in this case it worked really well. And we also transpiled the tests. And so, we got a flexbox implementation that’s rather compliant with the browser in C. And when we started the Java port, someone just took my reg exes, they modified it for it being Java compliant, and we got a Java version working as well.

DAVE:  [Laughs]

JAMISON:  Oh, cool. I think yeah, what you’re saying is you now have ‘trisomorphic’ C to JavaScript to Java.

DAVE:  [Laughs] Oh my god. Powered by regular expressions.

JAMISON:  Yeah.

JORDAN:  And that’s a separate project that you can check out as well. And I think it’s a really cool artifact of the project because it’s a nice little self-contained implementation of flexbox that you can run in any C code out there. Maybe you can integrate it in a game engine if you have a menu screen or something like that. It’s really cool.

DAVE:  To be clear, you’re talking about the ported flexbox implementation, not the regular expressions used to generate the code, right?

JORDAN:  Yes, yeah.

DAVE:  I’d like to see those. [Chuckles]

CHRISTOPHER:  Yeah, sure. You can go to GitHub.com/facebook/css-layout.

JORDAN:  Yeah.

JOE:  So, it’s a pretty cool technique that you did. Unfortunately nobody on the show really cares much for testing or TDD.

[Laughter]

CHRISTOPHER:  Too bad.

JAMISON:  Joe’s just kidding.

DAVE:  [Inaudible] joking.

[Chuckles]

JAMISON:  So, you talked a little bit about the ongoing work to make React Native fully open source. What else is going on besides that? I’m sure you’re still working on it beyond just to, to enhance it not just to open it up. Can you talk a little bit about that work?

JORDAN:  Yeah. So, I think there are a few areas that I would like to see focused on. And I would also love to see the community help out with this, too. We’d like to get good documentation for and a very solid API for the gesture stuff. So, gestures are really complicated on mobile. And it’s something I feel the web has really punted on. And so, we want to not make that same mistake. And we want to make sure that you can build components that are modular and that also feel very natural when you use them, authentic to the platform. And it’s really as simple as not misinterpreting a tap for example.

And so, we want to get the API really solid and well-documented. And when we come out the gate with React Native we want people to start building apps that have these gestures integrated all throughout them from day one. And it’s one of those things where I feel like if the precedent isn’t set correctly, I think it’ll make React Native apps… I don’t know. I think they’re going to end up feeling like the web if people don’t use gestures from day one. And that’s controversial because some people think, oh there’s nothing wrong with web gestures. But I think the difference is really clear to me.

CHRISTOPHER:  Yeah. So, one interesting fact about this is if you read on the internet why a web app sucks everybody’s going to say it’s because of performance. And this is true. Performance is really bad. But it’s been improving a lot on the web. But with React Native we got 60fps from day one just by using iOS native components instead of the DOM.

JORDAN:  Like and off-thread image decoder, for example.

CHRISTOPHER:  Yeah. But now when we prototype with [inaudible] the app still felt like shit because we were using the same paradigms for gesture as the web. And so, Jordan re-implemented all the iOS gesture system within React. And now we need to promote it and make sure developers understand this is one of the fundamental things that they need to get right in order to do native apps.

JORDAN:  Right. Yeah, we implemented a subset of the features which was enough to build a wide variety of applications and interactions. But there’s still more to do and we want to vet that and we want to document it well. And we want to go through all the edge cases and make sure that it’s really solid.

JAMISON:  So, I haven’t done any iOS development. And I only know about gestures from a user perspective. It’s tracking when the person taps and how their fingers move and how many fingers are moving, right? Can you talk a little bit more about why that’s so hard to do on the web?

JORDAN:  Okay. So, I feel like getting one particular gesture, let’s say a pinch or a two-finger drag. That’s actually not that hard. It’s just simple math. But I think the harder part to get right is the API and the integration of that API to do gesture hand-offs. So, where one part of your application is interpreting a gesture and it gets to decide whether or not another part of your application can also handle that same gesture, and what happens when that handoff occurs. Some kind of visual feedback is almost always given to the user to say, “Oh that button is no longer active because some other part of the application is now taking control of that.” So, that’s something that’s missing on the web. Standard touch events aren’t sufficient to even implement that, even if you’re diligent. So, you need something else to be able to do that. Does that make sense?

CHRISTOPHER:  Maybe you want to talk about the example where you scroll and tap.

JORDAN:  Okay, so one really common example that the web always gets wrong or often gets wrong is if you’re in a scroll view and the scroll view is actively moving because it has some kind of momentum. And then you stop the scroll view and you don’t move your finger, you just stop it, a lot of times on the web the button that you happened to stop the scroll view on will highlight. And it’s active. And releasing your finger will cause some kind of a redirect or a mutation. Now, that’s wrong because the user usually just wanted to stop the scroll view.

And so, there’s nothing there negotiating this at I guess a global or system level. And even if people do handle this correctly they usually special case the scroll view. And so, that really only works in a couple of cases. But what if people want to build their own scroll views or their own modals or their own transitioning scenes that also have these characteristics where they do the right thing and you don’t accidentally tap on a button you didn’t intend to? So, this is what a good gesture system will help you accomplish.

JAMISON:  So, as someone who hasn’t done native development that just sounds impossible and magical. I don’t think I know what I’m missing. Of course you can’t do that. Aww, that’s fine.

JORDAN:  Well, do you agree that when you use a native application usually you don’t accidentally tap on things?

JAMISON:  Oh yeah. No, I agree with what you’re saying that it feels a lot better. It’s just, as a purely web developer it doesn’t occur to me that I need to implement that stuff.

JORDAN:  Right.

JAMISON:  So, I can see what you’re saying, that it needs to be built into the platform better.

CHRISTOPHER:  And so, we haven’t talked about it too much but we’re going to communicate a lot more on this subject in the future.

JORDAN:  Right.

DAVE:  So, can we talk a little bit about debugging a running React Native app?

CHRISTOPHER:  Yeah. So, the debugging experience is the same as the web browser. So, your JavaScript is running React and we can debug inside of Chrome and get all the Chrome developer tools and the React developer tools. And interesting about it, the bridge between JavaScript and Objective-C or Java, it’s just the same as the bridge between the JavaScript environment and the browser. And have you ever tried to step in through the browser on the web? No. And so, this is something that we want to reproduce. And one consideration that we have is the native part should never crash. This means that if you give it invalid input or anything, it should give you an error message or something. But it should not crash. This way you can reload the JavaScript without having to rebuild on everything.

JORDAN:  Right. We’re not there yet.

CHRISTOPHER:  Yeah. [Chuckles]

JORDAN:  Just to manage expectations. But in the same way that a browser is a native backend for what you’re specifying in JavaScript, that’s what the React Native backend should also be. I realize it’s confusing how we’re talking about using Chrome to debug when we just said that we’re using JavaScript core. So, one of the things that was mentioned at React.js Conf was that we, our communication between the JavaScript engine and the native backend is a completely bashed, asynchronous, serializable bridge.

So, what that enabled us was within a couple of hours we could easily get Chrome debugging working. Because all we had to do was just run the JS in a completely different engine and communicate these serializable messages across Chrome using WebSockets into the React Native container, as opposed to being communicated from JavaScript core into the React Native container. So, that architecture made that pretty trivial.

DAVE:  So, are you saying that when you run in the debugger it’s actually Chrome’s JavaScript engine that’s executing all of the JavaScript? Or is it still JavaScript core? I’m a little confused about who’s responsible for what.

JORDAN:  Yeah, so that’s the power of having an asynchronous serializable boundary there and that being your only interface between JavaScript and the native container, is that it doesn’t matter where your JavaScript is running. It could be running on a server on the east coast and you’re over here. It’s just, as long as you can serialize all the messages that go back and forth between the two, and as long as you’re okay with it being asynchronous, then you can run that JS anywhere.

Now, the most natural place to run it when you’re running a production app is in the JavaScript core library that iOS gives you. But if you want to debug you can easily run that JS in a Chrome process outside of your simulator even. And then just send the messages back and forth across WebSockets.

DAVE:  So, on iOS, Objective-C is running some of this code. And is Objective-C the thing that’s doing the serialization over to the bridge and back? Or is it, I’m not totally clear on all the parts there.

JORDAN:  Yeah, very little serialization. It’s really just taking a tree of NSArrays, NSObjects, and just creating a JSON string out of it.

JAMISON:  So, one interesting thing from React is I feel like it has inspired a lot of good ideas in other frameworks. Is this something you like to see more of, especially with React Native? Do you think… Would you like to see someday an Angular Native or Ember Native or some new framework I haven’t heard of native?

CHRISTOPHER:  Oh yeah.

JORDAN:  Well, so everybody on the React team is super excited about learning from other frameworks and also the ideas of React making their way into other frameworks as well. But as far as the native backends, we do think that React is particularly well-suited to doing this type of thing, at least today, because it had always anticipated it. It had no real dependency on the DOM by design. And it also batches up its updates. And the programming paradigm itself is very batch-y as well. So, if there is any other frameworks out there that have all these characteristics that React also has, then yeah I’d be excited about that framework adopting the same sort of native backend that we’re having. But I do think that it might be challenging unless they essentially are React or are very, very close to React.

JAMISON:  So, a related question is React Native, it sounds like it’s important to Facebook internally. And you’re open sourcing it because you want to share with other people. But if someone submits a pull request that maybe the community likes that makes Facebook’s job harder, how do you handle that conflict when you open source a tool that gets used internally and that you’re building products off of?

JORDAN:  I don’t see that happen a lot to be honest. The whole reason why we even open source things that are this far along is because we feel like the things that have helped Facebook actually do help open source. And…

CHRISTOPHER:  [Inaudible]

JORDAN:  What’s that?

CHRISTOPHER:  And the opposite is true.

JORDAN:  Yeah, and the opposite is true. If something didn’t help us and our technology stack, it probably wouldn’t help other people outside of Facebook. So, I don’t really see that many great examples. So, if you have one in mind though, I’d love to hear it.

JAMISON:  I don’t. I’m just thinking about doomsday scenarios.

JORDAN:  Right.

CHRISTOPHER:  Yeah.

JAMISON:  Where React Native 2.0 totally changes everything and you’ve vetted it internally and then you just drop it on the community. [Inaudible] about that.

CHRISTOPHER:  Yeah, [inaudible] with React because the worst thing that a Facebook use case and external use case where it’s very different. And we would see it’s a very different thing. But actually, React is supporting many different use cases. But they all add up and they all make the React library better. So, we’ve got a lot of open source contribution on React that helps indirectly or directly Facebook. And the same for Facebook that help React. So, it’s actually I would say a good, it was a good synergy. And we’re going to see with React Native, I’m pretty sure is going to be the same.

JORDAN:  Yeah, I hope so.

DAVE:  So, can you talk about the Git repository? You offered private access I think to conference attendees.

JOE:  To the cool kids.

DAVE:  Yeah, to the cool kids. Coming soon there’s going to be open access. Can you talk about that schedule a little bit?

CHRISTOPHER:  Yeah. So, we’re not sure yet about the schedule. But we need to get our house in order. Being able to take pull requests, being able to push our code to the open source repo and being able to do trivial things like running your app on a device, we cannot do that right now. So, as soon as all of those are working, like the bare minimum, then we’re going to turn [it over] to everybody. And we don’t expect it to take years. We really want this to happen as fast as possible.

JORDAN:  Yeah, because the longer that we have this GitHub and internal versions, that’s actually painful for us. So, the sooner we can actually get them on the same page it benefits us. And like we were saying, it also benefits the community.

CHRISTOPHER:  No hard dates.

JAMISON:  Yeah, these two… oh, go ahead.

CHRISTOPHER:  No hard dates right now.

JORDAN:  Yeah, no hard dates.

JAMISON:  [Chuckles] I think the rule is, if we make you submit a hard date then next time a boss asks us at work, we have to give them a hard deadline, too.

[Laughter]

DAVE:  So, in the meantime, Jamison will be the only one writing React Native apps.

JAMISON:  [Laughs]

CHUCK:  I love how deadlines are always just bad guesses, right?

CHRISTOPHER:  Yeah.

JAMISON:  Can you talk about the differences in keeping up with APIs in native platforms versus building what was a web framework before? Stuff still changes on the web. But it changes a lot more gradually and it’s more backwards-compatible I feel like.

CHRISTOPHER:  Yeah. So, our stance with this is we want to make the APIs look as familiar as possible with the web. So, if you’re using React Native, all the APIs that talk to iOS/Android, they should look and feel like the web. And we’ve been inspired by Mozilla web APIs that target phones. We want to make a good set of core API like this that is going to probably be the same across versions.

And then we also want to make sure that React Native is extensible. This means that if tomorrow iOS 9 introduces a lot of new APIs, you can write your own bindings of those APIs to your JavaScript without having to wait for us. And I’m pretty sure that the community is going to pick them up really fast. And then when it’s more solidified, we’re going to bring them into the core. Does that make sense?

JAMISON:  Yeah, that does. So, when a new iOS version comes out, people just run out and wrap the new APIs and then you’ll let them solidify and pull them in?

CHRISTOPHER:  Yeah. That’s our thinking for now. We haven’t yet experienced one big thing like this. So, we’ll see when it happens.

JORDAN:  Yeah, I’m pretty sure that that’s also an issue for current app developers when iOS upgrades or we get a new update to iOS 9. Some of the older APIs might be deprecated. And in order to update your app to the newest OS you have to go make some changes in your code. Everybody has to do this dance in any event, really.

JAMISON:  Sure. Just hopefully, you’ll be able to make those changes faster.

JORDAN:  Yeah, I hope so.

JAMISON:  I have one more question. So, I have a lot of friends who are native application developers. And they’re interested in React Native but from a very different perspective. Can you talk about, do you want React Native to be used by JavaScript developers that can now build iOS apps? Do you want it to be used by iOS developers? Is it everyone? Are you aiming towards a specific audience with that?

JORDAN:  I actually think all the above can benefit from building apps really quickly on top of React.js on React Native. And we’ve had native developers give us that feedback. Even though they’re expert native developers, when they step into the React.js world they can iterate really quickly and make design changes really quickly, rapid reload, all of that great stuff. But even if somebody’s not as interested in that and they’re a native developer and they’re more interested in the backend view system and the lower level details, they can think about React Native as a way for them to build these highly optimized lower level building blocks that their skillset would be best at building. And then expose that to a much wider set of developers.

So, their involvement can be that they get to share I guess the results of their expertise with tons more developers than they could otherwise. So, it’s dividing up the roles of development into people who are really good at lower level programming in the native environment and protecting that lower level code from application developers who can easily step on them.

JAMISON:  Okay, that makes sense. So, it might enable someone to be the architect that builds the low-level APIs. And then you can let people consume them. But more people can consume them now.

JORDAN:  Yeah.

JAMISON:  If you make this really solid iOS or Java component.

JORDAN:  Exactly.

JAMISON:  Cool.