 trying to understand react, react native and the whole ecosystem and the whole idea of like building apps and websites. I am I am standing here in front of you to talk about react native specifically. But before I begin, how many of you here have written websites that use react.js? Almost every a pretty good number, that's good. How many of you here have written mobile applications applications for iOS or Android using react or react native? Okay, that's a good number to that. That's pretty amazing. I mean, it's not usually common to see such a good mix of audience. So this is good. How many of you have written any sort of a mobile application? Even more awesome. So in this talk, I would like to introduce to you this technology called react native, which is a way to build mobile applications for iOS and Android. And rather than trying to tell you how things are done, I would prefer to say why it was done the way it is and what's coming. And how does the whole thing work really? So let's get started. My name is Parshuraman. I work at Facebook on react native. I'm based out of the US and as I mentioned, I was traveling here, trying to talk to people and understand what people use to build their mobile applications. I've also been involved in creating or working on cross platform, JavaScript based frameworks for a while before my involvement with react native. I was at Microsoft where I was helping out with this framework called Apache Cordoba or PhoneGap. How many of you have heard of PhoneGap or Cordoba? So I'm actually a commenter in the Apache Cordoba and the PhoneGap project. And I also used to work under the leadership of Xamarin. So I've been working on hybrid technologies for a while right now, almost five or six years. And the current state of the world in which people are used more and more people are using hybrid technologies to deliver first-class user experiences for mobile applications is pretty exciting. In the last talk, Wipple was talking to you about how react works and how do people typically think about UI engineering or structuring web pages, right? It's all about components. Any complex structure that you have on the page, you basically look at the page and start trying to break it down into smaller components. In fact, all of these concepts of props and states are not JavaScript specific. They're not web specific. The idea that react is bringing to the world the idea of concepts of props of state is actually being used outside the web world into multiple other places. For example, if you look at Flutter, for example, the idea of the states versus props is similar to what exists in react. There are also similar frameworks for iOS called ComponentKit or Lito for Android, which use similar concepts. So I think we all can agree that writing components seems like a same and interesting way to build user interfaces today. Now, the interesting thing to note is because these are the building blocks, let's start from components and look at how we can transform our idea into delivering web pages and mobile applications. At the end of the day, it's all about a tree. I mean, you use multiple components and then you compose them into a tree, right? Back in the day, when jQuery used to exist, our main job was trying to manipulate this tree. However, with react and with modern JavaScript frameworks, you don't really have to think about a tree alone. All you think about is what should the page look like? And then the framework does a job of constructing and manipulating the tree. For example, in this tree, if I had to change something back in the jQuery time, I'd use a selector. I'd say, hey, document dot get element by ID, pick a specific node and then move it around or change it. On the other hand, with modern technologies, you say, hey, this is what my page should look like given specific states and specific props. And I think that's the important concept here. So to start off with, let me start with a simple example for react. Now, let's take a simple component here. It's a div with an image and like a span or something. And then react basically picks this up and renders it on the browser. Now, if you want to add more stuff to this, you continue to add, you continue to add it to the DOM structure. The tree is manipulated and by this process called reconciliation, it tries to figure out how to get from state one of the tree to the next state and it does like a diffing algorithm. And in this case, figures out that there's a new red box to be added in the middle. React does that for you and it automatically adds it. And that's sort of the react reconciliation algorithm. Now, the interesting thing to note is, of course, react has this concept of control components which people spoke about. The idea being, if you want to manipulate something, you would have to like, I give it a value and also set the state for it. Now, because hooks are the new cool thing, I wouldn't, I don't want to sound like a dinosaur. So let's actually show, let me show you how this looks in the new hooks world. Effectively, what you do is you say, hey, the value of that input box should be text. And whenever someone changes something, the set text function of the on change function needs to be called. The way this typically works, regardless of whether it's on a mobile website or on the web is this. Basically, the moment you start typing something, an on change event is fired from the browser. This on change event says, set the value of text to a and the value there becomes a and this is sent back to the browser. So it's this flow that happens over and over again. It's pretty much how react works. Clear? This is something that all of you already know, right? I mean, this is not new. Here's where the interesting thing comes in. Now, it's well and good that you write a web page or it's okay. It's, it's also pretty good that you write responsive web pages, but there's a difference between writing a webpage and delivering an app. I mean, everyone today has an Android device or an iOS device. In India, most people browse the web using their mobile devices. So it's important to deliver your experiences. No matter what client you work for or what product you build over a mobile device. And a mobile device may not just be sufficient. The key here is, if you end up just delivering a webpage experience, remember that they are working with other applications like Twitter, Facebook, Pinterest, Instagram, and those have experiences. They have animations. They look and feel good. At that point, you need to ensure that you don't stick out like the odd man out. You need to ensure that the experience that you deliver are similar to what people are already used to when they're using their mobile phones. Like the Ola app, for example, a lot of people use the, use the PWA. But there is a slight difference between the experience of an app versus the experience of the web, right? And I think this is where React comes in and shines. So if you look at the input, uh, input typical text there, there's nothing inherent about it. That's that restricts it to the web. Technically, what you could do is change that to a text input component. And this way you'll actually be able to get this working on a mobile device also. And that is basically how react native derives its strength from react.js. The idea being in react, you talk about divs and spans when you're when you're dealing with the website, but divs and spans are specific to the web. If you were able to abstract that concept concept out a little bit more, you can think in terms of views and texts and that higher level abstraction will let you develop your applications. So basically the technologies that you already know using react, you will be able to take that and use that right mobile applications. And I mean, why limit yourself to just mobile? You can use the exact same technology to also write VR applications application that you can see on your headset. There's no difference. It's conceptually the same 2D surface or a 3D surface. It's all about components and objects. In fact, if you think about the workflow, there's no difference. It's pretty much the same like the on change and all is pretty much the same except on the browser, JavaScript can go manipulate the DOM directly, right? Like you can actually say, Hey, I want to go add a checkbox to this or I want to go change the style while it's possible on the bear on the web. There's a slight problem with mobile. These are two different worlds. There's the Android UI, but all of their business logic is written is written in JavaScript, right? How does this whole process work? This method of direct communication that you saw may not really apply because there's no direct way to call methods, right? Instead, what react native does is instead of calling methods directly, it has this concept of a bridge. The best way to think about the bridge is it's a way to communicate between JavaScript and Android or JavaScript and iOS. And at this point, I'm going to go a little bit into detail about how react native works. The reason why I want to go in the in depth is because when you're starting to write an application, it's always useful if you understand how it works under internally. I mean, it's okay to use a technology, but having that knowledge about how it works and why certain things are written the way they are helps you to become helps you to write better applications. So you know how I told you that you have set value and like direct methods, you can't call those. Instead react native serializes them inside like a json array and sends them over the bridge. Whenever someone talks to you about react native and communication, this is basically what the bridge means. There's another gap in this explanation and that is on the web, you use Flexbox and style and CSS to like do the layout stuff, right? Android doesn't understand that. The browser does but on Android, you have Android's own way of doing things. If anyone has written has done any Java Android programming or any Objective C iOS programming, you'd know that the layout system is slightly different. Here you talk like on Android, for example, you talk about linear layout or constraint layout and things like that. And what we need is a simple system to be able to convert that CSS that we write in react into something that Android understands. And this is where a layout tree or yoga comes in. So center component that you see here is a layout engine and the layout engine is called yoga and the way it works is into yoga. The inputs basically are flexbox and CSS. The output is where on the screen should certain elements be displayed. And this is pretty much the canonical picture of how react native works today. React native in fact works using three different threads. There's the main UI thread. There's a central layout thread where majority of the layout calculations happen and then there is a JavaScript thread where all of the business logic is logic is run. In fact, the fact that by default, you have these three threads makes make your applications very, very responsive. Nothing none of the heavy lifting happens actually on the UI thread, right? Most of the business logic is in JavaScript. Most of the layout is in like a separate thread and this three multi-threaded architecture by default make ensures that your mobile applications are fast from the get go. The best way to think about how the world flows is as soon as you open your mobile react native application, there's a render method that tells JavaScript to display something on the screen. Remember that it is in JavaScript where you have written all of your render methods and all of that logic, right? So all of those are run and eventually those are sent over to the layout, which then are sent over to the Android UI system. Now, here's another interesting thing. Let's go back to the previous example of typing text, the onchange example. We looked at that, right? So let's look at how that works in the react native world. In the react native world, whenever you type something on your Android application, an onchange event is filed in JavaScript, which then tells that, hey, we have to change something in the layout. But the thing to note here is because it is across multiple threads, it's asynchronous, it's non-blocking. While 99% of the cases, that is a very good thing. There are certain cases where this might be an issue. And in this case, for example, what could technically happen is, but before the onchange has had time to respond to the UI thread, you might have typed again. And this would be a conflict because what will happen is you have typed A, B on your phone, but the thread hasn't caught up yet and you will only see A on the phone. That's kind of janky. That's kind of a little bit jittery, right? I mean, when you type, you expect that your typing should be smooth. When you scroll the device, you expect that scrolling should be smooth. This conflict is, though it's very, very, this is very temporary, it only happens for like a split second. It still has that jarring experience. And I think the whole idea of React Native is to be able to deliver seamless, smooth user experiences. So you might be wondering, hey, is this really a problem in React Native? I mean, a lot of people actually don't even see this problem. In fact, what happens is we add like a debounce function and this conflict usually does not happen in most cases. What does happen is this pretty interesting case where being super responsive is the opinion. Now, remember how I told you that the UI thread is responsive? The UI thread, in fact, is so responsive that when you start scrolling really, really, really fast on a list that has a really, really large number of elements, the scroll continues. But because you have not caught, because JavaScript hasn't caught up yet, you might see those flashes of white at the bottom. I mean, that's because the scrolling is just scrolling is going on and on, but JavaScript hasn't done its work. So it doesn't know what to catch up, right? And on native applications, when such a situation happens, the scroll gets janky and that is the expected behavior. I mean, if you want to be like a native application, it's important to not just implement the features, but also implement all of these quirks. And what we are looking at doing with react native is ensuring that your device looks 100% native. Unlike Apache Cordova or unlike the other frameworks out there, we do not reinvent the UI system. We do not go ahead and say, Hey, we are going to provide our old components. The power of react native comes from the fact that you can leverage existing UI elements on the phone, which means that your application looks no different from a minter application or like a flip card application or the Amazon application on your phone. It's the exact same UI elements all across and that consistency from a user experience perspective is very important. So what can happen is here's one way to solve it. And this is what we are working on in the future of react native to ensure that react native continues to be fast 99% of the cases we will do asynchronous rendering. But in the future, we are looking at a world where all of this rendering happens synchronously. And this is the point where I'm talking about what exists and we are going into the world where hey, this is what the future of react native is going to look like. The reason why I specifically want to mention the future is because react native is fast, but we want to be the team at Facebook is ensuring that we work, we continue working to make it better. So you'll have you in the future, you'll have you'll have the ability to render synchronously and asynchronously. And given that you'll have both of these choices, it would be up to you to be able to pick up the ones that you want and render it. In the last talk, you also heard about fiber and time slicing, right? With this approach, we will be able to make full use of fiber and time slicing for a minute. Think of this scenario where you've made a network request. You're already waiting for one second. Once you start rendering a network network request, let's say the user type something at that point, you want to be able to interrupt the user interrupt the network request processing and actually respond to the user typing because remember, you need to be responsive as the user type something is expecting something to show up on the screen. So it's okay to suspend that render processing and then respond to the user input and with a system like this, you will be able to do things like that. In fact, it's if you if you think about it from a holistic perspective, it's that asynchronous bridge that kind of is the cause of these problems. And what we're looking at doing is sort of burning this bridge and ensuring that react native is a lot more like the browser in react native rather than to go through the bridge and all. We want a way in which we have like a jet pack that lets you go from JavaScript to the UI layer directly. Now, what does this mean in more concrete terms? Well, let me give you an example. At the bottom here, I'm going to tell you how the browsers work today. How does the web browser work? So today what happens is when you say document dot create element, the result that you get that is not a JavaScript object. That's actually a C++ object, right? I'm going to say document dot document dot create element. What do you get? You get like a HTML input element, for example, and it has like a bunch of properties and stuff. It also refers to your native systems UI inputs input. That's also the reason why if you look at a web page on a Mac versus if you look at a web page on the gun on Mac Safari versus IE on Windows, there's differences in like the way things are drawn. And that's because you don't you don't draw a checkbox using lines and boxes. You pretty much use what exists in the system already. The other advantage of using UI that the platform provides is consistency. If you imagine a world where you have to go and implement the whole checkbox, you'll have to ensure that it is accessible. You have to ensure that tabbing to the checkbox works. You'll have to implement all the titles. Let's say a new version of Windows or a new version of iOS comes out. You'll have to keep up with the new version. There are so many assets to that. Instead on the browser, you'll be pretty much assume that hey, the browser is doing the right thing. We will just depend on the browser. React Native is very similar. In fact, on react native, we pretty much use the Android checkbox and instead of sending a serialized serialized commands, what we want is an API that looks similar to the browser. So this is how the new version of react native is going to look like. What it's going to do is it's going to be if you think about it, this is very similar to the this is very similar to the browser. The APIs are going to be synchronous. The controls that you have are simple to the browser controls and the whole layout system is also going to be very similar to the similar to the browser. Now that is the core idea behind react native. The idea is that you have a JavaScript interface which lets you call Objective C and Java methods directly. JavaScript can actually hold references to C++ objects. Pretty much like how you do in the browser today. And this is good not just for code sharing, but also for from a conceptual perspective, writing UI for the browser for react native and a bunch of other surfaces start to get more and more similar. This way you will be able to use react philosophy of learn once write anywhere. I mean, a lot of people here already have react websites, right? Taking those react websites and taking the learnings from your website and converting them to react native apps is now going to be much easier. What does this specifically mean in terms of the UI elements? What it means is that all of your view managers, for example, all of your checkboxes, all of your text inputs, they will now be callable directly. All of your layout tree is going to be made of those elements that are written in C++, but JavaScript holds a reference to them. What that means is for a command like this on the browser, the equivalent in react native would be something like UI manager dot create node and that the object, the node object that you get back is similar to what you get back when you use the browser. And here in that object, you will be able to call Android methods directly. Like you'll be able to create an Android checkbox or an Android view directly. The same story for native modules. So let's say you want to take a picture using a mobile phone with the new architecture. You'll have the exact same story and you'll be able to call these methods synchronously. And why is this important? This is important not just from a performance perspective, but even from like conceptually understanding react. So here's a example use case. Let's say you want to take a picture. And then you want to upload this picture to a web server or something what you would typically do in most in most hybrid cases today or in most across platform frameworks today is you take a picture, you would send it to either to JavaScript. And then when you want to upload it, you'd send it back and this is expensive. This is expensive because you're basically serializing and these DC less Jason across language boundaries. Instead in the new world, what we would typically have is the ability to hold a pointer to a picture in JavaScript. And there is no translation, no serialization and you just call the upload API directly. In fact, this is pretty much how like navigated or geolocation like on the browser. You say window dot navigator. What is navigator? It's a it's a native object that the browser provides. And then you say navigated or j get geolocation. That's a method probably written in C++. That's called on the navigator object, right? This is very similar. And don't worry about all the C++ because you wouldn't have to hand write most of that code. Most of the C++ are what is going to be auto generated using build tools. So if you're writing JavaScript, none of this is actually going to go to change the way you write stuff. And as I said for app developers, just like if you remember the way react has been progressing, there haven't been a lot of breaking changes. You've never there hasn't been many cases that you have had to throw away your complete react application rewrite from scratch and react native is looking at following that kind of a structure that kind of a mentality. Most of this code is backward compatible and all of this is already out there in the open source react native repository. In fact, if you were to think of react native as like a block diagram, the typical way to do up is that you have a you have stuff that you draw on your screen called new managers. You have APIs like get camera or geolocation which are called native modules and all of these are built on top of react and of course you have your JavaScript virtual machine on top of it and then react JS and your JavaScript code. Of course, there are multiple view managers and multiple native modules. The strength of react native comes from its community. I would say that react native is probably one of the largest cross-platform hybrid app development communities out there. A lot of so even if some of the core components don't exist inside the main react native repository, they all they are extended and they exist exist in the community. In fact, we as the react native team are looking at moving more components out to the community so that people are able to develop faster and react native is much more thinner and much more leaner by doing this people will be able to upgrade react native faster and pick and choose the components that they want. There's more information about what's happening in the react native world at the URL at the bottom and if you want to get started with react native, if you want to get started with with contributing into react native open source, that's actually a pretty good place to start looking. So at this point, let me take a pause and talk about okay, all this is good from a technical perspective, but I'm a company. Should I use react native? Or you know, I mean, it's your it's your company and I may not be able to talk to your company, but what I can show you is some examples of companies that are already using react natives out in the world. So I work for Facebook and at Facebook, the analytics app, the ads manager app, the Oculus, the headset, while the companion app and in parts of Instagram actually use react native in it. In fact, you'd be surprised, but the main Facebook app that you may have installed on your phones. A lot of screens in that app are written using react native. In fact, the marketplace app that you see at the bottom there, that's the marketplace tab. That's completely written in react native. And this is one of the good things about react native. You don't have to completely move to one framework or the other. Even if you have existing native applications, you can start converting some screens into react native. When I was in Bangalore, for example, I spoke to people from Minthra, go ibbo, make my trip, red bus and a bunch of other top companies in Bangalore and they are actually start they have an app where some screens are in native Java and object to see while a lot of other screens have now been migrated to react native. So this migration can happen slowly both ways. You can start with the react native app and start adding native stuff. All you can start with a native app and start adding react native screens. So that way you have that flexibility. You're not locked in. There's not like, hey, if you've started with one app, this is the only way you can do it. In fact, Microsoft is a big proponent of react native like Microsoft. There are tons of places in within the Microsoft ecosystem where some of the apps are written react native. Skype is a big partner and has submitted more than a hundred PRs into react native into react native. You know the mobile versions of like outlook and word that you have on your phone parts of them are actually written in react native. And I think the key here is you should not you as a user don't have to realize that it's react native because in terms of performance, they are no different from how the rest of the application is structured. Some other apps that use react native extensively include Pinterest Bloomberg and even Zynga. In fact, Zynga is one of my favorites because you know the game words with friends. It's actually a game with very rich animations. Parts of Zynga of that app parts of the words with friend app are written using react native. And then here are all the other companies that are starting us are using react native. Remember these are like big companies top apps in each of these each of their categories. So it's not just hobbies developers who are starting with react native real businesses that depend on like that bet on their app for revenue are actually starting to use react native in their applications. I personally am super excited about where the whole hybrid app development platform is going the challenges of having to push a coach having to share code between your react JS web app versus a mobile device as opposed to having to write one app and then try to ship them on iOS and Android in addition, the whole ability of being able to push updates over the air just like a just like you would do on a website without having to go through the app store for every critical bug fix. These are some of the big benefits that we see with react native and that way react native has been pretty helpful for a lot of people to build applications. That's all I had. I'm going to be hanging around here. So please let me know if you have any questions, but this is pretty much all about react native.