Jed Bartausky:

Welcome back to another episode of the React Native Radio podcast, episode 3 31, new architecture, new era with Ricardo Cipolleschi.

Jamon Holmgren:

Hey everybody. Welcome back for another episode of React Native Radio. I'm Jamon, she's Robin, he's Mazen, and we have a guest, actually a returning guest this time. Ricardo. Ricardo, can you say your last name again? I think I practiced it last week and then I forgot to practice it this morning.

Riccardo Cipolleschi:

Worry too much. My last name is Leski, but it's pretty hard. Even in Italy, they sometime mispronounce it, so,

Jamon Holmgren:

Okay. Alright. I don't feel so bad. Leski. Something like that. Yeah, in that range. It's good. It's close enough. Ricardo, he actually, so Ricardo was on React Native Radio two 70 with set a couple of years ago talking about React native 0.72. So a little, a few. What are we at?

Robin Heinze:

Well, as of today, seven versions ago.

Jamon Holmgren:

Okay, there you

Robin Heinze:

Go. The 79 came out today. As we're recording then

Jamon Holmgren:

As we're recording, yeah, this won't come out for a little while, but Awesome. Well, we have a really cool topic to talk about we haven't talked in depth about in quite a few episodes, so very excited to get into that. But before we get into that, let's hear from our sponsor. Infinite Red is a Premier React native consultancy located fully remote in the us. We're a team of 30 senior plus level. We're all seniors. Someday we'll graduate, but we're seniors for now. React native developers and some support staff and we've been doing this for almost a decade. It's actually coming up so close in October. Yeah, so if you're looking for React native expertise, hit us up Infinite Red slash Radio. And don't forget to mention that you heard about us through the React Native Radio podcast. Alright, let's talk about our topic. We are going to be talking about the new architecture and for those of you who there might be some people listening to this who aren't familiar with the new architecture, they've maybe heard the term, they don't understand exactly what it is.

We're not going to go too in depth about that, but we will kind of give a little bit of a high level here. We want to talk to Ricardo, who's been one of the key people at Meta on the new architecture and just react native in general, but certainly throughout this new architecture transition that is happening, community adoption and support, those types of things. So from my perspective, I feel like we're in this transition period in 2025 between two eras. We had the initial 10 years of React native, which was focused on building on that foundation that meta created in the very beginning 2015 with the bridge architecture with original, I think it's kind of referred to colloquially as paper, the original architecture for the view layer and all of that and the original native modules and stuff. Of course that served us pretty well throughout history throughout the decade.

But as time went on, it became pretty obvious that, hey, if we want to move forward, if we want to move forward with what the React Web team is doing, as well as some other things that we know are issues with how React native apps perform on startup, on synchronous operations, on different things like that, we need to rewrite a bunch of stuff. It's a little bit disappointing that we have to rewrite a bunch of stuff, but we do. And so that's what Meta did. And actually Meta has been on the new architecture for years now

And evolving it. Community support has lagged a little bit, not the community support, but rather the community adoption has lagged a little bit behind. But with that said, last year I really felt like it started to come together like 2024, it felt like the new architecture started to come together. We started seeing all these things, which was of course, new architecture is Fabric, which is the new view rendering layer and how it kind of handles rendering views and laying out views and doing it in a way that works much better going forward with the new React concurrency features and whatnot. And then also Turbo Modules, which is more like lazy loading modules as you come in, instead of loading everything upfront that you may or may not need, as well as some other cool features bridges mode. So you're not having to send commands over the bridge, you can actually talk directly between your JavaScript engine and native and Code Gen and some other cool features.

So all these features, they're just known as the new architecture. That's kind of how it is portrayed. And so 2025, at least for Infinite Red and I think across the community has started to become okay, we've done the core features of the new architecture are starting to mature. We're starting to have much more broad-based support among all the third party libraries. Now it's time to start adding it to our apps. Now it's time to actually start building apps with it, start switching apps over and really actually excited that Mos was able to be on this episode because he's been leading a lot of that on our side and making sure he's tracking how our teams are doing with this stuff. So we'll get into all of that, but I do want to really quickly talk to you, Ricardo a little bit. How long have you been at Meta and what's your key focus area there?

