The React Native new architecture has been "coming next year!" since 2019 - but, this time, it’s actually here! So… what now? What do we actually need to do, to benefit from this all new shiny tech? In this talk, I want to provide some insights and in-depth analysis of the current state of the migration path to the new architecture, to help you and your team evaluate and estimate when and how and how long it will take you to get to the next level!
The New Architecture Is Here… What Now?
AI Generated Video Summary
The Talk discusses the new architecture in React Native, highlighting its benefits such as native interoperability, concurrency, faster startup, better memory management, and improved code quality. The migration process to the new architecture involves refactoring, codegen, and extending native interfaces. Challenges include typing, configuration, and migrating third-party libraries. React 18 introduces automatic batching and compatibility with the new architecture. Microsoft is expanding React Native to target desktop platforms and has a dedicated open-source tooling repository. The Talk emphasizes the importance of open-source contribution and setting healthy boundaries.
1. Introduction to the New Architecture
I'm here to talk about the new architecture and what it means to start using it. The main difference is the disappearance of the bridge, enabling native interoperability and concurrency. This leads to faster startup, better memory management, and improved code quality. The new architecture also provides a better developer experience. Let's start with the documentation.
All right. Thank you, Kathleen. I like the metaphor with Gandalf for two reasons. One of them is that in a very famous point of the Lord of the Rings, it kind of like just almost dies and just before doing that, it's like, run, you fools. So, I feel I'm in that phase. I don't know if I'm going to show up next year with like super white hair and white robe, but, you know, we can make things happen. We'll see about that.
Anyway, I'm here to talk about the new architecture, like we've had Gand, we've had Nicola talking about it. So I'm kind of here answering the, you know, the next logical question, which is like, okay, so we have the new architecture, what now? So Kathleen already did a great job introducing me. I just wanted to reiterate I'm a senior software engineer at Microsoft and I've been a React native core maintainer and a releaser since 2018. So, yeah, I've been around for a while.
And because we had Nicola and Gand doing a really great job kind of like going through the concepts of the new architecture, I'm just going to kind of cheat my way through my first few slides by saying, oh yeah, let's just, you know, this is the old architecture. We all know what it looks like. Absolutely we all do know. And then, boom, here's the new architecture. Yeah, we don't need to know literally everything about it. It's fine. Just let's recap very, very quickly like the main differences. So, the main one is the bridge disappearing. And that means no more communicating through JSONs, no more bottleneck. This means native interoperability and concurrency, which is great and enables all this fancy reg data and stuff. Because we have a better structure, it means that also we have a faster start up because now the native components get only loaded when it's actually needed. We have better memory management because now the OS knows more about what's going on within this cross platform app. And then also we have, well, by, you know, having more structure and having ties safely to things like Codegen, we have also, you know, less clashes, better code quality in general. And technically, through the new tooling, we also have a better developer experience. And on paper, this is great. You know, we have Gantt, we have Nikolai pinning it up and, you know, I'm an engineer. So the first thing that comes to mind whenever I hear something saying something positive is, huh, okay, when do I press X on this conversation? So let's try to kind of do that. Let's see actually what does it mean to start using the new architecture. And the first starting point, the easiest place to start is actually the documentation.
2. Migrating to the New Architecture
The documentation for migrating to the new architecture is well done. The process involves refactoring, adding codegen to the package, running a command, and extending the native interfaces. For apps, the migration process is slightly more complicated but offers more granularity. From version 71 onward, the steps become smaller and more achievable. However, there are complications to consider, such as typing and the requirements from CodeGen and modules for the type system.
So if you go on the Rackintive website, in the guide section, there's a beautiful page called Migrating to the New Architecture. And actually, I wanted to take a second and give a huge round of applause to Ricardo, Nikolai, and the rest of the team because, like, the documentation is pretty well done. And, you know, usually, it sits fairly low in like the list of priorities. But, like, spending time on having proper documentation is very, very good.
And also, just keep this in mind from here onward, for this first few slides, the premise is that we are on 67, so the first version, the last version before new architecture and we want to migrate to latest, so the version that Nikolai was using earlier, so 71. Why that? You'll see in a second.
3. Challenges and Evolving Trends
I cannot have union types or custom types. The types must be read-only and have the exact same signatures. Things have been evolving, as Nikola mentioned, with improvements in TypeScript support. Meta and Microsoft are collaborating to make it better for everyone.
I cannot have union types. I cannot really do custom types. The types must be read only and they need to have the exact same signatures and things start to get a bit more messy. Things are evolving in the previous version of this talk like the exact signature that add a red dot because I wanted to showcase that you really need to add it. But since then, things have been evolving, as Nikola mentioned. They're really listening. They're really changing things up overall. So, yeah, things are evolving for the better. And also TypeScript support is feeling better technically. This is something where Meta and Microsoft are trying to collaborate. And we have a huge set of PRs that we're sending back and forth to try and make it so that it's better for everyone because, you know, most people use TypeScript these days.
4. Newark Configuration Challenge
The second challenge is the Newark configuration, where certain things don't quite gel properly. For example, the command to run the code gen differs between platforms, requiring attention. Refactoring the library may be necessary, including moving the require Native component to a separate file.
The second challenge is what I would call the Newark configuration. And what I mean by that, let's go back to the documentation a second, is that if you look closely, when I said refactoring for your library, I said, oh, yeah, it's going to be fine. Actually, there's a bunch of stuff that you need to do. And if your library uses any of this, it basically means that you need to change your library. Especially, like, even if you don't have, like, most of these things, like the require Native component literally requires you to move that part into a separate file. So even if you're like, oh, I'm fine, I shouldn't do anything, yeah, no, actually you still need to do the require Native component one. And also on the topic of Newark configuration, we have a combo here because, like, there are still certain things that don't really quite gel properly. Like, for example, the command to run the code gen is different between the two platforms and it's not even, like, oh, one is a yarn command and the other one is actually, you know, a Gradle site command. So it's kind of like, oh, okay, yeah, these things needs to be addressed.
5. Third Party Libraries Migration
The third challenge is the migration of third-party libraries to the new architecture. Currently, only eight plus one libraries are fully migrated, with seven more in progress. This creates a disparity between the number of libraries documented on React Native Directory and those migrated to the new architecture.
And the third one which is probably the one that also Nicola was teasing earlier is the third party libraries. And what I mean by that is that if we go on React Native Directory which is like this website where, like, a lot of libraries are documented and you can quickly find out the ones that you may need. We have over 1,000 libraries there, right? And now if we go into the React Native New Architecture Working Group that Nicola was mentioning earlier and we look at the dedicated third party libraries section, we'll actually see that only eight plus one libraries are fully migrated to the new architecture which is like a bit smaller than the one thousand we have on the other side. And, okay, to be fair, like, there's actually seven more that are in progress currently in there and this is not by any means like a full one to one like all the libraries are documented in both places, but still like, it's a bit of disparity in terms of like where we should be and where we are right now.
6. React 18 and the New Architecture
React 18 introduced automatic batching, which optimizes performance but can make it harder to understand what's happening. When migrating to React 18, ensure your state management library is also compatible. A blog post on frontend development provides in-depth information on React 18 support and how it interacts with React Native. The new architecture has ripple effects to consider. While there are no benchmarks available, trust that the new architecture is good. Microsoft, a heavy user of React Native, has five apps in their showcase.
And then, oh, what's going on here? Oh, no. The foreshadowing is happening. There's a new challenger. And, yeah, basically what I wanted to talk a second about is React 18 because, yeah, React 18 is great, absolutely. You know, React used to be like this very smooth linear like logically linear thing and you're like, okay, yeah, if I render something up, everything goes, and you render the things down and, you know, it's just one direction and you kind of like know all the steps of the way. And then we got React 18. They introduced automatic batching which is perfect, it's an optimized thing, but also at the same time that means that the library is saying, you know, I know how to optimize stuff, and that implies that you don't really know what's going on sometimes. So, basically, when you move to React 18, which is a requirement for Fabric, you need to also migrate your state management library to a newer version that is React 18 compliant. Like literally unless your library says, yes, I know how to handle React native stuff, like, look into that please. And to help with that, I actually found this very good blog post. I don't know who wrote it, but like is this frontend something something blog post. And like this blog post really goes into depth about this React 18 support, automatic batching and stuff. And also, as we were mentioning earlier, hey, I think I've seen that earlier. Yeah, like how React and React 18 and React Native interact with each other is a bit more complicated. It's not just about, oh, the version that I set on my package.json. So, you know, when you start thinking about the new architecture, you also start need to think about all these ripple effects. And, you know, in the sake of time, like let's just say there's a bunch of more stuff. But please trust me, the new architecture, it's good. It's good. It's good. Absolutely. And also, since this also came up as a question earlier, yeah, so no benchmarks. The reason for that is that there are a few ones that are popping up. But honestly, I don't feel confident enough in any of those React team, I'm looking at you, because, yeah, there are kind of like edge cases and things like I don't really feel like I can properly show benchmarks like, oh, this is how bad it is. So going into the last part, okay, so we have seen that there's implementation for that. We've kind of looked through it very quickly and now we have an idea of what the challenges are going to be. How do we plan for all of this? So as I mentioned, I'm from Microsoft. And Microsoft, we use React Native a lot. This is from the showcase. And there are five apps.
7. Migrating Libraries and Native Code
To enable your app to migrate to the new architecture, start by migrating your libraries or extracting custom native code into a library. Check the React Native Directory website for libraries that support the new architecture. Consider using React Native Library, RNT Turbo Module Sorter, and React Native Test App for a smoother migration process.
You may have seen some of these. I don't know if you, you know, are a gamer or like you work in general. Like those kind of things tend to show up. I'm sorry if you need to use Teams, but no, it's fine. No, I'm joking. I'm joking. But like this is a subset. To be, like, to be completely serious, this is a subset. Like we could have done like three more rows, but then it would have felt like React Native and then Microsoft and then all the way down there, everything else. So we're like, all right, let's just pick five. But basically what this means is that internally I need to come up with some ideas that I can share with everyone else. We're like, okay, this is how we're going to do it because these projects are massive and we need to make sure that things work. So what I come up with is this kind of thing because I like graphs. You may have realized that by now. And I know it's small so let me try to make it slightly bigger, probably still unreadable. But the basic gist of it is that you want to be on the latest React Native version available at any point in time because again as Nicola was saying, we're still trying to make things better every single time and every occasion that we have. But then, because the libraries are what you need to migrate in order to enable your app to migrate to the new architecture, that's the first step. Like if you have a library, migrate the library. If you don't have a library but you have custom native code, extract it into a library and then migrate that separately. Start from the libraries. That's pretty much it. In the React Native Directory website that I was mentioning earlier by the way, there's now a flag in the filters to show like libraries that support the new architecture. So that should help you evaluate, okay, I'm using these libraries, let's see on the website if they show up in this list. If not, let's migrate or like interact and let's understand what we can do to help migrate those. And especially, if you're looking into extracting your native modules, please also take a look at React Native Library or RNT Turbo Module Sorter, those two libraries help you really kick off your, you know, the new version Turbo Module Supported Library. And also, you can use React Native Test App, which is a library from us at Microsoft as a test app because it makes things so much smoother. It's already supporting your architecture, you just switch a flag and it works. And, yeah, that's more or less the plan that I'm kind of like throwing around internally. I hope it will help you too. But of course, there's one big question which is like why start now? Like clearly, things are still evolving.
8. Feedback Loop and New Architecture
The feedback loop through the dedicated repo is something unique. Take this chance to report issues and improve React Native. There's a separate discussion on how to improve React Native. The new architecture is awesome and will be a big deal. Prepare for it and enable OS libraries to migrate. Try fast, fail fast, and tell everyone.
But to be honest, as someone that's been around React Native a lot, even like trying to be a maintainer so communicating a lot back and forth, I can tell you that right now, the feedback loop that exists through this dedicated repo is really something else. Like, the fact that you can report something and like, hey, by the way, I don't think this works really well, smooth out. Like, it's not something that happens every day. Like, meta has not been like this forever. And maybe they will not be in the future. So take this chance while you can.
And talking about taking your chances while you can, right now, there's also a separate discussion about more general like how can we improve React Native. But this is literally only on Tuesday. So take your chances. Go there. Be a React Native team. This is what I would like for you to do better. Like, it's good. They're very listening mode. They're very proactive in helping out. So take this chance.
So, closing in the off, we have 30 seconds. So, yes. Yeah. The new architecture is pretty, pretty awesome. Again, I kind of cheated here and just kind of like throw a couple of drafts at you, but please trust me. Like, from an architecture perspective, it's so much better. The second thing, which is what I hope you can go back to your managers and peers to say, is like, hey, by the way, the new architecture is going to be a big deal. We need to prepare for it. And then, of course, enabling OS libraries to migrate to the new architecture is key. Like, you need to have your libraries working within your architecture to be able to migrate yourself. So if I had to sum it up, if you need to write a tweet about it, it's just this. Try fast, fail fast, and tell everyone. Because, like, if we don't help each other, this is going to be much messier. And thank you, everyone.
9. React Native at Microsoft
We love React Native and we're expanding it to target desktop platforms with React Native Windows and React Native macOS. We have dedicated teams and an open-source tooling repository called RNX kit, which includes a dependency aligner and other critical tools. We've also added tree-shaking to Metro through one of the plugins and developed React Native desktop, which has a lot of potential in the future.
We do have some time, right, for questions? Yeah. So if you haven't already, just go ahead to Slido to one to four. Don't forget about the old track. Ask the question there and we are going to go through them. Otherwise, if there are no questions available yet, let me check it out.
Meanwhile, I have a question prepared for you. I like questions. You're talking about Microsoft and React Native ecosystem inside Microsoft. If you can give us more things maybe that you haven't touched or what's actually happening inside Microsoft in terms of React Native? Oh yeah. I mean, as I was saying, we love React Native and we're doing a lot of things. Maybe some of the most famous are, you know, we're expanding it in terms of platforms, you know, React Native core as iOS and Android. At Microsoft, we actually believe so much in that idea that we've created React Native Windows and React Native macOS to target to the desktop platforms. So we have dedicated teams for those. And also, I kind of tease that like we have an entire set of tooling that we are open sourcing for React Native developers because that's what we have people using internally. So we have the RNX kit repository, which is pretty much where we try to put all our tooling. So for example, you would find like a dependency aligner in there and other critical tools. We add the tree-shaking to Metro through one of the plugins there. And also we have the React Native desktop, which is like this sandbox up, which is pretty, pretty good. Like we are investing a lot into it because we think it has a lot of potential in the future. That's great.
10. Open Source Contribution and Dealing with Stress
RNX kit is amazing. Find a small project to contribute to and establish direct communication with the maintainer. Every contribution counts. Establish healthy boundaries in open source and don't rush. Stress in open source is common, set boundaries and don't feel the need to respond immediately. The new architecture opens opportunities for optimizations that are not achievable with native code.
Yeah. RNX kit, it's amazing. I really would like to invite everyone to check it out, especially if you'd like to upgrade your React Native application, you should do so.
I do have one more question. What's your advice for open source newcomers? Or, yeah, because you are the best person to ask, if you can give us, like, I'm a newcomer to the open source community, what I should do first and what do you think it's, what's your advice here? Yeah, I mean, I think open source can really feel like a massive thing, and React Native repo, the repository in particular, is so massive that people can get scared off quite easily. My suggestion is, like, find a small project that you use, like, let's say a library, a React Native library, that you use, but it's, like, let's say has less than 100 stars, like, something small, and try to establish a direct communication with the maintainer. Like, be like, hey, I would like to learn open source, I would like to help out with this library, and, you know, usually what happens, especially with these smaller libraries, is that the person is really able to, you know, walk you through and give you some understanding of, like, what's needed and how you do, you know, contributions, and also, like, the other half of this is every contribution is a good contribution. Like, it's not like, oh, I submitted, I fixed the typo, and that doesn't count, no, literally everything, that's how I started. There was that website that showed your first ever PR, and it was like, I fixed the typo in a ruby website or something, it's about getting started and learning how the tooling works, and then all of the things will happen over time, just don't rush it.
Okay, that's great, and as a follow-up question to this, I mean, let's assume that you know how to get started with open source, you have contributed a little or quite a lot, how to deal with the stress in open source, and yeah, maybe the imposter syndrome, but the stress in general. Oh, yeah. Doing open source can be really stressful, like, I'm kind of like, in the one percent of people that, like, whenever I click release, I don't want to think about the download numbers because if not, I'm never going to release anything. But like, it's hard. You need to establish healthy boundaries, and like, don't get sucked into the actual culture of like, oh, I need to do it every day, I need to be immediately responding to every issue, like, it's fine, it can wait. Like, unless you're working on, for some reason, an open source project that like, keeps an hospital alive, it's fine. If it takes one week too long, it's okay. Like, it, you know, it's a lot about creating boundaries, I think. Speaking about hospitals, just a side parenthesis here. We do have a talk on Monday about public toilets in the UK, so definitely you should check it out, which is open source, by the way. It's, yeah.
So, thank you so much, Lorenzo, we unfortunately ran out of time. If you'd like to ask any question, just find him out. Actually we have one, okay. What are the opportunities coming from the new architecture that you're the most excited about? Oh, okay, yeah. I'll try to be brief, because we are out of time. But I think the new architecture especially opens the door for optimizations that normally with native code are not achievable. So I can foresee a future where some React native based apps and components are actually faster than their native counterparts. That's technically possible so I'm just looking forward to see that happen in the future. That's great, yeah. Thank you so much and once again, just give a round of applause to Lorenzo.