Eli White shares the five core principles guiding React Native devolvement: native experience, at massive scale, fueling developer velocity, on every platform, with declarative ui. He shares some insights about how Facebook organizes around features and products — not platforms — and shares news about exciting React Native collaborations with Microsoft.
We have a YouTube channel for React Podcast 🥳
Watch the livestream of this chat with Eli and Subscribe for future chats!
Eli White — Twitter, GitHub, Website
chantastic — Twitter, GitHub, Website
AWS Amplify is the fastest, easiest way to develop web and mobile apps that scale.
Get started building a React app today, check out the tutorial on AWS Amplify today, visit awsamplify.info/react.
In over your head with a React or React Native app?
Infinite Red can help.
They are React Native core contributors who've been designing, building and shipping apps for over 10 years.
Learn more at reactpodcast.infinite.red.
Please join us in donating to the Equal Justice Initiative
Chantastic: Eli White. Welcome to "React Podcast."
Eli White: Awesome, great to be here. Thanks.
Chantastic: [laughs] It's funny. We have gotten to see a lot of each other, talking about React and React Native and what you are doing. We haven't actually had you on the show yet. I'm super excited to get you on, to talk about React's Native. The principles that you're using to lead that project and develop it for the future.
For anyone who doesn't know you yet, can you tell us a little bit about who you are, what you do? How long you've been doing it, and what you love about it?
Eli: Absolutely. I'm Eli White. I'm one of the engineering managers on React Native. I've been at Facebook and on React Native about three and a half years. I've never used React Native before joining the React Native team.
I come from a web background, so I came from the React side, worked a lot of web infrastructure kind of thing. I have a lot of that background that I bring to React Native. I wanted to come into React Native, I wanted to take the things that I knew really well and apply them to an area that I didn't really know anything about which was mobile and React on Native.
That's what my path to React Native came from. It's been really great seeing this new area and working on mobile since then.
Chantastic: You mentioned going from React to Reacts Native and I'm really curious. What were you building with React before and how did that translate to your work on React Native?
Eli: When I was working with React I was hoping web team that built out a web property I wanted to look at web infrastructure side. Working with setting up linters and sharing Webpack configs and Jenkins, CI configs, all that kind of stuff as well.
Then coming to React Native there's been a lot that's transferred over. React Native is very similar to React on Web. You write the same components, you have pretty much the same style properties that you're used to.
The differences are that instead of rendering to DOM Nodes like divs and spans you're rendering to Native UI components. The box components that are provided by iOS and Android.
There's some things that are different that are helpful to understand about mobile as well. Navigation on mobile, for example, is wildly different than navigation that is on web.
Chantastic: [laughs]
Eli: Thinking in that way is different, but the way that you build your UI, the way you think about how you nest components and build out things with Context or Redux, all of that is exactly the same.
Chantastic: That is interesting. I've touched React Native a little bit, but I've been predominantly a web developer my entire career. It's an interesting challenge when you go from web, where you're working directly with elements, whether that be div, span, unordered list.
You're working directly with those and see those show up in the DOM as the way that you put them in. There's an interesting thing that happens that you alluded to in React Native where you're using elements that sit above those native elements. They're native in iOS, native in Android, and whatnot.
There's a level of abstraction. Is that predominantly where React Native sits as a project? Is it just like React, and then React Native is this mapping to those platforms, or is it more complicated than that?
Eli: One mental model that I like to think about for React Native is React Native, in a lot of ways, is like a browser. You write your JavaScript, but it is the thing that provides access to your webcam or to the other system devices.
It provides those APIs and also has the implementation of div and span, and all those things are built into the browser. It does its layout processing. It does how to process CSS and do all those things. That's all in the browser core.
React Native is very similar that React Native takes the JavaScript that you write, but it provides the APIs that let you access native. It does its layout calculation itself. A browser will draw every pixel on the screen, but React Native, instead of drawing that itself, it renders to the actual native components.
React Native is the heart and soul of specifying what you're able to use. The thing that's nice about React Native you don't get on the web is that it'll let you can't add these features to your browser.
Chantastic: Sure. [laughs]
Eli: You can't expose new system capabilities into your browser. You have to wait for the browser vendors to do that. With React Native in your app, you can add new capabilities. You can add new connections between Native and JavaScript and expose those, so you can use those.
One example is a map component in React Native. You might want to render a map, and on a Web, that's really complicated. You have to essentially give up in your import sound like Google Map view that have all of the logic to do everything.
On Native, you're able to import the Apple provided SDK for Maps, and use that in the app itself. As if the browser decided we're going to expose Apple Map's SDK as a component to the browser and instead of having to wait for the browser vendor to do that. You can do that in your individual app.
Chantastic: It's interesting because one of the big contentions or frustrations with the Web is that it is a much less, I don't know, high fidelity platform than Native platforms. A Native like Mac OS, or Windows, or mobile like iOS and Android, they have a huge amount of fidelity and responsiveness and APIs that let you do tons of things.
It sounds to me when you're using Reacts Native, you actually get to use these really high fidelity APIs instead of depending on, like you said, some big cluster of JavaScript, Canvas, or whatever, that gives you that opportunity in the Web but isn't actually a Native experience necessarily.
Eli: Yeah, exactly. This actually ties into our first principle which we'll probably talk more later. One of the thing's pretty interesting is that when you think about the different platforms between Web, and iOS, and Android, the highest bar that users have for any experience on those platforms is that of iOS.
People have a really high bar what they expect, the experience of that platform to be. It might be, maybe upsetting to this audience, but in a lot of ways, Web has the lowest bar of the experience people expect. We get away with a lot of things on Web.
We talked about trying to avoid junky animations. The standard is junky animations and we try to avoid that. On mobile, a single frame drop in an animation is not acceptable. People really hold you to that bar. For us on mobile, using a web view doesn't cut it. You can't get to the level of fidelity that people expect on iOS.
It's really important for us to be experiences built on React Native really meet the bar that people have for that platform.
Chantastic: This is a really interesting differentiator for React Native, I've always thought is that so many people want the ergonomics of JavaScript, HTML, CSS, and have put that into a web view on an application. It works but you're getting the ergonomics but then sacrificing the user experience.
It feels with React Native, you've really tried to flip that. You still want those ergonomics of JavaScript to being able to have bring your web developers in and have them be effective in the product, but with the value of these Native components that that feel and look great and predictable in those environments.
Eli: Absolutely, and get into our principles. The reason that immediate experience is our first principle is because we will trade off developer experience to give people a user experience that is what people expect for that platform.
Chantastic: I do want to talk about the principles but first I want to back up just a little bit because we're just barreling towards those principles. I really want to get to those, but I want to ask, setting up principles feels like a really important part of a project.
I'm curious. You wrote this article detailing your five main principles for React Native. I'm curious, just before we go into those, what types of experience have you had leading this project that led you to want to redefine those principles or establish them at this point in 2020?
Eli: React Native has a bunch of different stages of its life.
Chantastic: [laughs]
Eli: When React Native was first announced, React Native came out of the gate saying like, "We're a bunch of web engineers. We know how to build apps. Hey, mobile engineers, you've got this all wrong. Don't worry about it. We'll fix this for you. Don't do what you do anymore. Be web engineers now."
Chantastic: [laughs]
Eli: That was a big mistake on our part because that's not how we felt. It's set the wrong tone. I think a lot of engineers that are really great Native engineers, they see React Native in that mindset.
They see these web engineers who know nothing about native -- they know nothing about what the expectation is of the platform -- are coming in and saying, "We don't need mobile developers anymore." That's not how we feel.
We figured that it's important for us to tell how we do feel and what our story is. People have been able to guess and talk about things, but it hasn't necessarily been aligned.
Instead of responding to each individual person saying, "That's not what we believe," it's easier to get pulled into the trap of what we don't believe. I wanted to focus on what we do believe and the things that are important to us.
Chantastic: I'm curious about the nuance of how that actually manifests or...You mentioned routing a little bit earlier and how it's distinctly different on the web versus native platforms. Obviously, that was a challenge and something that you had to learn from native processes and engineering.
Were there other things that rose to the surface as challenges that you needed that clear lines of communication between this React Native JavaScript type of experience but then also native knowledge and whatnot.
Eli: Yeah. There's a bunch of different things in this category. People who have expertise on native, they know how to debug native apps, and improve the memory, and be able to think about the lifecycle of applications, and have all the [inaudible 12:28] around that, how to set up CI for iOS and Android apps.
They help maintain the bar of what the experience is on these native platforms. You have a bunch of iOS engineers or Android engineers, and they're going to not let you use React Native as an excuse.
Chantastic: [laughs] Yeah.
Eli: We want to make sure that people working in React Native don't say, "Oh, we can't do this because it's React Native." People can fall into that trap. It's easier on web because you don't have any other choice. You can only do what you do on web.
Chantastic: Sure.
Eli: One of the perceptions that people have with React Native is that you can do everything in JavaScript. You can do a lot of things in JavaScript, but React Native doesn't mean JavaScript. One of the things that's important to us is that you use native code when you need to.
That isn't avoiding React Native for a certain part of the application. That is a core belief of React Native that if you need to bridge new components, APIs, or implement something natively because it's too complicated or too confusing to have in JavaScript, there's already existing code in native to do that. Using it in native is still React Native. We want to encourage that.
Chantastic: That's interesting. I imagine that there's a perception to someone who's investigating these things, thinking like, "Well, there's not like a React Native library for this thing," or, "It doesn't do exactly the way that I want to."
It seems like that experience has improved and I guess augmented by having people who are familiar with iOS, Android, and all the other platforms that you actually target. They can actually now have a better space to work together than they did before. We're just like you have one team dedicated to one platform. That's basically it.
Eli: Yeah, exactly. It obviously depends on the scale and size of your company.
Chantastic: Sure.
Eli: When people consider React Native, we don't want them to say, "Oh, this means that we don't have to hire iOS, Android engineers. We're just going to hire web engineers, and we'll be totally set."
Maybe you're starting a startup, you have two people, maybe that's fine. As you grow, the way that we see it, and the teams that we've seen have the best success are teams that still have some native engineers. The ratio of native engineers to people who have a JavaScript background, it can be very different than it would be with just native apps.
Chantastic: Interesting. I'm curious. Since we're on this topic, what does that look like at Facebook? You have the tippity top of scale issues, right? I'm curious. What does this look like at Facebook using React Native? How's it being implemented? As much as you can tell me, and what are those handoffs look like between your teams?
Eli: On the product side -- which might be most interesting to you but pushed me in a different direction with that -- people are mostly organized around features and products and not around platforms. You will typically have teams that go and build the same feature for all the different platforms.
By being able to have shared knowledge or expertise, that helps a lot. People building this for web can also build this on mobile. The teams that do the best with React Native have a couple of native engineers on both platforms that can help many of the places they need to, bridging different API's, thinking about different architecture for how things might be laid out.
That's what we see. One of the things that's interesting for us at Facebook is that we have a lot of different choices for how you can build your application. There's nothing prescriptive about which framework you have to use. Our native frameworks and component Litho are actually heavily inspired by React.
Even if you're running iOS native code or Android native code, you're still working with components and with props, and with very similar mental model. That's been helpful as well, that native Android engineers can still have conversations about the JavaScript React Native application that's getting built on top of it.
Chantastic: That's interesting, this notion of everyone rallying around components regardless of if they have a Native framework, a web framework, or React Native that's bridging them.
It seems like this whole concept of components, if I remember correctly, even started back in like PHP. Before React, there was this PHP model of a component. That migrated to what we know as React today. Has that been an unmitigated success for Facebook, the notion of components? Have there been some drawbacks?
Eli: I think components are everywhere. I don't think we really do much anywhere that isn't with that mental model. Components have a drawback that isn't Facebook-specific. It's shared everywhere. We might have solved where behavior lives into these individual components, but then finding the right components to use becomes the problem.
Once you have all these how do you distribute them and communicate them in order to make them findable. This is a problem of the matter which technology you are in, this is one of the shifts to components that I've seen. There's much tolling internally to help make us better but it's not a solve problem as I've seen it.
Chantastic: [laughs] Nice. I love the idea that you mentioned just a bit ago about how you have teams that work around a feature or a product and try to bring that to the different platforms.
I find that really interesting because it flips the expectations around a little bit where you'll have someone whose maybe an expert in this type of technology and what not. You bring them in to do that part of the stack for that feature. I'm curious, does that work well? Is that something that smaller companies could model?
Eli: Yes. For Facebook, we have a lot of experts that are experts in individual platforms or technologies. Facebook values generalists. They can jump between anywhere. The experts can help in the areas they know. They provide infrastructure, two lanes, make things better, make things that used to require experts be accessible to generalists.
That's the way we think about a lot of things. I think that's a part of React Native as a whole is that mobile used to be only accessible to people with deep need of expertise, but the up leveling with components, and with React Native as a whole has enabled this kind of thing that's required expertise to be done. The balance has shifted a lot more towards a generalist supported by fewer specialists.
Chantastic: I like that. That's something that I find interesting as an industry. It feels like we're moving closer and closer to product where it's like we want to be able to service customers as quickly as possible.
We're trying to build technology that allows more people, or a wider spectrum of people, to be able to deliver on those features faster and in more places. It feels React Native is one of those projects that's at the center of this.
Eli: Both React and React Native, we see them as one unit, that are very much at the center of this.
Chantastic: Yeah. I'm curious. Before we dive into principles, what are the major platforms that React Native is targeting right now?
Eli: React Native is a framework and a technology that transcends Facebook. React Native supports significantly more platforms than our team at Facebook supports. It's an interesting conversation. Both sides of this are pretty interesting. Facebook, historically has only supported React Native in iOS and Android.
There has been other companies that have supported a bunch of other platforms like Apple TV. Microsoft has been driving a lot of work around Mac and Windows. You have companies that build React Native for a whole bunch of different TV platforms and Roku and Tyson. It feels like if there's a screen, React Native runs on it.
Chantastic: [laughs]
Eli: It's pretty cool.
Chantastic: For anyone who's unfamiliar with the technology, we got the broad picture of the technology and how it fits in at Facebook and how your team's working to support more generalists.
I want to talk about these principles, that you wrote a great article on, that are driving the current and future development of React Native. I'm going to list them out here so we know the pillars. Do you have a question? Sorry...
[crosstalk]
Chantastic: [laughs]
Eli: When you're talking about platform, React Native started with iOS, Android, and Facebook but it supports all the other platforms. We'll talk about this more at the end of the things that I'm excited about.
One of the things that we're doing now on our team Facebook is partnering closely with Microsoft to support Windows and Mac. We're building up a team to do that because we have products now at Facebook that are using those. I'll talk about that more at the end. That's something that our team at Facebook is now supporting these platforms as well.
Chantastic: That's awesome. That's one of the things that I've been most excited about in hearing from you is all of the new places that React Native seems to be popping up and all the new platforms that it seems to be servicing.
That one with Microsoft is particularly interesting and gives something for our listeners to look forward to in the next 15 minutes or so. [laughs] I'm going to read these principles off. They are from top to bottom, we have native experience, massive scale, developer velocity, every platform, and declarative UI.
Now we've touched on a couple of them, but I'd love to hear the principled version of these first. Let's dive into Native experience. Could you talk a little bit about what Native experience as a principle means?
Eli: In our blog post, which you'll link in the show notes, the first paragraph for each principle is the bite-sized, tweetable form of each principle. In fact, each one is of the length that it could be tweeted.
Chantastic: [laughs]
Eli: That's probably a pretty good place to start our conversations about these. For native experience, our top priority for React Native is to match the expectations that people have of that platform, kind of what we talked about before. This is why React Native renders to these native platform primitives.
We value the native look and feel over cross-platform consistency. This is how we think about React Native. The goal isn't 100 percent read code for use. The goal isn't that you write one piece of code and that will run on every platform, look and feel exactly the same across all platforms. It should look and feel like people expect of that platform.
One of the ways that we think about this is that when people want to make a decision about an app, they don't compare that app on iOS and Android and any other platform to see like, "Oh, this is consistent. This makes me happy."
Chantastic: [laughs]
Eli: Instead, they check whether that app looks and feels like other apps on that platform. If you're app scrolls differently or has different bounce behavior or animations feel subtly off, it doesn't matter if it's consistent with other platforms. What we believe matters is that it matches people's expectations of the platform that they use.
Chantastic: That's a pretty big challenge, I imagine. [laughs] Consistency with the platform versus consistency with your experience across platforms is maybe a level of consistency that people aren't used to thinking about consistency at. It's easier to think of it as AI.
This thing looks exactly the same everywhere versus this thing looks as its environment does on all of the platforms. [laughs] Is that a challenging way to think about things or talk about them as you introduce React Native to people?
Eli: It is for people coming from web, and it really is not for people coming from native.
Chantastic: [laughs]
Eli: People coming from web, you're used to building a website on a browser, and that experience on a browser should look the same no matter what browser you use. When it isn't, you're upset at the browser...
Chantastic: [laughs]
Eli: ...but in this case, and not because you don't know which browser people use, and it's interchangeable. When you use a different Native device, you're very much locked into that Native device and know what that platform should feel like. It doesn't matter what it feels like on other devices to you.
Chantastic: [laughs] It is interesting because, at least with the developers that I've talked to, they hold very closely to the interface guidelines for those platforms. It's very important to each person that the experience match the surrounding apps as best as possible.
Eli: Absolutely. You asked one of the reasons why we created these principles. One of the things that's really helpful is that there's a lot of different technologies in this space now with Flutter, SwiftUI, Jetpack Compose, and a bunch of different choices that people have, let alone web views, when thinking about these.
The trade-off that people often talk about are performance or who created it. That's not the things that we want people to think about. There are different trade-offs that are aligned with different goals. We want to talk about the things that matter to us to help you understand, if you're deciding between these technologies, which ones you feel aligned with.
For example, Flutter, I don't want to speak for them. I haven't seen a post like this from them, but my understanding is that they don't have the same principle.
For them, it matters much more that the experience is the same across all platforms, not because they want the experience to be the same across all platforms but because they want the developer experience to be so great.
They want you to be able to confidently write code and have confidence that it's going to work the same way when we write it. For us, we make sure that we tell everybody working with React Native at Facebook that you should be testing your experience on all of your platforms because they should behave like that platform.
That's a difference between these different technologies, that I would love to see a document of the principles from the other frameworks.
Chantastic: This showcases your belief that if it comes between a user experience and a developer experience, you're going to choose the user experience over the developer experience.
Eli: Absolutely.
Chantastic: Interesting. I want to move on to the next one which is the massive scale. I'll let you read the tweetable version of this, and we'll go from there. [laughs]
Eli: The Facebook app is used by billions of people on huge range of devices. There's hundreds of screens in the Facebook app that are implemented with React Native. For our team, it's important that we focus on the issues that we see at that scale, which is also saying that there's a lot of things that we aren't able to focus on because they don't cause us the biggest problem to the scale.
Our team is only a certain size. We can't focus on everything. We have to draw that line where we needed to. There aren't that many companies that are using React Native at this scale, if any company other than Facebook is even close.
The things that we're most uniquely situated to solve are the things that we should focus on. As I said before, React Native is much larger than just Facebook. There's a big community around it, a lot of other companies that operate at lots of other different scales.
We want to enable other companies that operate at those scales to focus on the things that impact them and provide that back to the ecosystem. As we think about the APIs who provide and how we set up the community to be able to build third-party modules and contribute, we want to help people contribute at the scale they're comfortable contributing.
For example, here, as a difference in focus, if there's an issue that comes up that is about a specific prop in a certain way that we don't use it, we are less likely to jump into that than we are to jump into disk utilization on Android.
Low-end Android devices slows down React Native. It requires tons of changes in the core of how we architect the whole framework to be able to address making React Native run better on Android devices.
We try to focus on these bigger problems that will have the biggest impact for the scale that Facebook operates at and enable the community to solve some of these other problem.
Chantastic: This is interesting to me. One of the things that I have enjoyed about using React is that I know that it's being used by Facebook. For any indie product that I make or things that I make with significantly fewer users, there's going to be some consideration for the problems that I might face, already baked into the framework.
I love hearing that you're using it, and understand, and build new solutions around the problems that you have at scale. There's also another benefit to this. It sounds to me that at Facebook, because people get to choose their own tooling, you have to be very adaptable framework.
You have to be able to fit into the way a certain platform or product is making those decisions. You can't own the whole pie and be like, "Well, this is a React Native app. We're building it from first principles on React Native." How has that necessity guided the way that you build out React Native?
Eli: The biggest way to me is the way that we've approached our community and our other partners. I want to plug Expo here a little bit. For those that don't know, Expo is a managed toolkit to create React Native applications with a lot of the capabilities that you need built in.
Focused on new applications, but they've also been providing a lot of their toolkit to existing applications as well. They're creating a high-quality building blocks that people use.
The interesting thing for us at Facebook is that we aren't spinning up new apps all the time. We have a couple of massive apps that were existing Native apps that we do integrate React Native into. For us, we need to be able to focus on those kind of problems.
We aren't in the situation that we would be investing in creating a way for people to spin up tons of apps and make that streamline. If we did, it would be out of the goodness of our heart to build up our developer community. We wouldn't be able to invest in it and provide as much success to it as the community would want.
That's an area where Expo has stepped in and made that successful by helping teams create new apps and make it easy to get started. For us, it's more important to build our relationship with these companies and enable them versus trying to do it all ourselves.
Chantastic: I just have to say that the stuff that Expo is doing is really cool. It's been fun to see all of the cross platform libraries that they just make it really easy to get started and start using on...Even on web, they have some great libraries that work on web.
I know that working at this scale has mandated that you invent new tooling. Some of the things from that article that have popped out of that are Hermes, Fabric, and TurboModules. Can you talk a little bit about what those are and how they were birthed out of React Native?
Eli: First of all it's Hermes.
Chantastic: Oh, is it? [laughs]
Eli: The other name may have some trademarks around it.
Chantastic: Oh, got you. [laughs]
Eli: Hermes is our JavaScript engine built specifically for React Native. This is a great example of what it means for us to focus on scale. As I mentioned, Android devices have slow disks. Our focus there is to serve the billions of people using React Native on Android in the Facebook app.
There's only so much that we can do, loading JavaScript off-disk. With an existing JavaScript VM, you have to load source code, the entire JavaScript bundle, and then parse it and compile it, and then start executing. That also has to happen on the startup of your application.
In a Web, you have browser tabs that are around forever. The startup matters but it also matters, can it still be fast after being open for a week. That is not common on mobile that you keep the same screen up for a week. What matters a lot is how fast you can start the app, switch apps, and come back to it and get back right where you were.
For us, we needed to be able to make it so that all of that work that's really common to a JavaScript VM goes away. For Hermes, that's really the main focus is really optimizing for startup performance on mobile.
It's not a thing that anybody can do, creating a new JavaScript engine. This is not a fork of the eight, this is not anything that existed from scratch JavaScript engine. Instead of parsing JavaScript, we compile that JavaScript to bytecode, that is then directly executed off disk. There's no JavaScript source, there's no parsing, there is no evaluation. It is actual bytecode instructions.
Chantastic: [laughs] It so well ties into this whole notion of...That's something that Facebook could not have done. [laughs] You're going to have to be at a certain level to take on a project like that and actually optimize around that. I imagine that was a non-trivial effort by some very talented engineers for an amount of time.
Eli: Yeah. There's only so many JavaScript engineers in the world.
Chantastic: [laughs]
Eli: Not just any company could have thought of that. Even be able to invest in that. We're able to invest in that at Facebook because it has such an impact on Android where the Facebook app is so important. I don't think any other company has the sale that would warrant that investment.
Chantastic: Just out of my own curiosity, I know that Apple, in particular, is very particular about the engines that run on its platform. I'm curious did that infringe on some of their guidelines for that? Were you able to work around them with success? Did you have to work with them to get this thing to work?
Eli: As I mentioned, Hermes is there to really solve our problems on Android and the desktop Android. Hermes is the Android JavaScript engine. The disk on iOS is much faster than the disk on Android, but it's not as much of a problem there. The focus has really been on Android.
Chantastic: Fascinating. It's interesting to me because I didn't realize that you're able to do that even at a platform level. This is effectively just for targeting Android and the limitations there versus iOS which have, as you mentioned, faster disks and can use the platform that's available.
Eli: Yeah. The impact on Android is much greater than the impact would be on on iOS. The optimizations are still valuable. Not parsing the entire JavaScript bundle, it would only lead to wins. It would provide value. Callstack has actually been working on bringing Hermes to iOS and investigating that and what wins people might see. Our focus has really been on Android.
Chantastic: Interesting. Thanks for clarifying that for me because I had no idea. Fabric, that seems awfully close to Fiber in that we got in React to a couple years ago. Are those two related?
Eli: Yes. Fabric and Fiber are very similar in their missions and approach. I don't know that many people remember React before Fiber. React got to a certain point where they couldn't bring the capabilities and the optimizations that they wanted to bring on the architecture that existed.
They re-thought the core of React without changing the public API to be able to unlock these new capabilities in the future. We think about Fabric the same way. We have a couple of different big architecture projects that we're working on to address...
Similar to Hermes, we see these patterns that are problems throughout the stack, none of which is something you can fix that one individual problem, we have to change the whole system.
We've been working on this new architecture that will solve a lot of these challenges that we've run into and up-scale while not requiring much changes on the product code side. Trying to be an under-the-hood improvement that will unlock a lot of capabilities for us in the future.
Chantastic: Nice. Were there any other things on the scale side of things you wanted to cover before we move to Velocity?
Eli: We should move on.
Chantastic: Let's move on. Getting too much in the weeds right now. [laughs]
Eli: This is great. I love these questions. I am really happy talking about these principles. I wrote this and the main goal for this whole document was sharing and people have conversations about it. This is a starting point, not an end point.
This is what drives React Native and we want to hear from other people how this lines up with their opinions and other technologies. This is really about a conversation so I'm glad we're having this conversation.
Chantastic: Me too. That brings up a really valuable point is that sometimes people see principles like this is, I don't know, maybe being restrictive or whatnot. I am so glad that you mentioned that because being able to say what your values are open up discussions.
You can talk about how something that you want is aligned with this principle or unaligned with this principle. That doesn't mean that you can't do it. It just means that we got to rework it to fit into these principles and these guidelines.
Project like React Native would just fall apart if you didn't have any guiding principles. There's just too many people who are interested in having it be tailored to a certain way to just say yes to everybody. [laughs]
Eli: Exactly. One of the other things that's interesting here is that these aren't the React Native principles. These are the React Native team at Facebook's principles because React Native is much bigger than us. Expo has probably different principles as we work on React Native than we do.
That's one of the things that's really valuable for our ecosystem is that we're able to support these other partners to have different principles. We figured it's really important to share ours because we've been the one driving this project from the frontlines for a while.
Chantastic: Expo is a really great example of something that can be aligned but have different principles and try to solve a different part of the problem that you're not allowed to. I love that.
Developer Velocity, that's the third of the React Native team principles. I'll read this one. This one says, "It should only take a few seconds to see the result of code changes." Talk to me about that one. That one seems really big and hugely important for a company as big as Facebook, where one second for every developer that works on something is, hours a day. [laughs]
Eli: When you're running on our scale, the number of engineers that we have, we have dashboards that measure how many years per day are spent running Yarn.
Chantastic: [laughs]
Eli: When you can save a little bit of time from something that really impacts a lot of people. It's not just we are driven by a lot of these things at Facebook, but by providing an open source we know that we're really changing the game for companies all around the world.
If you're creating a startup, being able to move fast and try a bunch of different ideas, iterate, and find product market fit, that is incredibly important to you.
For us at Facebook, we have so much that we want to build on the product side and so much to do, that if you can let a team do everything they're doing with half the number of people, that other half can take on bigger challenges and have a lot more impact. We really value developer philosophy in making this easy.
Chantastic: What are some of the things that have been introduced to React Native to make changes in development super snappy?
Eli: A lot of what we're comparing against is mobile, which is minutes-built process after every change before you can see anything. That's not what people expect from web. Maybe the listeners here are a little bit skewed in that direction.
When you think about things like fast refresh which came to React Native first, it makes that save and reload experience seamless. It's not just about how long it takes to see a coaching. It's not just about that refresh cycle. It's also about how fast you can debug problems and the tools you have available.
For a lot of companies, it's about OTA and being able to ship updates to your app on your own cadence instead of on a weekly cycle. You can just ship, and it's live. That is all our thinking, that empowering those kinds of changes is a really important part of React Native.
Chantastic: This is something that I think web developers like myself just have zero context for, when refreshes are pretty fast even on a slow web app. Taking control of your deployment is like...For me, I just think, "I'll push this in, and in a couple of minutes, it'll be live on the web."
For native, you actually have to get approval from a different company. [laughs] Tell me a little bit, for those who aren't familiar, what this life cycle usually looks like and how React Native allows you to bypass that whole thing?
Eli: For a lot of companies, they might have weekly or bi-weekly release cycles for their native apps because going through the process with Apple, and Google Play might be pretty complicated. One of the things that was really cool is that Microsoft built this system called CodePush which essentially lets you ship like you're used to on web.
You can just publish a new version of JavaScript, and then the app will start up and download that new bundle and execute that instead. A lot of companies are using this and having a great experience with OTA. For the companies that use it, it's not about shipping new features. It's about being able to quickly fix bugs.
Notice if there's a crash and be able to resolve that crash right away instead of having to wait a couple of weeks for that to go through. It's been cool to see Microsoft having that stack. Expo has theirs with OTA update system.
I know Shopify have been sharing some of the other things they've been doing on QRs. You can scan a QR code, and it will download the bundle from that poll request and load from that on the actual native application. Those kind of things are not possible with a native application and part of the release that is possible with React Native that companies are doing.
Chantastic: I love that. I love that that is something that the website is able to bring to native platforms. You can bring that particular experience and being able to push updates into your product without having this big, weeks-long song and dance with third parties.
Let's move into the Every platform, because I think this is something that you're super excited about and seeing the places that React Native has gone this last year. Tell me about this Every platform as a principle.
Eli: I'm reading the first paragraph here. When we introduced React Native in 2014, we presented it with the motto, "Learn once, write anywhere," and we meant anywhere. Developers should be able to reach as many people as possible without being limited to the device model or operating system that people are running on.
React Native -- we've talked about this already -- isn't just about iOS or Android. It's also about Windows, and Mac, and VR, and game consoles, and web. It's about the way that people write UI and not about the platform.
That's something that we believe in. React and React Native aren't separate projects. A lot of it is meant to be very much the same. The way that people write UI and the things they learn should translate anywhere.
React Native pushed a lot of this with what you're able to write. We also now see this influencing the way that people write, even native products in terms of the mental model being the same with SwiftUI, Jetpack Compose, and Flutter.
For us on React Native, our goal isn't necessarily to have write once and run anywhere, but to have the offering experience to enable you to build great experiences on individual platforms. We've been doing that now with Windows and Mac at Facebook as well as iOS and Android.
Chantastic: That's awesome because I naturally think of...When I was introduced to React Native, it was specifically targeting iOS and Android, but now you mention this is going to desktop, to different types of devices, to TVs, and whatnot. Tell me a little bit about the partnership that you have with Microsoft right now building desktop experiences with React Native.
Eli: When we open-sourced React Native a couple of years ago, we never thought about other platforms being a thing that we would need to focus on, because Facebook is so focused on our mobile apps on iOS and Android.
Then Microsoft started using React Native. They realized that their developers want to write in JavaScript. That model worked really well for them. Microsoft has been doing amazing building out React Native for Windows and Mac.
Some of the built-in applications that ship with every version of Windows now are written in React Native. Every copy of Windows includes React Native in it, which is just mind-blowing. Some of the applications on Xbox, itself, are written with React Native.
Chantastic: Unreal.
Eli: The whole Office Suite has certain parts of the apps across all of the platforms that are written in React Native. It's become a big thing for Microsoft. They were doing that on the side with consultation and partnership with us. Now, for us at Facebook, we actually have a use case for React Native on desktop.
One of the things that's important to us right now is helping people connect even when they're remote from each other. That's important and part of the mission here. One of the things that we've been building out is Messenger desktop.
Messenger desktop had been an Electron app, but there are some things that we want to do that aren't possible in an Electron app. There's a lot of limitations that it has. We were investigating like, "Do we build Messenger Desktop with a native iOS Android app?"
The answer was this React Native for Windows and Mac thing works really well, this works out. We've been building up a team here at Facebook, that I support, that is building out React Native for Windows and Mac in partnership with Microsoft. We operate like we are one team across both of these companies.
Chantastic: Wow. That's awesome.
Eli: We chat at least once a week. Engineers on our team should feel just as comfortable with engineers on their team as they do with other engineers at Facebook. This has been our relationship. We want to make React Native on desktop a really great experience.
We're having great success with it so far, versus Electron-based Messenger Desktop was. We're going to keep pushing that forward. We're just at the very beginning of that. I'm excited for that feature.
Chantastic: That really speaks to earlier points of the extensibility of React Native to be able to be introduced to platforms that it wasn't previously on. Then also, it's flexibility that it can go and support a portion of Microsoft Office. It doesn't have to own the whole thing.
That is just really fascinating to me that this project can go anywhere that it needs to go to help people, be more productive in a wide variety of environments.
Eli: That's part of our focusing on massive scale principle as well. There's thousands of different screens in the Facebook app. Last time I checked, a couple months ago there was 850-ish screens in the app written in React Native. Being able to enable existing apps have parts of it written in React Native, versus the entire app having to be in React Native is really critical to us.
Chantastic: I want to get into this last one. Was there anything else that you wanted to say on the Avery platform before we move on?
Eli: No, that's great.
Chantastic: I've just been enjoying talking to you so much and I realized we've already been on for [laughs] an hour or so.
Eli: I am happy to keep talking for a little bit longer.
Chantastic: The last of these principles is declarative UI. Tell me how that fits into the React Native mission.
Eli: Yeah. I'll read this first. We don't believe that deploying the same exact interface on every platform. We believe that it's important to expose each platform's unique abilities with the same mental model, the same declarative programming model. For us, our declarative programming model is React.
React is like a heart and soul of what we use. It's what we use in the Web. It's the mental model. It's the capabilities. It's hooks. It's the way that you write applications that shouldn't be tied to any specific platform. That should be the way that you write UI for any platform.
It's important to specify here that React is one of React Native's principles. We're not going to diverge from React to do something different. We really want to stay aligned with React. As I said before, we see it as one and the same.
Chantastic: Yeah. I love that. That really ties back to the original vision of learn once, write anywhere that you could take React and apply it to all of these different platforms which you've seen tremendous success in over the last 10 full years.
Eli: This ties into the stuff I'm excited about which was part of your agenda for one of our last topics. Are you ready for this?
Chantastic: Yes. I'm totally ready. Tell us what you're excited about. What's just getting you excited now that this technology seems a little bit more fleshed out? What are the things that are on the horizon?
Eli: We talked about desktop. That's a really new thing for us. I'm really excited about that. There are a couple of things that people might not be thinking about with desktop that are interesting. For us at Facebook, iPad and Android tablets are a big deal in terms of absolute number of users but we don't [inaudible 58:02] invest in that as we do for iOs and Android.
There's a lot of things that you need on desktop that are very similar. For example, on a desktop application, you might hit Tab to navigate through the interface with your keyboard. That's what you expect from a desktop application but it's not something you do on a mobile app.
You don't do that really having a touchscreen. We have to figure out what that means on Mac and Windows. How do you build a Native application on Mac and Windows looking feel that platform and exposes capabilities React Native?
As we figure these problems out, we get to bring these solutions into React Native itself, which provide value to iOS and Android because you can plug a touchpad and keyboard into an iPad. You can plug a mouse and keyboard into an Android device.
You have the same kind of controls, but most things don't think about that, because you have to build it out as a first-class citizen for desktop. We can bring it as a first-class citizen to iPod and inPod. It's not just about desktop either. Web has the same needs. Web needs to figure things out.
Chantastic: [laughs]
Eli: As we think about these APIs, one of the things that we need to do that are cross platform. As we talked about before, it's not just about iOS, Android. It's not just about desktop. It's about VR and TV and your controllers. It's also about web.
We want to make it easy so that you can build applications across all technologies using 95 percent of the same codebase and using the platform where it matters. For us on web, there's a lot of opportunity there.
That's kind of the dream that everyone's had for a long time is that an engineer who knows React in one codebase. 95 percent of it can be the same between web and mobile. A lot of teams externally from Facebook have investigated that signing.
Expo is doing a great job of driving this forward and bringing a lot of these capabilities to web for React Native. Those thing that I think about is that in a lot of ways React Native is a toolkit on top of React for building high-quality experiences.
React is the core of the mental model of the APIs provided. React DOM exposes the low-level APIs to divs and spans of events and that kind of thing. React Native built on top of that with the patterns and components and hooks and things that people need to build an application that's high quality across any platform. I'm excited that as we build this out, we can start thinking more about web that makes this cool thing.
Chantastic: It's funny, as you're talking about that, I'm just thinking about how hard it is at the moment to support devices on the web, how difficult it is to support devices that have a keyboard, which we expect, but then also are capable of touch technologies because more and more devices are giving you both experiences.
It's something that we're just bad at right now, and I love this kind of virtuous cycle that React Native is already trying to figure that out, and through figuring that out provide libraries and concepts and ideas to help out all of the platforms including the web.
Eli: Something we mentioned earlier is being able to make it so that product development is more accessible to generalists regardless of the platform. That's a big piece here as well. You talk about keyboard navigation on web and then adding touch is hard. You have to be an expert at these systems to be able to do that.
For React Native one of the things that's important to us is trying to figure out what these patterns look like that can be more accessible to a broader swath of the developer ecosystem. There's millions of developers that know React and making them more effective in the ways that they want to work in the areas where they can have an impact and be useful is important.
We think about this a lot as we think about lowering the barrier to development. There's a lot of coding boot camps where people come out and learning React. That's amazing. A couple of weeks of learning and people are quite productive.
Now, the things that we can do in React and React Native that require less expertise in the common case and make it more effective. We still need the experts to drive the expectations and drive these things forward, but we can shift that balance and make it more accessible to more people.
Chantastic: I love that vision. Over the next handful of years, that is where things are going to happen. Being able to give people with an idea like every opportunity to very quickly spin up that idea and prove it and make a product out of it is going to be more accessible to non-programmers.
I love that you're really driving this forward, and I think a unique focus on product as opposed to more cool developer tooling that makes us feel more hipper or happier, but focusing very narrowly on how do we get product to customer quickly and narrow that gap? I love that, and I'm excited to see that is something that is picking up steam on more and more platforms.
Eli: Us too. [laughs]
Chantastic: Before we wrap this up, is there anything else that you wanted to say that I didn't get to ask you about yet?
Eli: This has been great. Thank you for talking about all of these principles, and having this conversation about it. This is what I wanted.
Chantastic: [laughs] This is what I wanted too. I'm really grateful you made the time to do it. I love seeing this pop-up on the web, because as you said it really opens up an opportunity for conversation and investigate a little bit further into why is this the most important thing?
Why are we veering away from other things that seem just as important? Thank you for writing it and coming up on the show.
Eli: Absolutely. If other people want to have conversation about this please tweet at me eli_white and I'm sure it will be in the show notes as well. I really want to have conversations about this.
Chantastic: That brings up a good close for us is how is the best way for people to contact you, get involved in React Native development and future discussions?
Eli: Twitter is the right way to contact me for following along with the big changes in React Native. We have a repo called discussions and proposals. That's a good way to follow along. If you mark that repo as watched and get notifications there without the volume of notifications in the main React repo. A lot of the big changes that are happening we discuss there.
Chantastic: We'll definitely link all of those things. Eli, thanks again for your time today. This has been illuminating and super fun for me.
Eli: Awesome. Thank you very much.