Riccardo Cipolleschi:

Hi everyone. I'm happy to be here with you talking about architecture and reactive in general. I joined Meta three years and three months ago now, and since I joined, I've always been on the new architecture project, the new architecture rollout in open source. My background is on iOS engineering, so I started working on rollouts from the iOS perspective and slowly ramped up on all the other topics of how Androids behave and how all the new architecture concept, like turbo modules fabric, as you already called them out German. Yeah. My focus aside from iOS in general has been exactly how can I help the community and the open source community especially to adopt the new architecture and how can I enable our users to move doing architecture successfully.

Jamon Holmgren:

Yeah, definitely. And we've of course taken full advantage of that, asking you lots of questions throughout the years, and we appreciate your patience with us and you just, you're a delight to work with. I definitely, I'm not just saying that. I know that our whole team feels that way. So yeah, I really appreciate having you on. Robin. I know you had something you wanted to check or ask Ricardo here about the new architecture's progress.

Robin Heinze:

Well, we've been talking about it for, it feels like, I mean, it has been years that we've been talking about the new architecture, and for a long time it was in this phase of being in progress. It felt like it was in progress, it wasn't finished, but the tone has changed a little bit and it kind of feels more done. Would you agree that the new architecture from a technical perspective is considered done? I mean, obviously software's never done. There's always going to be improvements or bug fixes or whatever, but is it finished and at what point will it stop being the new architecture and just be the architecture?

Riccardo Cipolleschi:

That's a complex question. And so a bit of history I think is important here. Since the development of the new architecture started at the end of 2018, I was not in the company, so a lot of the whys that was necessary and the old initial design, I wasn't there to participate and to learn about that. But yeah, there were some limitation at the beginning in how Tive was working that we needed to figure out and sold. And we are seventh years, seven years after the beginning of the development, 2018, 2025. And I can't say that is done, meaning that as you mentioned in the nature of software, everything is always changing, everything is always evolving and we learn every day something new. So there will be improvements for sure that we want to bring in the new architecture, but we think that he's ready to be using production. As Jim was saying, we have been using the architecture in production successfully in the Facebook app for a few years now. I think that we consider that done in 2022. So now that's

Robin Heinze:

As done as software is ever going to get, as if you have

Riccardo Cipolleschi:

Confidence

Robin Heinze:

To use it in production. That's kind of the measure.

Riccardo Cipolleschi:

Exactly. Yeah. So of course every day we discover some things that we can improve, maybe some edge cases that we were not considering at the beginning, especially because we tested the new architecture internally in the Facebook app, which is a huge surface of

React native creative code, but is not comprehensive of every use case that we have in the open source. So when we decided to promote them to stable last year, the reasoning was that we have been spending roughly three years, three years fixing all the gap that we could find, trying to make it back more compatible with the old architecture as much as possible. And we reached a point where we weren't receiving a lot of bugs from the community anymore. So it was like, okay, it seems like it's stable enough, let's promote it to stable and let's see how thing goes and let's have the community work with that and tell us what's not working for them so that we can together make the React native better for everyone. So that was more or less the reasoning that let us promote it to stable.

Robin Heinze:

Yeah.

Mazen Chami:

I'm hearing a lot of 1.0 talk right now.

Robin Heinze:

Sorry, I just have to say, I just have to get that out early in the episode. If there was ever a time, Ricardo, this is the time you

Mazen Chami:

Said it's done, let's use it in production. And these are all buzzwords that large companies want to hear when it's 1.0 talk,

Robin Heinze:

I think I heard someone at some point say, it's just never going to happen that there's no plans to ever go to one point. Oh.

Mazen Chami:

