Transcript
Sciandra: Where I want to start from is a very inspirational quote from my grandmother. She used to tell me that picking a technology is like a box of chocolates, you never know what you’re going to get. Maybe she never actually said those words. Probably no one ever has ever said those words. I think there’s something true in there, which is that sometimes we have to face some decisions. We need to work on a project, work on a product, work on an app, work on an experience, and we need to take some technical decisions. In certain situations, we take these decisions based on the information we have around us. Then, maybe six months later, this decision blows back, and it explodes in our face. What I want to do is actually talk a bit about how we’ve been successfully using React Native for over six years now at Microsoft. To do that, I’m actually going to do two parts of this. I’m going to talk about some technical reasons, but I also want to talk about some non-technical reasons. Hopefully, I will give you a list of considerations to leverage for your next meeting.
I’m Lorenzo Sciandra. I’m a senior software engineer at Microsoft. I’ve been a React Native maintainer from 2018, so I’m biased, but hopefully all the things that we’ll describe you can also apply to other technologies.
Adaptability
Let’s talk about adaptability. Let’s talk about the technical reasons why React Native makes sense in certain situations. How many of you are using React Native right now, do know about React Native? This is pretty much all that you’re going to need to know about React Native. It’s basically a way to make apps on native platforms that, through a communication layer, use JavaScript to do the heavy lifting, to do basically everything that you need for your app to be useful to your user. To just hammer home this point very quickly, while we’re at the start, when it comes to React Native, React Native, one of the key advantages that it has is that literally everything on screen that gets rendered, even if the code you write is JavaScript, at the end of the day, that’s going to be fully native code.
In this scenario, we have a super simple React Native app, but the nodes there in the VS Code debugger, they show you how it’s a UINavigationController, a UIViewController. It’s all native in the end, which is a key feature of React Native, of course. I was lying, this is actually the graph you’re going to need the most. It’s slightly more complicated, and you’ll see in a bit why I’ve added all these blocks. Basically, we do have native UI and native modules on one end, and we do have the JavaScript React Native UI code, the JavaScript modules, and the business logic. When you think of a React Native app, this is usually what you deal with. In a normal, standard, vanilla React Native project, this is what is called a greenfield app. This means that you’ve built your app from scratch using React Native. In this scenario, very easily, your developer just runs, or uses the JavaScript, and he codes, and then the user interacts with what is, from their perspective, a normal native app.
Out of the box, React Native comes for iOS and Android, so your user base is already doubled in a way with just one code base. If you’ve never used React Native before and you’re only interested in the mobile world, this is pretty much where I explain to you the way it works, the way it was working before, when I showed you the breakdown, is that basically what happens is that the communication layer has a JavaScript side of it, and an Apple, Android side of it that communicate with the iOS and Android UI and native modules. Those are the things that then end up in the app for the user. Already, by now, you can probably tell, if you’ve worked in the mobile space, that this could bring a significant advantage. In fact, React Native is really good at speeding up the time to market, and not just in this base scenario, as we’ll see in a bit.
In fact, this is where things start to get interesting. I was showing you earlier, like how we do have, in this communication layer, both a JavaScript side and the native platform side. Nothing is stopping us from expanding this JavaScript side to have even more native platforms. This is actually what we did. We did make, at Microsoft, React Native for macOS and Windows, because, of course, we are a desktop heavy company in some of our organizations, like mine, Office, or think about Windows. We saw the potential in having a JavaScript based solution to develop apps, and we decided to expand on it and use it ourselves. We’re not the only ones that are betting on React Native for this adaptability. In fact, there are so many platforms that React Native can support. Right now, there are two big pushes, one around visionOS and one around the TV platform that is backed by Amazon and Theodo, which is a consulting company here in UK. This is already introducing a certain level of adaptability. You have React Native and it’s not just for one platform. This is pretty interesting.
Let’s add another dimension to this adaptability. Earlier, when I was showing you this greenfield app, what I was saying is, at the end of the day, your user interacts with a native app on their native OS. When the user uses a normal, let’s say a Swift or a Kotlin app, what they do is just interact with the 100% native app built with 100% native UIs and native modules. Those two squares are very similar to what I was showing before. In fact, we could. It looks similar. What’s stopping us from doing this? This is actually what in the React Native space is called the brownfield app. This means when you have a preexisting native app and you inject React Native, you add the communication bridge, and you start writing some of the features, some of the experiences in React Native. That means that you can add, in your native app, some parts in React Native. We can even take this one step further. This graph is too complicated for now, so let’s just make it a bit simpler.
Now let’s enter a situation much more closer to what we have at Microsoft, where we have multiple apps. Let’s say that we have an app, let’s call it Outlook. Let’s take another one, let’s call it Office. If both these scenarios have already a bridge and we want to write some code in JavaScript to reuse in our native apps, nothing is stopping us from just writing it once, and then we deploy it on the different host apps. This is something that we do a lot at Microsoft, actually. This is a slide from an old talk, I would highly recommend if you’re interested in this specific topic of like, what I usually call the multi-monorepo world at Microsoft. You can go and check that out. Basically, we do have so many massive monorepos that even just moving the code and getting one host app, which is something like Outlook, Office, to consume an experience built in another monorepo, it requires some work, and that’s why we made some custom tooling for ourselves in the React Native space. This is all open source. There’s actually another talk that we’ve done where we go deeper into this tooling. We’ll see it again in a bit, some of it.
We can take it one more step further. As I was showing earlier, the brownfield situation is very similar for the end user to use a normal app, but for us, we’re adding a communication layer. We’re adding some JavaScript code, and that doesn’t come for free. Of course, there is some overhead that we’re introducing. For example, we might introduce an increase in bundle size. In particular, what this could lead to is a slower startup time, or some interactions might feel slower. React Native is actually so adaptable, that one of the things you can do is that you can replace the communication layer with something custom. We actually do have an implementation called react-native-host out in one of our open-source repos. In this scenario, it may look a bit weird. Why would I need it? Let me show you a slightly more complicated example. Let’s say that you have a very big app, and you have so many screens into it, and you’ve built two or three of them with React Native.
Maybe one of them is like five screens deep. One is two screens deep. The other one is like 10 screens. It’s a page that no one ever sees. If you don’t know when the user is going to use it, or each of these experiences, you basically have just one communication layer. You need to build it up at the start and then hopefully at some point it will become useful. If you have a custom communication layer, what you can do is tailor the behavior of this communication layer, for example, to only build up when you’re at the n minus screen right before that specific experience. You can build it up and build it down for each specific need. This is not even my final form. When I was showing you earlier that the business logic was separate, it was on purpose. Because when you write some code that interacts with the server, for example, and this is more relevant when maybe you have a big corporate app, when there are many backends you need to interact with for different services, and then a new feature comes in.
Basically, that business logic is pretty much standard JavaScript, TypeScript code. If we want to take something that we built very quickly for web, so we have the JavaScript code built for the web app, and we want to very quickly introduce it into our native platforms, but we’ve only built the business logic, what if we do this? We have actually found out at Microsoft that there is this special mode of using React Native that you can basically concat and call it headless. Pretty much this allows you to have your UI to be built fully native by maybe your app team that is working on that specific platform. They can directly interact with the code that the backend team has provided in JavaScript for the web app without having to rewrite it from scratch just for your app. At Microsoft, this looks much more like this. We have a brownfield scenario. We have the custom communication layer. Headless is one of the more interesting use cases of React Native, and it enables a faster time to market, especially when you have a range of apps that vary across a whole series of platforms.
A React Native App at Microsoft – Strategical Reasons
Also, I’ve shown you a bunch of different ways of using React Native. I’ve shown you like, this is uploading this way, this way, that way. At this point you may be like, but how does it look really like? How does a React Native app at Microsoft look like? The answer is, of course, it depends. We actually do have many apps that use React Native. This is just a subset. This is like the crown jewels. We have Office, Outlook teams, where we all use React Native in a brownfield way. We have Xbox and Skype, which are in a greenfield way. Not just that, we do have many experiences. For example, this is called the contact card or the live persona card, and it’s one piece of code that works across all these different platforms. This is Outlook. In a way, we both have React Native apps at Microsoft that look like this, standard greenfield apps. Both scenarios, they’re much more complicated, intercommunicating, they share the code, and some are more custom than others. Some use React Native more than others.
The great thing about React Native is really that both of these scenarios are valid React Native cases, and this really opens up a world of possibilities. We all know that technology is not what wins the hearts of our leadership. It’s not, I’ve made it 10 milliseconds faster, 100 milliseconds faster. They want to hear the strategical reasons. They want to hear the money talk. To talk about strategy, I wanted to start from something that happened a while back, around 2022. We had an internal conversation where basically a developer from a different team came into an engineering room and basically was like, why are we using React Native over this other technology? Surprisingly, the conversation stayed very civil. No one threw anything at each other. The more interesting bit for me is that it was a very good treasure trove of good strategical reasons. It was a great way for me to find a good bunch of good strategical reasons. One thing that you need to learn about Microsoft is that we love a three-letter acronym. If we can give it a three-letter acronym, we’re going to make it into a three-letter acronym. Here’s the first GSR.
The first one is actually hire-ability. Maybe some of you that are more familiar with the JavaScript space may have already seen this coming. There’s this really interesting quote from the McKinsey Technology Trends Outlook 2023, where they stated very clearly that a lack of talent is a top issue constraining growth, where talent here is, of course, having actual people that work for you. When it comes to React Native, it’s based on JavaScript, and it’s constant and consistently across any server that you can find in the space, JavaScript is at the top, is the biggest pool of developers. It literally opens up the door to the biggest pool of developers. Because it’s JavaScript, it also means that it’s actually faster to onboard people from different projects.
The second good strategical reason is flexibility. I already mentioned that brownfield is a very interesting way of using React Native. The really great thing about it is that it doesn’t come in one size. You can literally make it as much or as little part of your app as possible, compared to some other solutions for mobile, especially in cross-platform, that literally requires you to throw everything out the door, start from scratch with a new stack. React Native really allows you to test the waters, only introduce it for a bit, see if it works, and really be flexible in how you introduce in your code base and how much it does. The third one is that it’s alive, which, of course, I’m talking about a piece of code, but what I mean with that is that it’s very much alive as an open-source project. One of the other reasons why I didn’t want to go too much into the technical details of the graph and how React Native works, is because I would have gotten to this point and basically said, and now forget everything, because it’s going to change next month.
This is because of a project called the New Architecture, pretty much React Native. The team at Meta, in collaboration with us and other companies, we’ve, over the years, figured out that there are some pretty significant bottlenecks in the existing architecture of React Native. Meta has been doing a lot of work to create a new architecture under the hood for React Native, so that all of them are actually removed. There’s this new process, basically, we’re moving from a single bottleneck to an entire interface that allows for much more permeability between JavaScript and native. I don’t know about you, but React Native is from 2015, so it’s almost nine years old. How many open-source projects can really say that nine years in, they’re still super active. They’ve been actively worked on by the original owner. They’re doing significant work that is supposed to help everyone without being as disruptive as Angular 2.
Also, some other more interesting strategical reasons that maybe make more sense at the size of Microsoft is, for example, the cross-industry synergies. When I showed you earlier the showcase to show some of the apps, I didn’t mention the fact that some other big companies are involved in this space. In certain situations, in certain rooms, when we need to justify why we’re doing certain works, why we’re following certain efforts, the fact that we can leverage the fact that we’re working together with Meta, with Amazon, on certain efforts, or like, we’re doing this because we treat them as customers of some of the things we do, it really helps get buy-in from center and leaderships. This is a very good thing to keep in mind. Some big companies are involved in the space, you can get involved with them, and that may help you make your goals move forward on the win of this interconnectivity.
Then, of course, there’s the number five. This is the big one. This is probably also the trivial one. This is the one that we say about a lot of different projects, and most times we’re just like, “It’s open source. It’s better by default.” I don’t like that. I want to talk a bit about this. I want to talk about why something being open source makes it actually better, for strategical reasons. I’m actually going to talk about four very quick reasons for that. The first one is probably the one that will have leadership most interested. There was an interesting paper that come out in January of this year, from the Harvard Business School that went into trying to estimate the value of open source. One of the key findings that they have is actually that if all our companies stopped using open source, had to rewrite it from scratch internally, it’d cost three-and-a-half times more. First off, using open source is good because it saves you money.
The second reason why open source is important is actually that it helps you retain control over the technology that you’re using. I think we underestimate the value of the fork button over there. As you can see here, I do have my own because I’m a maintainer, but this is also the button that allows us to enable or to create React Native macOS. The fact that you can in some form or shape always go back to the code and own it at the level that you need if something goes wrong or if we want to move it in a different direction, is incredibly powerful. It also eliminates the situation where, if the owner decides to do something different with the tool, you are just at their mercy, or you’re stuck, or you need to move to an entirely different stack. The third reason is actually that React Native in particular has a big community. It’s part of the JavaScript ecosystem, which we’ve already mentioned is the biggest pool of developers.
It’s not surprising to see that we have some massive numbers. For example, I was trying to find out the better numbers to show how big this community is, but I think the fact that it gets downloaded weekly around 2 million times now on npm is a pretty significant number. The React Native directory website is a man-made list of all the libraries out there that are made specifically for React Native. Imagine just simply the fact that because you’re using React Native, you have access to almost 1400 libraries. On top of those, you can put all the libraries that are just vanilla JavaScript. They don’t need to be React Native specific, as long as their JavaScript is probably going to work. Being part of this big community really means a lot of tooling, a lot of resources. It is not something that you should underestimate.
Then, of course, this is more specific to the React Native one, because React Native is based on React, it allows for very interesting cross-company synergies. By that I mean that if my team, my org, we invest in React Native, and our sister team, our sister org, that maybe work on web, they invest on React, the fact that we both have this common denominator allows for broader investments and a bigger center of gravity around that technology in our company. For example, at Microsoft, we do have our Fluent UI library. Basically, Fluent UI is our design system. Fluent UI the GitHub repo is the web implementation, it uses React. The fact that different teams can, in a way, come together and be like, yes, React is a technology we like, we invest in, really helps the talk with leadership, which, on a strategical sense, is very powerful.
Then, there’s technically one more that I wanted to add. It’s cheating, though, so I’m only mentioning it in quotes, which is potentially using web code. One of the things I mentioned earlier is that you need JavaScript React Native UI code, JavaScript modules to do a React Native app that controls the native platform. Especially that JavaScript React Native UI specific, that’s sometimes a bit of a hiccup, something that not many teams want to deal with. Like, I already have my web React code, why doesn’t it just work? This is actually something that we as Microsoft and Meta, we’ve been thinking about it. We’ve been talking about it for a while. The idea is that, basically, we want to make it so React Native is going to use straight-up React code, and also, we can use WebAPI as ways to control native modules. Of course, this is still in the experimental phase. There is the react-strict-dom repository by Meta. There’s the WebAPIs work by us. Basically, we’re actively working on this. We really think that this is going to be the next big thing in the React Native space.
Tradeoffs
Of course, there are tradeoffs. You wouldn’t believe me if I just came here, and finished the talk saying, with the last line, it’s like, “Everything is perfect. Goodbye.” There are tradeoffs. We’re all engineers. We all know that if something is too good to be true, it’s probably fake. Let’s talk about a few big tradeoffs that come with React Native. The first one, it’s alive. It means that it’s still alive and invested on. It keeps moving. Because it keeps moving, it means that we need to keep up. For example, this is one of the biggest pain points, usually, when it comes to React Native, when you talk with people about React Native. When you need to upgrade between different versions of React Native, usually what you become very familiar with are these massive diffs. Like, these are all the things you need to change, to move from a version to the other. This is something we’ve been actively working on with Meta. I’ve been part of the release crew for many years. Also, we made some of the tooling. Earlier I mentioned this tool called React Native Test App, and this helps a lot with the upgrading process.
Another tradeoff is that, yes, I did mention that you can integrate it with existing projects, which is pretty cool, and it’s very powerful. A lot of the adaptability comes from there. That’s also the main ways where Meta is using it in the Facebook main app, in the Marketplace tab, precisely, through this integration with an existing process in brownfield mode. When it comes to existing projects, you’re adding overhead. To dive a bit more into that, there are basically two main ways the overhead is added. One is having this communication layer. You are adding chunkiness to your app. You’re adding some time to the startup process.
Of course, because you’re adding JavaScript, we all know JavaScript bundles can be pretty massive, so that’s another area that you need to take into consideration. You’re like, do I want to add it in? Can I take the tradeoff? To help you with that, we did already mention the custom layers. That’s a way. Of course, that requires maybe some internal tinkering and engineering. There’s also the new architecture. That part of the problem is being addressed. For the JavaScript bundle, we actually do have, in the monorepo I mentioned earlier, one of the tools, which is literally a tree shaker, that helps a lot with that. Things have tradeoffs, but fixes are in the work.
When it comes to integrating with an existing project, there is actually a bigger issue, especially when you need to consider a very big scenario. Or you’re in a big company, you’re trying to convince many people to integrate React Native into your project, because, at the end of the day, what you’re doing is disrupting an equilibrium. If you’re in the React Native space, if you have heard of React Native, probably the biggest example I can give you of this is from the infamous Sunsetting React Native blog post series by Airbnb. If you go and read through them, basically, Airbnb was very invested in React Native. At one point in 2018 they were like, no, didn’t work out. Bye.
The problem is that for a lot of people, it literally became, React Native is dead. That was 2018. I’m still here in 2024, so I’m living proof that that wasn’t true. If you actually go and read the blog post, I think that one of the main takeaways is literally this disruption of the equilibrium. You cannot just go to an iOS engineer, to a Kotlin engineer and just shove JavaScript down their throat, and be like, be happy with it. You really need to be careful in how you approach it, in how much agreement, in how much buy-in from leadership you need to have when it comes to integrating something like React Native to preexisting solutions.
Recap
When it comes to adaptability, thanks to its architecture that can be modified and adapted in a lot of different ways, React Native is very powerful. It allows new platforms, new configuration, and can mix and match. You can add it as much or as little as you want. Because it’s JavaScript based, you can easily share code and tooling across the code base, think something like ESLint, Prettier, like all these toolings that all your JavaScript developers are already familiar, they can still use those, even if they target different platforms or web. I’m talking about JavaScript, of course, when we move to the strategy bit, because it’s JavaScript based, it means the biggest pool when hiring. The flexibility allows for tailored and incremental usage. You don’t need to get the all or nothing approach. You don’t need to get massive sign-in. Maybe you can just start by like, that page that is 10 screens deep, let’s try to just do it there. You can really take your time with introducing it and making sure it works out for you. The project is still very much alive.
You don’t need to worry that it’s going to disappear tomorrow. It’s not going to be on the killed by Google Twitter account. It allows for cross-industry and cross-company synergies, which when you need to get buy-in, when you are in big companies, those type of pros are really important when you want to keep your team and everyone happy. Of course, it’s open source. Let’s go through the tradeoffs. You need to keep up. It adds some actual technical overheads, so you need to work through those. Some of the things are already addressed. It can lead to disrupting equilibriums. That’s probably where most projects will fail, in introducing React Native in using it. Be careful with that. React Native is incredibly adaptable. Good strategical reasons. Has tradeoffs. Again, please take all the things I’ve said and adapt them to your situation, the next time you go into a decision process, the next time you have an architecture table. Adapt this to your situation. Don’t just blindly, it’s used by Meta, it’s used by Microsoft. It’s going to be good for us. Play it careful.
Questions and Answers
Participant 1: You said one of the advantages of React Native is that it’s alive. What’s the relationship to the parent React project? Because that seems to be somewhat on a soul-searching mission, which hasn’t had a release in, I think, nearly two years. What’s the relationship between React Native and the somewhat floundering React project?
Sciandra: I think that one thing to clarify is that, at Meta, in terms of organizational structure, React and React Native are part of the same org. Literally, the entire org is called React Org. React Native, in that sense, is very much part of the project. As you may know, internally at Meta, there’s one massive monorepo code base where everything lives together. Of course, I’m from Microsoft, I can talk about some of the bits of how Meta works, but I cannot dive in too deep. React is technically alive. I’m pretty sure that React 19 is going to be out soon. There’s going to be React Conf. I expect a lot of announcements to happen there. React is a much smaller project in a way. It’s just a web library in a certain way.
React Native, by comparison, it needs to keep up much more with what’s happening around it, with Android and iOS. In that sense, I wouldn’t take the different release rhythm, to be a significant signal. That’s just in the nature of the two projects. They are very much interconnected. The people that work on one are very much close to the people that work on the other. There was a talk from the person from the Oculus experiences team, and that’s also another platform where React, React Native are used heavily in conjunction. In a way, as long as one of the two projects has a spark, you can assume that both have the spark, because it’s basically the same people working on both.
Participant 1: When I looked at the React Native support for desktop a year, two years back, there was a fork repo of the React Native things, and if you wanted to build a mobile app that also works on desktop, you physically had to build two different applications. Because there was the official React for mobile, and then there was Microsoft fork for desktop, which is different with some of your competitors. Is that still the case that you have to physically build two different applications?
Sciandra: No. The repositories are still separate. There’s the React Native Facebook/ React Native code base, which is iOS and Android. There’s the Microsoft React Native macOS and React Native Windows. Those are three separate code bases. I think of maybe what you’re referring to is like the developer experience when you build the app, or the actual code base. I think, at this point in time, the flow is that you generate a React Native app, and then you run an extra command that adds the extra folder. You generate the React Native project, and then you go into the folder and you run React Native Windows in it, or something like that, and that adds the Windows implementation, so all the native bits that you need, the Windows folder. That’s pretty much it, as far as I’m aware. I don’t use Flutter, but basically, my understanding is that you have the code base with just the separate folders all living side by side.
Participant 2: What is the performance implication of using the native code, doing Android and Java, or whatever, Kotlin, versus doing React Native? You did not talk about performance at all.
Sciandra: If I have a fully Kotlin based Android app, how it does performance wise compared to React Native? What we’ve seen at Microsoft in all our scenarios is that the performance is not significantly different. Even if there is some small overhead, in the end, when it comes to the final user experience, the interactivity difference is minimal. Of course, for example, we don’t try to use React Native for very complicated, computationally heavy situations. We don’t try to render a 3D object in visionOS or something. The use cases are much more like the live persona card I was showing earlier. For those scenarios, it’s pretty much the same, in particular when it comes to the user. Some small benchmarks might be different, but at the end user, the milliseconds of responsiveness are in the same hundreds, so 200, 220, something like that.
Participant 3: For example, you were showing that some of the projects you have, 10% of the project is React Native, 90% is native. Is this because 10% of it can be made in React Native and the rest is too computational?
Sciandra: It’s just that it was a preexisting code base. If we already have Outlook built, and we just want to add, when you click on the avatar, a new thing comes out, and it shows you some details. What happens is that we don’t throw away everything that was built before. It’s just there, and we’re just like, let’s add this new part in. Instead of building it natively, let’s take it from that one code base where we’ve already built it for the other platforms, and let’s just put it in.
Sciandra: It depends on the feature, on the team. Again, some of the things I mentioned are like these non-technical reasons. At our size, most of the decisions are not very technical, are much more around which team has the signoffs to do certain things. It almost always boils much more down to those type of like, which leadership has agreed to do what in which team, and based on that, that gets reflected on what code ends up in the code base. There isn’t a master plan to get every single app everywhere to be built in React Native. At Microsoft, we don’t use it for all the apps that we’ve done. We use it in quite a bit at different levels, but it’s very much a situation of like, do we have this code already? If we use React Native, does it mean that we are faster to market with that feature?
For example, Copilot is a big example of that. One of the reasons why we were able to get Copilot so quickly across all our native apps is because we had the web implementation and through some of the things I mentioned earlier, basically that made the process much quicker, because we had the web code and we were like, go, go, go. Let’s just wire it up as quickly as we can, and give it to our users.
Participant 2: Since you are from Microsoft, how do you choose between .NET MAUI, which is a new multi-platform, again, you can build multiple apps with that, versus React Native?
Sciandra: It’s almost always a situation of which code base we’re looking at, which pool of developers we’re looking at. For example, one of the key difference between React Native and .NET MAUI is that .NET MAUI is much more for C++ developers, like that silo of developers and technologies. It very much depends on what code base this work needs to be done on, what expertise does the team have? For example, again, if we’ve built the live persona card in JavaScript for web, perfect. We need something JavaScript if we want to go fast, so React Native makes more sense.
I’m talking as a theoretical example, let’s say Office Word creates in C++ a special feature, and we want to throw it over to Excel, PowerPoint, or even Outlook, then in those scenarios, maybe something like .NET MAUI could make sense, or just straight C++ sharing code. It really depends. It’s very much feature first. We’re trying to get value to our customers as quickly as we can, in the best way possible. One of the things that we believe is that the experience on a native app needs to be compliant to that native platform. That’s why we try to use React Native instead of WebViews. Even that, we have a lot of things that are built into WebViews because of the decision-making process: who is involved, who’s signing off.
Participant 4: We use a lot of WebViews in our mobile app, and we use React web to populate those WebViews. It’s really interesting to see the quite extensive use of React Native. We’ve run some experiments with React Native before, we’ve actually taken out of the code base. I just wondered, was it worth us having another go? Where do you see the tradeoffs between React web in a WebView, versus trying to run some more experiments with React Native?
Sciandra: It depends. What are you trying to optimize for, for example? One of the things I said at the very top is that, by using React Native the native OS knows exactly what’s happening in the app. It knows every single component. If you have something like a WebView, what the native OS knows is that, now I’m throwing a WebView, I have no clue what’s happening in there. That’s an example. That’s one of the situations where, for example, this thing could lead the OS to optimize your app in a different way. Because it has no concept of which screen you’re showing. Are you showing three screens, are you showing one? In a WebView, you don’t really know. It really depends on what you’re trying to optimize for. If you just want, I have my web app, I really don’t want to spend any more engineering time and just want to give my users something to install on their phone, WebView can make sense, of course.
Participant 4: Potentially there’s a strategy to do both depending on the use case.
Sciandra: There’s also the React Native WebView. Probably you’re using a straight WebView. There are different options. Again, WebView makes sense in certain scenarios. It all depends on what you’re trying to optimize for.
Participant 5: Why React Native and why not something like NativeScript, which would maybe not have to tie you as much to React specifically?
Sciandra: First off, because, as I was saying earlier, if we all work in the React space, we can create cross-company synergies. There are some strategical reasons there. The NativeScript case is actually pretty peculiar. Some of the people that work in the project are heavily interacting with our team, because some of the solutions that we developed around, for example, the JavaScript engine that React Native users harness, are now being used by NativeScript to do some really interesting things. I work constantly with Jamie Birch and Nathan Walker and the team, we talk frequently. It’s pretty interesting to see how these two projects that some people may perceive as competitors, we’re actually helping each other out a lot.
For our needs, I think that what happened is that when we started looking into React Native, NativeScript wasn’t as powerful or as polished as it is today. I think now it’s a much more stronger competitor than some other alternatives, especially when you want to go for a JavaScript based solution. I think for our needs, our investments, and the platforms that we target, React Native still makes more sense. It could also be a dynamic inertia. We’ve invested so much that we are not maybe going to pivot everything all at once. The two projects are collaborating very closely.
Participant 6: Are there any scenarios where you want to go the other way round. I see that you have to bite that brownfield application, maybe you want to make 5% native instead of supporting and using React Native.
Sciandra: If I have something done in React Native and I want to rebuild it in native? I have not heard of any scenario where we’ve done that so far, but I can see situations where, for example, let’s say there is a reshuffling of the organization, you have a new leadership and the new leadership has cut the web team because they believe more in the native apps than the web teams or the web app. In those type of situations, I can totally see a native team having to take over a preexisting brownfield scenario. In that case, if your native team is Swift only, it makes sense to transition off React Native in favor of going back full native, which is basically what Airbnb has been doing. As soon as the people that were advocating the most for the brownfield approach left and the expertise left, what was still at the company were the native engineers, so, of course, you want to rebuild so that you use the best as you can, the engineering that you have, basically.
See more presentations with transcripts
