The New Architecture Is Here… What Now?

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.

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.

So if we look at that documentation and we're like, okay, I have a library, I need to migrate it. What we end up having in terms of load of things that we have to do is pretty much this. So we have our library, we need to do a bit of refactoring, we add the codegen to the package, and then through that we run a command and we have the native interfaces and now we just need to extend them. So it should be fairly straightforward. For apps instead, things get slightly more complicated but in both good and bad ways. Like, oh yeah, yeah, the drawing is much more complicated, it has more colors and stuff, but at the same time, has a level of granularity which, you know, allows us to kind of like migrate one part first and the second part second. But actually, this is where the things that Nicola was mentioning earlier with 71, like things are going to change because now, from 71 onward, pretty much like that entire draft reduces to this, which is much smaller, the steps are much more achievable. I hope you can read it, by the way. It's slightly small, but like the purpose is like big graph, smaller graph. So, we're fine. Now, what go wrong? Okay. So, we have documentation. We have seen that more or less things are getting easier. We have the steps, you know. Fine, everything is going to be absolutely perfect. Well, I already told you, I don't trust anything positive in the world, so let's see actually some of the complications. Now, for foreshadowing purposes, I called these challengers. Why? We'll see in a second. But, basically, I've selected three which I think are fairly important. And the first one of them is typing. As I was mentioning earlier, the new architecture pretty much forces you to type your code. If you're using vanilla JavaScript, you apparently like a lot of pain but like please just use TypeScript or Flow. And once you start looking into the requirements from CodeGen and to modules for your type system, you realize that okay, on a surface level, like all the main types, they all work just fine. But then you start looking into the more advanced things and like, oh, hang on a second.

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.

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.

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.

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.

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.

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.

Thank you. Wow. Thank you so much. Lorenzo. Yeah. And again, the work that you put in inside this entire React Native community it's, yeah, it's huge. Thank you. Huge. And yeah. Thank you very much.

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.

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.