I'm kidding. I always joke that we don't have to go into that one. That one is a long and complicated story. I get it. Yeah, that's good to hear. Now I think one part I want to shift into, and I had a lot of experience with it. Jim had mentioned, I think it was mid or early last year, I started what I'm going to call new architecture task force internally where I'm going to reach out to every single project of ours, see if they're on the new architecture, why are they not, how can we help unblock them? And a lot of it pointed at third party libraries, and that's kind of where things seem to always hit a roadblock. So we put together a long list of packages, reached out to those packages maintainers and tried to figure out what's next, what's happening, what's your timeline? And I don't know if you noticed this, but a lot of them that are not compatible are large companies that require you to sign contracts with them. And that's kind of concerning to me personally. Imagine you're a company and you reach out to, I promised, I wouldn't say names, but I'm going to say names. You reach out to Stripe, you reach out to Auth Zero, you reach out to

Robin Heinze:

Okta,

Mazen Chami:

Okta and you're like, Hey, I'm on the new architecture, are you? And they're like, oh yeah, it should just work. And you're like, no, it doesn't just work. There's work involved in getting it there. I'm not going to sign my million dollar contract plus to get it done. Now, individual contributors have had this on for two, three years. I can think of some packages, even Mark Avi who had his packages on new architecture before Nut Architecture was even released, and he's an individual contributor, and I can speak from experience, I had to actually reach out to Auth Zero, get some people on email, have some meetings with him, be like, look, you're non in architecture. There's been an issue. Brent Vanney opened up an issue over two years ago about the new architecture and he was kind of ignored until now. And I do have a large client that wants auth zero, but I'm trying to push them in a different direction because you're not on it.

Robin Heinze:

I mean, or clients that are their entire enterprises wrapped up in Auth zero or Okta or whatever, and they don't have a choice.

Mazen Chami:

So I think what do you think is the biggest obstacle for these maintainers that it's taking so long for some of them and what can be done to help remediate this? Because talking about we're in the new era where we want new architecture to be the architecture. How do we get all the third party packages there?

Riccardo Cipolleschi:

The problem with the third party packages is the problem that we have to face. Also, last year we wanted to, one of the requirements that we have before promoting new architecture to stable was that the most popular libraries should be compatible with the new architecture.

And so with the help of Expo last year, which one we collaborate closely with, we listed all the popular libraries using some data that we got from usage on expo services that we know is as a proxy. We don't have data of how libraries are used from all the population using tive, but we could use export data as a proxy and therefore that's how we managed to get that list. But we make sure that all these libraries were compatible with the new architecture, meaning that they were either fully migrated to the new architecture or they were working through intro players. So there is these two ways of using the new architecture, and of course the ideal world will be where every library is migrated to the new architecture, right? Because they will not suffer from limitation from the old architecture. But we know that with open source and migration time are longer than what we can handle internally of course, or how you can migrate internal app in Infinite Tribe.

I'm sure that it's much faster for you to migrate an internal tool than something that depends on open source stuff. So that's a problem of long tail basically. And something we need to keep in mind, we try to keep always in consideration that there will be people not migrating. There are libraries that are mundane, there is no silver bullet or a clear answer here of course, but we try to be as compatible as possible within Interplay. We are thinking about keeping the interplay around for a bit longer than what we had initially planned. And there's also a fun story about interplay if we have time later. But yeah, that's the way to go. And if those companies, most of those companies code is native modules and that's why they said that it should mostly work because that's actually our experience. Many native modules, were just working with the interplay. Even complex modules like Firebase for example, which will might work closely to make them work. They really require minor adjustment to work. So I would be curious to understand why those libraries are not working fine, because maybe we can improve the interplay so that they do, and that will get doors maintainer more time to properly migrate here. There is a bit of a problem if we continuously get more time for them to migrate, they will never migrate. So at some point, we'll,

Robin Heinze:

You have to force their handle,

Riccardo Cipolleschi:

Pull the plug and say, now it's time. If you don't migrate, it's not going to work. But yeah,

Mazen Chami:

I think it's tougher on you all because you're maintaining the interop layer in the new architecture. I think for our listeners that aren't aware, can you explain what the interop layer is and just elevate,

Robin Heinze:

I want to hear the story too.

Mazen Chami:

Yeah, and the story, what's the elevator pitch on it? I know from digging into Auth Zero specifically, I know what they did was they made their package interop layer compatible, closed the issue and said, we're done. We're done for now. We're going to look at new architecture in the future because we know we have time from meta for that. So yeah, can you explain what the interop layer is? And it seems like it's a middle ground essentially.

