Meta engineering manager Kevin Gozali joins the show to talk about the React Native new architecture -- TurboModules, Fabric, codegen, and whether React Native developers need to go learn C++!
Meta engineering manager Kevin Gozali joins the show to talk about the React Native new architecture -- TurboModules, Fabric, codegen, and whether React Native developers need to go learn C++!
This episode brought to you by Infinite Red! Infinite Red is a premier React Native design and development agency located in the USA. With five years of React Native experience and deep roots in the React Native community (hosts of Chain React and the React Native Newsletter), Infinite Red is the best choice for your next React Native app.
Helpful Links:
Connect With Us!
Todd Werth:
Welcome back to React Native Radio Podcast, brought to you by the No Meeting. What are the best meetings? No meetings. Episode 222, the New Architecture with Kevin Gozali from the React Native core team.
Jamon Holmgren:
Mazen, did you get all your Christmas shopping done already or are you a late shopper?
Mazen Chami:
I'm definitely a late shopper. I can never really decide what I'm going to get, so it usually takes forever.
Jamon Holmgren:
Yeah. I mean, it's actually more difficult than... I don't know, it seems like this would be a fun thing, like oh you get to go out. I've got four kids, right. So you also get to see the gamut of how difficult it is to shop for some versus others. Interestingly, my oldest, my son he is going to be turning 17 pretty soon, and he's been pretty easy to shop for. But my girls who are like, 13, 10, and eight, have been a little more, more difficult. I don't know why this year.
Mazen Chami:
How do you stay on top, what gifts to get for them? That's the hardest part for me. Not that I have any kids yet.
Jamon Holmgren:
I have a very organized wife. She's very, very good at this stuff. And I really lean on her and appreciate how organized she is, because that's not me. I'm glad in this case, she can cover for my skill gaps here.
Mazen Chami:
I have a window that has so many tabs sometimes that I can't even see what each tab is and come Christmas time, I'm usually overwhelmed by the amount of tabs. And I just go with the first two or three.
Jamon Holmgren:
We have a slack actually that I set up just for our little family. And so I actually put the kids in there too, but we have a separate channel. I should actually just make a channel for each kid, just my wife and I, so we can put the gift ideas in there, but yeah, it ends up being…
Mazen Chami:
That works.
Jamon Holmgren:
My dad actually just rolled out his website. He's been working on this for about a year. And so I'm going to give a little plug for that, beardshollow.com. He's like a woodworker, he's a retired pastor and he went into woodworking afterward so that's a good place to get gifts. I don't know if there's any inventory left by the time someone looks at it.
Mazen Chami:
I just looked at it and there's not a lot of inventory, but I am going to be scouring the site for a little bit till one of them comes back in stock for sure.
Jamon Holmgren:
Oh yeah. Don't say which one, otherwise someone will snap it up.
Mazen Chami:
Exactly. Or should just lead everyone to the other item.
Jamon Holmgren:
To the wrong one? Yeah. No, I'm really happy he did that. My sister built a Shopify site for him and he's been obsessing about this for a long time. But yeah, it's pretty cool to see him get into this and it's something totally new for him.
Mazen Chami:
That's awesome.
Jamon Holmgren:
Cool. Well, I am Jamon Holmgren. Your host and friendly CTO of Infinite Red. I'm joined today by my terrific co-host, Mazen Chami. Mazen lives in Durham, North Carolina. He's a former pro soccer player and coach. Current coach, not pro coach, but you are coaching, right Mazen?
Mazen Chami:
Kids.
Jamon Holmgren:
Yeah, kids coach. And he's a senior React Native engineer here at Infinite Red. How's it going, Mazen?
Mazen Chami:
Going well. Cold, chilly day.
Jamon Holmgren:
We also have a very special guest today. Kevin Gozali. Kevin is an engineering manager in the React Native team at Meta who has been managing the React Native team for about, I think over three years and has been developing software at Meta for seven years, including working on the ads manager app in React Native for iOS and Android. He has an Ms in electrical and computer engineering from Carnegie Mellon University and has worked at Microsoft, 24/7 Incorporated and other companies before joining the Meta team. Welcome Kevin.
Kevin Gozali:
Hi, thanks for having me.
Jamon Holmgren:
Yeah. I'm really excited to have you on. By the way, 24/7 Incorporated, does that mean you had to work 24/7?
Kevin Gozali:
Not exactly. That's just a company name. It's a interesting one.
Jamon Holmgren:
Oh yeah. Yeah. Well, sounds like that's been a little ago, though. You've been at Meta for quite some time now.
Kevin Gozali:
I've been here for over seven years. Funny enough, first team I joined at Meta or Facebook at the time, was as manager. That's basically the first ever app built with React Native before we opensourced it. So yeah, I've been here doing React Native since seven years ago.
Jamon Holmgren:
That's cool. That's amazing, because that's prior to React Native being available publicly.
Kevin Gozali:
Exactly. I witnessed the open sourcing of that, 2015.
Jamon Holmgren:
We were aware of React Native when it came out in, I think it was the spring of 2015 and then we were doing Native apps at the time. And then when Android came out, that was, I think in September, we jumped on board and that's just been our focus from then on basically. So it's been fun. I think it was version 0.17 or something. That we jumped on.
Kevin Gozali:
That's cool. Yeah. September, 2015 is the right time for Android.
Jamon Holmgren:
We started the company officially in October. Before that, I had a previous company. So it was right after. It was great timing. Anyway, very warm welcome to you, Kevin and I really appreciate you coming on board. This episode is sponsored by beardshollow.com. No, just kidding. It's actually sponsored by Infinite Red. Infinite Red is a premiere React Native design and development agency located fully remote in the US and Canada. You're looking for React Native expertise for your next React Native project, hit us up. We have real React Native experts, not just Reactives that are put forth as React Native experts. We've been doing this a long time. Okay now I just off our audience. Just Reactives. I better not do that. We're good at it. Go to our website, infinite.red/reactnative. And don't forget to mention that you heard about us through the React Native radio podcast.
Jamon Holmgren:
We are hiring also, if you're a senior level React Native engineer located in the US or Canada, go to careers.infinite.red. All right. Let's get into our topic for day. And this is something that we've had a ton of requests for. I mean, people really, really want to hear more about the new architecture of React Native. So my first question for you, Kevin... Well, first off, you're involved in this, right? You're actually working on the new architecture yourself. Yeah.
Kevin Gozali:
I work on this every day.
Jamon Holmgren:
So this is something you know. Pretty well. When I say new architecture, what does that mean to you? Because I've heard things like Fabric, Turbo Modules, JSI, Hermes. What comes to mind for you?
Kevin Gozali:
Yes. So the new architecture actually involved many parts. I think there was a bit of maybe misunderstanding that, oh, Fabric is the new architecture or Turbo Modules in architecture, but how do they fit together is a open question? So to us, new architecture is the whole rewrite of React Native from the beginning of time when you initial as React Native all the way until something renders on the screen. So there's a lot of parts in the spectrum and we categorize the new architecture into three parts. Phase one is Turbo Module, the new native module system, phase two is the Renderer Fabric as you've all heard about. And the final part is initialization path. The new startup path, that part is still on the works. We're still actively experimenting in the main phase app. And the purpose of that is to finally allowing us to remove the bridge.
Jamon Holmgren:
Remove the bridge.
Kevin Gozali:
Remove the bridge. Yes. So how's that going to happen? We introduce also a layer called JSI Javascript interface to help us interface better with the JS engine so you don't have to have this heavyweight Jason compatible message passing queuing from either side native and from JavaScript. So the new architecture rely more heavily on JSI so that we can do direct communication either on either side from either direction. So this is how things are connected. So when you hear JSI, you hear all this thing, Turbo Module, Fabric and removing the bridge. They're all connected. They're not separate project, we're just doing interfaces.
Kevin Gozali:
And then of course, there's this thing called Cogen. Maybe people heard about React Native Cogen, what is it? So this is not an actual run time feature. This is the way for us to provide type safety for every part of the new architecture. So for Turbo Module, when you write a new native module or when you write a new native component for Renderer Fabric, we generate code from JavaScript to ensure type safety. And this is how we... This is the way we ensure that typing, naming and lookup are all consistent throughout. So all of these terms that I just mentioned is part of the New architecture.
Jamon Holmgren:
Wow. That's really helpful. And I think that's the first time I've actually heard it explained that way. So I appreciate Kevin. I've heard all these things floating around and I'm in the core team, the Open source core team discord and stuff. And it's still been slightly foggy for me. And that really clears things up.
Mazen Chami:
That was a great explanation. I have a quick question on all those phases. Can we consider them as one package or are they separate?
Kevin Gozali:
A very good question. So initially when we started the new architecture, we thought that, okay, let's just rebuild everything, then ship it in one go. After months of experimenting, we realized that, okay, this is actually very big pieces together. And it is very, very risky if we just roll everything out together because who knows what's going to change in some part of the app. We want to make sure that that compatibility is achieved and stuff like that. So if we just flip the toggle for everything, then there's a number of risks that may show up. And then we decided, okay, let's roll this out face by face. So we ended up rolling out Turbo Module, like the new native module system first in the entire Facebook app. I was an Android and then the Renderer, the Fabric site, we finished that after, I think a few months after.
Kevin Gozali:
So we finished that earlier this year in the middle of the year. And then now we're on the next phase of the initialization path. Now the nice thing about this approach is that we can work on the multiple faces in parallel. So there are some people in my team working on just Turbo Modules, some people working on just the Renderer Fabric and different people are working on the initialization part. And that helps us like, okay, figure out everything that we need to know, let's build it together and to make sure that things are aligned. So, we don't really want to produce a system that feels very different, on different phases. And then let's figure out how things are connected. So for example, Fabric actually requires Turbo Module to some degree because they are the model of the natives to Javascript communication that needs to happen in the same way.
Kevin Gozali:
And then the new initialization part also will require Fabric and Turbo Module because it doesn't make sense for us to build, revamp the…using the old system because there's a lot of open risk and combination that doesn't matter in the future. So to answer your question, to summarize the answer, we do it in phases. The most important one for people eventually to move to is the first two, which is the native module and the Renderer, the…is somewhat more transparent. It may require some changes on your app level. It's not going to change your react components.
Jamon Holmgren:
Okay. Turbo Modules is something that's been really interesting for me. I don't know, I like the native side of things. I like to work with that integration back and forth between the two. So I've been really excited about Turbo Modules just because I like working with the native side of things and the integration between the two. But I have this sense that... Are you writing code in C++ or can you still use Objective-C, Swift? Kotlin, et cetera?
Kevin Gozali:
Yeah. The answer is yes and no. So the old native module system actually rely on the native code to explain what you can access in JavaScript. So for Objective-C you write Objective-C classes, you have a macro R syntax for module R syntax method for Java, you have annotation processor and then you annotate your method, stuff like that. And then during run time, we load classes to send information upfront. And then we tell you, "Hey, you have all this method and modules that you can ask us." So Turbo Module simplifies this by reversing the direction. So the problem with having native telling you what is available is that you have to load all the classes pretty much in the app startup and for a big app like Facebook, that slows on everything during startup. Therefore we need to make it lazy. How do we make the discovery of this registration lazy?
Kevin Gozali:
It's by reversing the direction. We use JavaScript to let you define what API you want to expose. And then we use semiautomatic registration so that we can tell the system, "Hey, next time, if someone looks for a module A or component B, here's how you look it up," and then just use that going forward. So everything is lazy by default for all of the new architecture, which is good for app startup if you have hundreds of modules and components. And let's be real, I think class loads in Java is very expensive for low end device. You can spend seconds class loading. Yeah. So given that what you write is JavaScript typing, we use Flow just because the company use Flow for non ranking use Flow to generate like, "Okay, what is your API? Let's generate the binding, the C++ binding to translate how you call from JavaScript into native."
Kevin Gozali:
So the C++ will take care of translation to Objective-C, Meta Class and Java Meta Class and vice versa. So the layer that generates this binding is the Cogen. So you don't write C++ at all, you write typing in JavaScript, we integrate with the Cogen automatically so that you don't have to write an implication of Cogen. And then the code we produce is C+ binding that you don't have to touch it. Objective-C interface, protocol, sorry, that you can adopt in your class and then Java abstract class that you can inherit in your classes. So your module implementation just need to conform to that generated classes or a Spect, we call it Spect. And then things should be available during run time.
Kevin Gozali:
So technically, we can produce any class that we want. We can produce C+ or a base class or nothing at all. I mean, you can set it up as you like. You can customize how the look up happened and you can provide your own like C++ only implementation using JSI, like direct JSI, whatever you want. And we can probably also produce Kotlin base class. So base class, whatever you have, like C-Sharp, anything, that's the intention going forward.
Jamon Holmgren:
Yeah, that's really cool. That blows my mind a bit. And I've been doing quite a bit... Our last or one of our previous episodes was about React Native Colo Loco, which is a build tool that I've made so that you can co-locate your Objective-C files and Swift files and stuff with your JSX files and stuff. And so you don't have to be putting stuff in your X code project or your Android studio project it'll link those. It's basically auto linking, but for individual native files. I was really curious when I was building this, how the new architecture was going to affect this. So that'll be something I'll definitely be keeping a close eye on.
Kevin Gozali:
Yeah, definitely.
Mazen Chami:
So now that we've covered Turbo Modules in the first phase, phase two, you mentioned was Fabric. What is Fabric? And as a developer, can I use that today?
Kevin Gozali:
Yeah. Good question. So Fabric, for the sake of naming convention, we start to call it the new Renderer. Fabric is just a code name that we spin out before. So the new Renderer aimed to solve the underlying issue with a trading model and React Native. So if you know, in the past react is synchronous so React Native forced everyone to be in sync in all the communication native to JavaScript. That means any part of the layout, UL layout, UA measurement needs to be always async from both direction. This is fine for most cases, but you start hitting some limit when you have some very corner use case where you may see flicker because everything is asynchronous. So we're not waiting until layout is ready. We're just like, okay, we're done. Move on to the next thing. So you may see one frame or two frame of artifact, sometime when, for example, when you first load React Native, you may see like, oh a flicker with some resizing and vice versa.
Kevin Gozali:
This is not just about the initial loads, sometimes when you need to do in a synchronous layout, when you are in the list, like a long list, you may see some artifact, just a one frame artifact of things aren't already maybe two frame, maybe more depending on your device. So this is a limitation in all architecture with Fabric. We aim to use the Concurrent React, now it's called Concurrent.futures with React 18 and stuff to allow synchronous model and React Native. This is interesting because before React Native is asynchronous and now we're making reactive synchronous to allow a sync react. So let me repeat that. So React Native has been asynchronous and react with synchronous. We're reversing that React 18 and Concurrent.future is trying to be asynchronous, but in order to do that, we need to react to it to be synchronous.
Jamon Holmgren:
Wow.
Kevin Gozali:
So this is a funny reverse fraction kind of thing. And in order to achieve that, we need to rebuild the entire UL layer Renderer for React Native to allow flexible credit model and that's Fabric in the architecture.
Mazen Chami:
That's awesome.
Jamon Holmgren:
I can just hear all of our... Not all, but a lot of our audience being like, "Yes, this is going to fix..." Because the one, two frame flicker artifact, it's so common. Mazen, weren't you just telling me that you were running into something where you had to measure the size of something and the asynchronous? I mean, he's literally struggling with a problem right now on a project because of this.
Mazen Chami:
Exactly. Yeah. And you just mentioned like, everyone being... Yes, I have the opposite. I'm speechless right now. I don't even know where to go to next.
Kevin Gozali:
Yeah. I can add one more thing, which is Fabric is the foundation. What I just described to you is the foundation to allow all this use case to be actually finally built. In order to make use of all this new capability, we need to integrate with Concurrent React. So that's actually an active project right now, still experimenting to allow this kind of model. So at some point in the future, we'll be able to execute a certain layer or event for making this synchronously. The most common example is text input, right? You have inputs and then you want to control what is on the screen and something you have like one frame delay of things that are not synchronized. This Fabric foundation is going to help us solve that. Fabric alone is not the solution, but it's a foundation to help us build more capabilities.
Mazen Chami:
Is this available for developers to use now or still in development?
Kevin Gozali:
So yes, we are working to build a playbook, a comprehensive playbook for how you can adopt the new architecture all the way up to the second phase. And we're actually discussing with some partner and we're planning to opening more widely sometime in the next year. The exact timeline, we're still working on it, but we're working very hard every day to make it more available to all of you, starting with a new app. So hopefully in the near feature and next year you can start opting in, in your new app using a template from React Native to just try it out. We're not ready to announce that this is done, everyone can use it widely anytime, because there's a lot of pieces involved. Some library needs to be made ready to be the new architecture. There may be some changes that you need on the components or modules and we're working to provide the playbook for that. So hopefully by next year everyone can just follow this and most modules can be ready.
Jamon Holmgren:
One of the things that I think is on a lot of people's minds is, is this going to break our apps? Because when you roll this out, it sounds like a pretty significant refactor. How much of this are you intending to be backwards compatible with the bridge and how much of it do you think that we're going to have to make some major changes to our apps?
Kevin Gozali:
Yes. Good question. So let's break that into pieces. One, do you need to change your react components, like your actual product? The answer is most likely no. We try very hard to maintain back with compatibility so you can use the hooks effects and all that fancy stuff. You can use that and no problem. There will be some deprecated API because the old architecture have a bunch of, let's say UI manager related API that is maybe not very well documented and maybe is not compatible. So we're working on guidance on how to migrate away from that. There is an alternative, but we just need to provide that in the playbook. So if you use a custom API like that, you might need to change something to something else. But that's about it for JavaScript. For the native side, for Turbo Module going a bit deeper here.
Kevin Gozali:
So for Turbo Module, your native module as is, will work. However, you need to integrate the generated output that I mentioned before via Cogen just so that there's a type safety aspect. This means it's a bit of additional work on top of your module. You don't have to rewrite it though. So if you have a method that implements asynchronous, whatever fetching of something, you don't have to change that, it will just work that we try to preserve the trading model as much as we can, even with the old syntax method queue for iOS and other stuff like that. We try to preserve that in the future or we probably just going to remove it. But for the sake of compatibility, most of the time your classes will just work. Just need to add something. For Renderer, the components, it's slightly different.
Kevin Gozali:
Most of the time for iOS, you can use the view managers as is. We have a backward compatibility layer that you can adopt to start with and ideally to get the most benefit for a no... Overhead, you might want to adopt the full Fabric compatible approach. It may involve some rewrite just like the base class. For Android, we try to make it as much backward compatible as possible with the view managers, so most of the time no changes. So there are options. So I think we will leave it up to the people adopting this to decide, okay, how much do you want to adopt? Is it full capability or just like, I just want to adopt and see what happens?
Kevin Gozali:
Depending on how you set up your app, you may be able to enable the new Renderer or the new Renderer based on your root view. So if you have a system in the hybrid environment where you have multiple root written the root view, you may decide to enable Fabric one at a time. In fact, we did that for the Facebook app just to derisk. So yeah, there's a lot of option and all of these will be documenting and will be shared in playbook as we hash it off.
Jamon Holmgren:
Perfect. Yeah. And one of the things that comes to mind for me is the... I help maintain the React Native web view and that has a ton of native modules it also has a ton of native UI components. And so I guess, in the back of my mind, when you drop in a React Native web view into a brand new app that has all this stuff enabled, how hard will it crash? And so that's something, I guess that's just up in mind for me.
Kevin Gozali:
Yes. Good question. We try very hard to be backward compatible. So if you have a native module that is not ready to be Turbo Module, we just execute it as if they're the old native module. No problem so your app is fine. For Fabric, there may be some registration that you need to do, but it's not too big of a deal. But yeah, you can lift side by side, basically.
Jamon Holmgren:
Very cool. That's big, really?
Kevin Gozali:
Yes.
Mazen Chami:
So now, since you've released this new architecture on the Facebook mobile apps, what have been some pros and cons, I guess, as a developer or even from a user experience that you've seen come out from this
Kevin Gozali:
Good question. So there are a few aspect with the new architecture and also for Fabric, which is one type safety. So I explained before we generate code from JavaScript via cogen, and then every part of the code adopt this protocol or Spect that provide a lot of built time type safety. So in the past, because we rely on the run time checks and discovery, you don't know if something is off or misconfigured until run time. But now because everything is co-generated during build time, it guarantees everything to be in sync, assuming you're adopting all the outputs. So I think as long as you do the homework to just do the hook step you can discover, like oh, I mismatched a prop during build time, like someone changed a prop in JavaScript for the Spect and then forget to update the native code.
Kevin Gozali:
It'll fail during build time. So this is a big developer boost because this is a common mistake for many people that, oh, "I update this, but I forget to update the other file," kind of thing. And vice versa. So that's one, type safety is a thing. The Fabric that render itself brings a lot of correctness. So the old architecture has a bunch of implementation and not everything is perfect. So of course there is loopholes here and there in terms of when I set a prop here, what happened to actual behavior on iOS and Android? Sometimes they're different, like subtle different but it is there. With the Fabric as the rewrite of the Renderer, we had a chance to reevaluate some of these and sometimes make decision to, okay, let's make sure iOS and Androids is now consistent and it's more correct. And then if there is ordering or even ordering a flaw that happened in the past, in the old system, we had a chance to reevaluate, okay, is this the right ordering? Can we actually do it properly and increase correctness basically.
Kevin Gozali:
And like I touched on before, with Fabric, we can start building infrastructure to allow Concurrent.future, synchronous access to stuff. Before in the old architecture, this is not possible at all. Sorry, one more thing. I mentioned before that everything is loaded lazily by default, this will help improve your app performance, startup performance. Obviously it depends on how many modules or components you have loading, but we try to make it lazy by default. And then you can opt in to be more eager, or you can load stuff upfront as you like, customly. But we try to make the default case to be more performance. So you get a bunch of this benefit. Some of them are direct benefits, some of them are feature wins or feature capabilities that you'll be able to use in the future as we finish the entire capabilities work. But a lot of benefits, really.
Mazen Chami:
That's great. Yeah. I was reading the article that was released about this new architecture. And I did see a lot of references to garbage collector. Do you mind going a little bit into what that is and how that ties Fabric?
Kevin Gozali:
I believe that's somewhat separate. Yeah, from the JavaScript point of view, there is a bunch of logic on how you garbage collect your reference. And then from the native side like iOS have its own garbage collection, let's just call it, and then in Java they have their own VM and Jay and I have their own way to a release memory. So one thing we do here is that with the new architecture, we try to share the memory ownership from native to JavaScript a bit more. And by the way, this is possible, thanks to JSI. And actually, if you just use the JavaScript API that exists on the platform, you can probably do that by JSA, make it more easier for us to adopt this. So imagine you create a memory on the C++, which is hopefully tied to the native platform.
Kevin Gozali:
And then we use that and pass the reference as is to JavaScript and the JavaScript side, the React core will decide, "Okay, I'm going to hold reference to this for now, later with fiber and the Concurrent React. So I'm going to release it in the future. And then that's where the memory get released." I think the most relevant thing from the new architecture is the fact that we start sharing memory more and more between the two worlds, is allowing us to make this communication layer much more efficient. And you don't have to have a copy on native and JavaScript. You just have one copy and the JavaScript core react decide the life cycle.
Kevin Gozali:
And I think that's huge. That's means simplified communication layer and then having one entity that managed the life cycle. I think that's great.
Mazen Chami:
That sounds amazing. Yeah.
Jamon Holmgren:
Yeah. That is incredible. I'm blown away that this is even possible, but JSI unlocks a lot of things. Now, JSI, was that developed at Facebook or is that something outside of Facebook?
Kevin Gozali:
JSI is definitely inside Facebook. Meta.
Jamon Holmgren:
Okay, cool. Yeah, it's a fantastic piece of technology.
Mazen Chami:
So there was a couple articles that came out about the whole drive to React Native all platforms with this new architecture and Fabric. What role does it play in bringing all platforms to React Native and is this like an improvement that will make it easier for us to go to the different platforms out there?
Kevin Gozali:
Yeah. Very good question. One fundamental decision that we decide a few years back when we started the project is that the core Renderer and infrastructure should be written in C++. At the time, C+ is the cross platform language that is available. So we chose to do that and it is already available in many mobile apps anyway, so we stick with it. So we built the Renderer mostly in C+ with the core infrastructure, even through a module that the core system is in C++. So we interact directly with JSI, the JSI C+ with API, right? So you see how all the core infrastructure is moving to C++, and then we're also trying to build a scheduler, a React scheduler that is in C++ on top of all these infrastructure. So what this brings us is that with Cogen and everything else and type safety across. One, C++ is across platform language, so it's easier to integrate in different platform, not just iOS, not just Android, Windows as well and maybe more iOS in the future.
Kevin Gozali:
Plus one, second, because of the Cogen, we have control over consistency type safety across all different platforms. So with that foundation, the hope is that we will A, be able to spin up a new platform, like a target platform as just a mounting layer of the Renderer. Mounting layer means that all the logic happened in C+ already, the core will tell the platform to decide, "Okay, Hey, I need to insert a view here. I need to delete or remove or update something here." Do whatever you need on the platform. So at the end of the day, because of this cross platform foundation, a new platform being onboarded into Fabric means they just need to provide the multilayer on their own specific thing. And that's basically Python specific. So what we believe is that given all of these, it will make it easier for us to expand to multiple more platform in the future because of the foundation.
Mazen Chami:
That's great. That's awesome.
Jamon Holmgren:
So all this stuff is built in C++. Did you have to go learn C++ or did you already know it coming into Meta?
Kevin Gozali:
So I personally have learned C+ in the past but not the modern C++. So I used the traditional pointer base C++. The team had to spend months trying to learn C++. Especially modern C+, like what is smart pointer? What is the life cycle of no exception handling and RTT, all that. So yes, there is a lot of ramp up and it was not as easy decision for us because when we started, we didn't claim ourself to be a C+ expert. We actually learned a lot. And some people in the team spend hours and weeks learning from resources out there, like what is the good C+ and what is the pattern? And try to bring the best of that into the Fabric and Renderer.
Jamon Holmgren:
Yeah. The thing with C++ that has always been a little intimidating. I know a lot of languages and I've learned a lot of languages over the years, but C++ has this massive API. And over the years, it's changed what was idiomatic modern C++ over the years. So if you learn something from a book, like I did way back in the 90s and 2000s, some of that stuff may apply, but some of it might be... That's old school, you shouldn't do it that way anymore.
Kevin Gozali:
Yeah, definitely. And C+ is evolving as well. There is first 11, 14, 17 now 21. And who knows what else? So I think as the language mature, there's more API that is built in that we were not able to use before. So at least for us, we're trying to find a good middle ground on what is a good modern API to use. And then try to use that on the Fabric system.
Mazen Chami:
On this podcast, we have a discussion. It's ongoing, I would say, about as a React Native developer, do you need to understand Swift, Objective-C, Kotlin and Java to be an effective and senior engineer? I believe that was the discussion we had. Now that you're bringing in this C++ talk, do we now also have to understand C++ to be able to be more effective? Or is that just something that's completely under the hood and we just focus on the native language and JavaScript type script?
Kevin Gozali:
Yeah. The new architecture does not require you to learn C++ to use it, as I explained. Before we use code generations, so we take care of the layer that is in C++ for you. Most of the time in the common cases, you just need to continue writing Objective-C or Java if you need to write a native. So I think it doesn't really add express stuff. Obviously, now that there's a lot of C++ you have room, maybe if you are interested, you have room to dig deeper into like, "Oh, how does this work?" And then maybe you can build something a bit more specific with C+ and bypass all the system that we build in place, because we're trying to cover the default cases. There're always more use cases that can be unlocked.
Kevin Gozali:
And if companies or apps want to explore that, it is a possibility and we're trying to be flexible in this design. Right. We're not locking you into the, "Oh yeah, you have to learn this for sure." But then provide some flexibility by default. And so you can opt in to how deep you want to go in different area. So yeah, in a nutshell, I don't think you need to definitely... Yeah. I don't think you need to learn C+ for sure. We take care of stuff for you, but it is definitely an opportunity to dig deeper and maybe improve even further.
Mazen Chami:
Absolutely. Yeah.
Jamon Holmgren:
Mazen, I'm going to buy you a C++ book for Christmas.
Mazen Chami:
Thanks. Yeah. I put it up behind me in my shelf. I'll put it right next to a dance book. Okay. Well, Kevin, you mentioned a lot of this parallel work that's happening through the different phases through this project. And given that you are the manager on this project, do you mind going through your experience managing this team, managing this project and some challenges you might have gone through?
Kevin Gozali:
Yes, absolutely. So the idea of rewrite to some people is exciting. Like, "Oh yeah. Let's rewrite. Of course I like rewrite." But then if you look at the state of the world at a time or React Native at the time, we are trying to solve a flaw, all architecture with the async nature. And we're trying to rewrite that in place. What it means is that Facebook app at that time used regular widely, and we want to continue making sure that product can continue running, no disruption, while rewriting all of these at the same time. So that presented a lot of challenges because first of all, okay, how do you rewrite? You can build a brand new... Build a new brand new system, and then just test it later when you're done and risk everything, just, not behaving as you like.
Kevin Gozali:
So how do we do it in place, step by step? How do we build pieces by pieces, slowly? So that takes a lot of iteration to learn and like, and also C++ right, we decided to learn C++ so how does my team able to pick up this thing if we have to write it and pick up the language and rewrite and then make decision while keeping all the products alive, like no disruption. So that's the fundamental challenge. So that's why quite a while to get it right. And then we try to resolve most regression from different products. Sometime it takes months to investigate out of memory issue, maybe we leak something some where in the complex system, took forever to find it. Sometimes product rely on the wrong behavior that I explained before. Maybe the architecture has some behavior that they just, oh yeah, this is great, I'm just going to use it.
Kevin Gozali:
But then we fix it correctly that it breaks product. So who's right now? Is it a product or is it our infra? And obviously for every cases we need to do it case by case. And we decide and maybe work with the product teams. "Hey, let's figure out the path forward for this specific issue so we can move on," kind of thing. So from the managing point of view, this is a lot of big scope. And I think it's great for people for growth. People have opportunity to like create massive impact, stuff like that. So I think that's great. At the same time, the drawback, the challenges is that, how do we keep people motivated to push through until the end? So yeah, this is multiyear project, setback happen. You try this, you try to build a small feature, you trying production, it don't work. And maybe that demotivate you. So how do we keep everyone, like, yeah, we want to keep pushing and we want to continue. And remember Fabric is only the second phase. We have the third phase, maybe more stuff.
Kevin Gozali:
The challenge is about, let's keep moving, always move forward. And then whatever happened is a learning experience. So it's all about that. It's maybe encouraging people and addressing setbacks. So that's what it looks like.
Jamon Holmgren:
Yeah. It's a big project. Yeah. And there had to be a lot of internal, I guess, support from your management and whatnot in order to get to this level, because this was a lot of work I can tell just by having talked to people on your team. It just seems like there definitely was a lot of work, but you're seeing the light at the end of the tunnel now and it seems to be getting close.
Kevin Gozali:
Yes. So one thing I could share is that we knew from the beginning that this is the foundation. So some people might thought, "Oh, how come I don't get immediate wins on my surface?" Because it really depends on how you write your surface, right, or product. But then when we start experimenting with the new capabilities, Concurrent.futures. And that on top of Fabric, then you find some of us finally got it. Yeah. This is why we built this thing. It's been a long time, it's worth it, this is why. So excited to share more when we're ready, but that's the time it takes us to get to this place.
Jamon Holmgren:
Perfect. So one last question for you.
Kevin Gozali:
Sure.
Jamon Holmgren:
And I have no idea if you can answer this or not, but I'm still going to hit you with it. Once this is fully ruled out, can we finally go 1.0?
Kevin Gozali:
We'll see. So to explain from our perspective, 1.0 or 2.0 or whatever the number, is just a number. We always use the latest branch from GitHub. So Facebook app is always on the main commit at any time, which means what matters for us is that the main branch is stable. So however frequently released updates, it is the most important thing for us to make sure that it's stable. So for us, at the end of the day, the first year number is just a number. There's a lot of work for us to get to the stable place. Fabric needs to ship, the phase three needs to ship and Concurrent.futures and other stuff needs to start getting built out. And maybe with everything stable, we will be able to start considering maybe 1.0. It's more a reality, but right now it's still far in the future, I believe, to be able to tell when or whether this still make sense or not, but again, for emphasis, for us it is very important that the tip of the three is always stable because that's how we move fast.
Jamon Holmgren:
Yeah. That totally makes sense to me. I think the only place that this really matters is sometimes you'll get in discussion with a Flutter dev or something. And they're like, "Well, we're on 2.0. You're not even on 1.0 yet." As some sort of an indication of how stable it is which as we all know, there's no guarantee of stability just because something hits 1.0.
Kevin Gozali:
Yep. Definitely. We try our best to make sure that the main branch is always stable within the Facebook app and so you don't have to do all the hard work. So yeah.
Jamon Holmgren:
Very cool. Well, thanks so much, Kevin. This has been fascinating. You've dropped a ton of knowledge on us all here today. And I really appreciate you coming on the show. If people want to follow you on Twitter or whatever, where can they find you?
Kevin Gozali:
You can follow me at Twitter @KGozali or GitHub. I don't really check or actively engage in conversation. But if you have something just tag me in, I'll try to respond as much as I can.
Jamon Holmgren:
Perfect. Mazen, where can people find you?
Kevin Gozali:
@mazenchami.
Jamon Holmgren:
And you can find me at @JamonHolmgren. You can go to the show, Twitter @reactnativerdio. Thanks again to Kevin for joining us today and as always thanks to our producer and editor, Todd worth our assistant editor and an episode release coordinator, Jed Bartausky, social media coordinator, Missy Warren, our designer, Justin Huskey and our guest coordinator, Derek Greenberg. Thanks for our sponsor. Infinite Red, check it out. Check us out at beardshollow.com. No, and a special thanks to all of you listening today, make sure to subscribe on all their major podcasting platforms. We are React Native radio. Also reminder that Infinite Red is hiring react. Native engineers, go to a careers dot, infinite dot. See you all next time.