The RN New Architecture Is Here… What Now?

Alright, 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, he kind of like just almost dies and just before doing that is 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 Gant, we've had Nicola talking about it. So I'm kind of here answering 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 Gant 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! This is 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 not even interoperability and concurrency, which is great and enables all these fancy react 18 stuff. Because we have a better structure, it means that also we have a faster startup because now the native components can only load 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 tie safety 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, PNIDAP. And you know, I'm an engineer. So the first thing that comes to mind whenever I hear something saying something positive is, huh, well, 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 react Native website, in the guys 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's 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, the last version before new architecture and we're going to migrate to latest. So the version that Nikolai was teasing 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 flow 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 code gen 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, 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 Nikolai was mentioning earlier with 71, like, things are going to change because now from 71 onward, pretty much like that entire graph 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's going wrong? Okay, so we have the computation, 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 other complications. Now for foreshadowing purposes, I call this 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 TurboModules for your typed system, you realize that, okay, you know, 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 a 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 had a red dot because I wanted to showcase that you really need to add it. But since then, things have been evolving. As Nicola 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 still in beta 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 challenger is what I would call the newer configuration. And what I mean by that, let's go back to the documentation a second, is that if you look closely at when I said refactoring for your library and 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 requireNative 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 requireNative component one. And also on the topic of newer 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 using earlier is the third-party libraries. And what I mean by that is that if we go on Rack 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 Rack 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 have fully migrated to the new architecture, which is like a bit smaller than the 1,000 we have on the other side. And okay, to be fair, like there is 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 a 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 Rack 18 because yeah, Rack 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 Rack 18 and they introduced automatic batching which is perfectly an optimized thing but also at the same time that means that the library is saying, no, I know how to optimize stuff. That implies that you don't really know what's going on sometime. So basically, when you move to Rack 18, which is a requirement for Fabric, you need to also migrate your state management library to a newer version that is Rack 18 compliant. Like literally, unless your library says, yes, I know how to handle Rack 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 Rack 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 Rack 18 and Rack 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 is 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, they're kind of like edge cases and things like, oh, I don't really feel like I can properly show benchmarks and like, oh, this is how better it is. So going into the last part, OK, so we have seen that there is a limitation for that. We've kind of looked through it very quickly. And like, OK, 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. I'm a Microsoft user. I connect with a lot. Like this is from the showcase. And there are five apps. You may have seen some of these. I don't know if you 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 it's fine. No, I'm joking. I'm joking. But like this is a subset. 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, OK, 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, OK, 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. Like start from your 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 libraries that support the new architecture. So that should help you evaluate, OK, I'm using these libraries. Let's see on the website if they show up in this list. If not, let's migrate or interact and let's understand what we can do to help migrate those. And especially if you're looking into extracting your own native modules, please also take a look at react Native Library or RNTurboModuleStarter. Those two libraries help you really kick off. You know, the new version TurboModule 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 supported in your architecture. 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 like, hey, by the way, I don't think this works really well. This should be smoothed out. Like it's not something that happens every day. Like meta is not being 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. Write what 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 it 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 graphs at you. But please trust me. Like from an architectural 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. Wow. Thank you so much, Lorenzo. Yeah. And again, the work that you put it inside this entire react Native community, it's huge. Thank you. Yeah. Thank you very much. We do have some time, right, for questions. So if you haven't already, just go ahead to Slido, to one to four. Don't forget about the URL 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 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 have the tree shaking to Metro through one of the plugins there. And also we have the react Native desktop, which is like the sandbox app, 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. I think the react Native 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, 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 as 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 usually what happens, especially with the smaller libraries, is that the person is really able to walk you through and give you some understanding of like what's needed and how you do contributions. And also like the other half of this is every contribution is a good contribution. It's not like, oh, I submitted, I fixed the typo and that doesn't count. No. Like 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 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. Yeah. Doing open source can be really stressful. Like I'm kind of like in that 1% 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's a lot about creating boundaries, I think. Speaking about hospitals, just for 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. So thank you so much, Lorenzo. We unfortunately ran out of time. If you'd like to ask any question, just find him out. Yeah, we have a Q&A. 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. 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. Thank you. Thank you.