Riccardo Cipolleschi:

So when we developed a new architecture, we changed the APIs of how you can write your modules and your component. So we move from our work where we have the legacy architecture with the legacy APIs, and we need to bridge that work with the new architecture and the new APIs that we were developing. Initially when I joined the company three years ago, there were no interplay whatsoever. So you could use native modules and throughs together, but they need both infrastructure running at the same time. And you couldn't, if you were running fabric, your old native components were rendered as pinky rectangles with a string saying, oh, your component is not compatible within architecture, so please migrate. And the story is that I was very against interplay at the beginning because it was like if we add interplay, nobody going to be great.

To me, the solution was we have to make the migration as easy as possible. We have to reduce a lot of steps that are required. And that's what actually what we did in the first six months I was there. In fact, if you go through the history of how to enable the new architecture guide on the website, you'll see that from eight c plus plus file, we moved to zero c plus plus file from modifying hundreds of lines of the app delegate. We went to modify one line of the app delegate, so that's how we were working at the beginning. But at some point it was clear that if we were to wait for everyone to migrate, we will never be able to enable the architecture. So did agree and commit in implementing the interplay I worked with on that them and specifically I spent quite some time with on the fabric interplay together with someone from my team, and at the end that was the right call because last year we were able to actually ship the new architecture thanks to the inter player and we will not be on the new architecture without them now.

So that's the story behind that.

Mazen Chami:

Yeah, that's cool.

Riccardo Cipolleschi:

Yeah, so basically they are small bridges that connect that allow you to use your native components in public and your native modules are going through the turbo module infrastructure. And so you can effectively use the architecture and forward all the method invocation to the legacy circuit architecture and the legacy implementation.

Mazen Chami:

Yeah, cool. Yeah, and I think for our listeners, we've mentioned this a lot, that React native directory is the best tool to see if your packages are compatible. And I believe Expo also has a command to you can run that will tell you if you are new architecture ready or not.

Jamon Holmgren:

What's the error that you see the most often if you try to use a package that's not new? I actually haven't tried this where you just add a package that's not compatible. What pops up?

Mazen Chami:

From my experience, it's been as you're building iOS and Android, it crashes then while you're doing the

Robin Heinze:

Build, right? You can't find stuff,

Mazen Chami:

So you're an iOS or Oh, it's just not finding c plus plus. You'll see stuff like can't find c plus plus files or bridging within there. Yeah,

Riccardo Cipolleschi:

Right, right. Okay. Yeah, that's helpful to know. The expo CLI can tell you that you are using a package that is not compatible. Yeah,

Jamon Holmgren:

If you're using

Mazen Chami:

Expo. If you're using Expo, the CLI does is very developer friendly with that.

Jamon Holmgren:

Yeah. Yeah.

Mazen Chami:

So okay, we talked about N architecture being done, third party packages being integrated or not. Now from a company's perspective, we've seen a lot of companies come in say, we haven't heard of it. What is it? We don't want to go Innu architecture.

Robin Heinze:

It sounds scary it to them. It's

Mazen Chami:

Very scary. And you just mentioned interop layer, like hey, you can get there incrementally essentially, but not fully, right? But you can get there safely and get the gains from it. What advice would you give, let's start with the company. What advice would you give the companies on why they should adopt the new architecture? First?

Riccardo Cipolleschi:

New York architecture is the Future Object native, right? It's what Meta is using and is what we suggest people to use. And we working these days to create a roadmap to deprecating the old architecture, stop developing the old architecture. I mean, we are not developing dollar architecture even now. We are still basically accepting a pull request that might fix something. But the real problem is that we don't have internally a way to test it. We don't use it anymore internally,

Not in the Facebook app, but not even in all the other apps that we have that use made. So whenever a user submit a fix for the architecture, we either import and land it trusting the person that submit the fix or we don't have way to test it. So if we decide to land it and then we release a new version of with the fix, we might break everyone. We don't know. We don't really have a way to know that. And so on one side, to me it looks safer for those companies to adopt the new architecture.

Robin Heinze:

You have to frame it. These are all the bad things that will happen if you don't,

Riccardo Cipolleschi:

Yeah, on the architecture, sure there might be issues, but you might have other issues in the other architecture. So it's software, so it's not perfect, but at least we are using a version that is tested by Meta and by our partners instead of working on something that is legacy and not tested. The other reason is that as I was saying, we are not using the old architecture, so you are missing out all the new things that you are developing, all the improvement that we are fingering out and releasing on the new architecture. At Connect, we shared that React native is used on some apps in the Quest devices. Quest devices are Android devices and they have much more, much constrained in terms of memory and CPU power. So to make magnetic good on those devices, we need to figure out how to optimize React Native four Android in general, and those optimization are only on the new architecture.

So if you're not on the new architecture, your Android app will generally be less performance than the UN Android app on the new architecture. And also given that the new architecture is all written in c plus plus, so with the purpose of sharing the code between IO and Android, the optimization that we developed for the Android side of things, if they are on c plus plus, they will be beneficial also for the iOS side of things. And just by migrating to the architecture, you're reaping benefit of all these work that you're doing internally on all your platform at once. So I don't think there is a good reason to remain on the legacy architecture unless there are some modules and components that needs to be migrated. And so you need some more time to migrate.

Mazen Chami:

On that point, what would you recommend as the best migration strategy from your development team's perspective, knowing that some third party packages might not be ready, what would you recommend the path the developer take? We've spoken to the company now, we've talked to the development team.

Riccardo Cipolleschi:

So the first thing to do is for sure to enable the new architecture,

Robin Heinze:

Turn it on one line change.

Riccardo Cipolleschi:

One line change. You should be able to build

Robin Heinze:

So you have brakes follow the errors.

Riccardo Cipolleschi:

Yes. I mean unfortunately that's the way it is, right?

Robin Heinze:

I mean, that's how I've done every React native upgrade that I've ever done. So you just do,

Riccardo Cipolleschi:

You migrate and you see what works and what doesn't and you work backward from there. Sometimes it's simple application that just use third party packages and hopefully third party packages that are compatible with the new architecture should not have any issue. If you have internal components and internal model, you should start looking into them and see if they works with interplay or not. And if not, tell us why they're not working. Because we are actually having a look at all the issues that have been open. We are giving higher priority to the issues that are taught as the new architecture because we want to make it as good as we can. And so really the way is turn it on, try it and report was not work. Sometimes it's just a configuration thing that we can help you out on the issue and then you're good to go. And I've answered a lot of questions on GitHub or this kind of thing. Some other times you'll discover a real issue. For example, people at Firebase and discover a couple of issues with the Turbo model interplay that they reroute to us and I was able to fix them for everyone.

But if you are a company and your module is not working and you're trying to patch package direct native or fixed internally without telling us about it, you are making it hard too for us, but also for everyone else in open source

Robin Heinze:

Patch package is one of the best things to ever happen. And also one of the worst because the amount of times people just patch it and then not fix it upstream. But yeah, it's really, I want to highlight that for the audience, especially that you running into errors and then telling somebody about it, filing an issue on GitHub is really critical to this process because the meta team has no way of knowing what's broken in the millions of apps that are out there without someone telling them. So you trying it and reporting what's broken is a really critical piece of this process.

Mazen Chami:

And yes, and I can say from firsthand experience, when you do open up that issue, Ricardo does reply to you in a very timely manner. And I've seen it with one of our client issues. We opened up an issue, Ricardo replied immediately, I think it was within a couple hours, and we're able to get a path forward for that task to get things fixed.

Robin Heinze:

There's a way to open up issues that it's the most productive. I I'll say that

Mazen Chami:

Repro,

Robin Heinze:

Don't just copy and paste the error and fire it off. A minimal repro is really helpful. The steps that you use to reproduce it, your environment, the package go through, do your due diligence to make the issue as useful as possible. But I think the amount of work that the meta team has put in, we owe them that much at least to file useful issues.

Jamon Holmgren:

And sometimes doing the minimal repro, you'll find a bug somewhere you didn't expect. It's actually not what you thought it was. I think another thing that's sort of hurting community adoption is that not so much that maybe the third party libraries don't support the new architecture, but they may be like five versions behind. And to get up to speed on their third party library to the one that does support the new architecture is actually a tremendous amount of work. And it's not just one. They have multiple third party libraries. They're all kind of old. Their React native version is old. Maybe it supports the new architecture, but it doesn't have all the latest bug fixes in it. And so they're pretty far behind. We just did actually a project

Robin Heinze:

They were upgrading from like 60 something.

Jamon Holmgren:

Was it 60? It wasn't 68 was it?

Robin Heinze:

I think it was 68.

Jamon Holmgren:

Was it really? 68. 68,

Robin Heinze:

Yeah. Well, and they ended up not adopting the new architecture because they're dependent on Stripe, which is still not compatible yet. Yeah. But yeah, getting up to even just a version where you're able to turn the new architecture on is a huge effort.

Jamon Holmgren:

Yeah, totally. And Dan Edwards led that effort and got them up to, I think he's currently on 77. There was an issue with 78 that he couldn't quite get past that, at least in the shorter engagement that we did. But there's obviously we have a path also for getting to 78 and hopefully 79 now that that's out. But yeah, I mean obviously staying on top of upgrades will always, almost always serve you well. We don't tend at Infinite Red to stay on the latest meta released React native. We stay on whatever expos on, and that's a fairly common strategy across the board. Now, meta does need people to use the latest versions too, the nightlys because they need, yeah, nightlys would be great, but obviously also just the latest released because they need the bug reports and stuff. And there are people who like to be bleeding edge and obviously go do that. For a lot of our clients, they can't really afford to be leaning edge. They're fairly mission critical apps. So we're on whatever the latest SDK is for expo, even if we're not using Expo, even if it's a pure React native app, we more or less stay there. That's not universally true, but that's kind of how we tend to approach it.

But yeah, I mean that I think often there's a lot of companies out there that are like, Hey, I would love to use all the latest and greatest stuff, but we're still on 73 or something. And also the reason we didn't go to 74 is because some library we're using or multiple libraries we're using, we'd also need to update those. And that's a lot of work and we've got a lot on our pipeline, so we get that. But I do agree that you're missing out on a lot of the latest performance stability, all those things as well as there's new libraries coming out that are only working on the new architecture, they're built for the new architecture. They do not work on the old, maybe even the compact layer wouldn't work for, you're just kind of out of luck unless you upgrade. And so I do recommend you try to stay up on the latest and greatest if possible.

So in that same ba, one of the bigger challenges, even within Infinite Red and we have very experienced React native developers, most of our developers have been working in React Native for many, many years. Getting all of them up to speed on the new architecture actually like, Hey, how do I modify these native modules has actually been a pretty big challenge over the past several years. I think the docs haven't quite been there. And you might agree, Ricardo, that the docs haven't quite been at a level where you can be really proud of them. Certainly there's been a lot of work that's gone into the docs and I don't want to take away from that, but just from our standpoint, obviously that has been a challenge. I assume it's going to be more and more of a priority as the adoption keeps going, and have there been some improvements that maybe aren't as visible to us?

Riccardo Cipolleschi:

I completely agree with you, that could be better. In fact, this week at Meta we have better engineering or sustainability week. So it's basically a week where we do not work on our regular projects and we can spend time doing some pick this on the code base or documentation. And actually I'm working on the documentation for the architecture these days. Oh,

Robin Heinze:

Nice.

Riccardo Cipolleschi:

So expect something nice. There you go, coming up in the next, hopefully this week. But with code review and stuff, it might take a little bit more. So some new articles will come up and in the guides on the website in the next few days. That's fantastic. That said, there is one thing that is worth mentioning. The new architecture, as I said, is stable is here to stay and we think that it is production ready, but we learn new stuff every day. And so sometimes we change some API from one version to the other or we change, for example, there are some changes coming in how models are registered. One big change in 79, there will be another change in 80 to, for example, to initialize your native modules that require the main queue to be initialized, for example, on iOS. And those small changes, you can see them in API in the APIs, that's not a justification not to create the documentation of course, but you can see how if we develop a feature, we write documentation, then we reward the feature, then we need to rewrite documentation and the loop is continuous, right?

So what we try to do is to write a minimum set of documentation that is we think is stable enough that is not going to be changed. And when we are sure that the new feature are stable as well, we improve the documentation for that this year. We also kickstart internally a new process that will make sure that all new features that we're developing are going to be documented to some degree in the website. So I think that 2025 will be a good year for React native documentation in terms of how the new architecture is explained, how most of the React native core is worth. We have another colleague of mine, Ruben, is actually working on documenting how the internals of Tive works. That work will not be in the website, but will be probably in the repository in the form of marked down documents. But if people are interested in understanding some of those changes, why or why Tive works that way, there will be documentation for that.

Mazen Chami:

Two points. One, your native module document is great. I've referenced it many times when we gave a training, I think we've mentioned on the podcast earlier this year. One of the last sections is everyone's like, Hey, I want to do the React native advanced tutorial, and that's usually now in today's world, new architecture, native module building, stuff like that. I built it out and then actually I went and redid the tutorial that you all have on there and they were great and they helped me refine, refine, and push it forward. I think it's great. And I think outside of that, I'm sure you all would appreciate it if the community also opened up some tutorials or docs towards the documentation to help you speed up that process. Right? You mentioned you're doing a small set of the docs, that's one person for a week, the docs, there's a lot of docs out there that need to be written.

So getting more firepower on it is a call out that I think we should all have. The next thing I kind of want to dovetail into, and I think it comes from being we're all React native fans and we want to see it grow and we think it's very important. It's critically important, dare I say, to the ecosystem, the new architecture. Do you feel that your need to go to the new architecture was the best and most relevant decision to help React native, stay relevant and continue to grow and be cutting edge in the industry?

Robin Heinze:

Would it have become irrelevant as a framework if you had stayed on the legacy architecture and not changed

Riccardo Cipolleschi:

About what if question, which is hard to give up an answer that is great. I think that the latest architecture serves a lot of purposes and serve them well, but there were some evident limitations that we needed to figure out how to solve them, and they were architectural limitation, right? All the blanks in Flat Place, for example, or if you have a lot of native modules, your React native application startup time was very, very, it was taking a lot of time to start up. Those were intrinsic limitation of the architecture and it was not possible to fix it or work around them with the bridge architecture that we had in the legacy. So yeah, I'd say that yes, the short answer is to keep Tive relevant. We had to develop something new to invent something new, and that was the new architecture.

Jamon Holmgren:

I agree with that. And what I've seen online is a lot of times there will be these criticisms of React Native, which often were valid for the older architecture, the legacy architecture, but the answer can be, Hey, look, that was valid, but the new architecture does address this. There's some very promising early results with that. So it really does help keep React native relevant and competitive with all the other kind of options that pop up. We do have to wrap up here, but this has been fantastic. Really appreciate it. Ricardo, you coming on again? There's so many more questions I want to ask you. Actually. I wanted to ask you about, for example, nitro modules and the different ways of doing things that are popping up out of the community, but I don't think we have time to go into all of that, so we're just going to wrap up. But maybe I'll ask you offline. So I appreciate you coming on. Thank

Mazen Chami:

You very,

Jamon Holmgren:

Thanks so much. Very

Mazen Chami:

Thank you.

Jamon Holmgren:

Alright, and I think that's it for our episode, so we'll call it here. Appreciate everybody coming along with us and we'll see you all next time.

Riccardo Cipolleschi:

Bye. You very much. Bye-bye.

Jed Bartausky:

As always, thanks to our editor, Todd Werth, our assistant editor, Jed Bartausky, our marketing and episode release coordinator, Justin Huskey and our guest coordinator, Mazen Chami. Our producers and hosts are Jamon Holmgren, Robin Hines and Mazen Chami. Thanks to our sponsor, infinite Red. Check us out at infinite.red/radio. A special thanks to all of you listening today. Make sure to subscribe to React Native Radio on all the major podcasting platforms.