React Native: 2022 & Beyond

Good morning. All right, perfect. All right, so we have a relaxed just three hour talk, right? It's talking about React Native 2022 and beyond. Oh, 20 minutes. I could shorten it. No problem. So you've already heard about me. I'm CIO of InfantRed, published author. Take pictures of me during this presentation and tweet them at me, at Gant La Board. I did bring a really cool copy of my book and I did put it in sort of a steampunk sort of duster for the book and everything like that. Super amazing. So I will select one of you afterward to go ahead and give a signed copy of the book. I'm also a GDE, MDE, Oracle Groundbreaker, Amazon Community Builder, and then just to round out the alphabet, I put LMNOP. So to talk a little bit experience with React Native, started back in 2015 with a wonderful company called InfantRed, and if you look at React Native, we're everywhere. In 2016, we took over the React Native newsletter. In 2017, we started Chain React Conference, the U.S. React Native conference, and in 2020, we took over React Native radio, so if you're looking for React Native news, we are significantly involved, and we've helped quite a few people along the way, being that we are a consultancy.

So you're all here to talk a little bit and learn a little bit about React Native, and it's just sort of like one of those times where like React Native works, right? We're all adepts to this. You're in great hands today because I've only got 20 minutes to dive with you, but you have so many amazing talks coming up. These are some talks that are happening today in this exact same room. These are going to be about the new architecture, these are going to be about React Native everywhere, these are all the cool concepts that I just want to make sure if I don't cover it in this, I know they're being covered by talks later on today. These people will take great care of you.

So this is the first morning talk, so we have to dive back for a minute talking about React Native independent JavaScript. What's the origin here? And just because I never know what the room is going to be like, how many people are used to it or not, but React was a composable function encapsulation for writing HTML, but now you're writing JavaScript components. It took this idea of these components and then wrapped them up so nicely for you, and it made it feel like HTML, but every time, as most of you have done React, every time you try to set the class, you realize you can't do that because it's actually all JavaScript underneath there and class is a keyword inside JavaScript, that's why you have to say class name in React. But it could be anything in there.

And then we actually make really cool components and then we render them out. This is the original how React Native was working. You had your DOM layout rules going to yoga layout to layout for the particular host platform, and then we were able to make up these really cool things. It could have been called anything. A view could have been called a div. I think that's moving backwards in a certain degree, but it's always a view and different things. But you have in React Native, you have these higher level ideas, view, scroll view, text, text input, and then at the bottom there, I have translations to people who have only done React.

And then of course, as we all know, this is where the native comes in, right? Native, I go ahead and put a text component on there, it becomes a UI label, or a text view depending on what platform it's actually landing on. And as we all know, this is the infamous bridge system which has been the bane of some people's existence and not too many, but here you have your host or native platforms communicating via serialized strings directly into JavaScript and communicating that back. So this is what the classic idea was when we kind of started this whole thing. This was the bridge, and it was such a great idea, we were able to take JavaScript, run it through, and then get it on a particular host platform, and that was it. We were hooking up packages from npm directly to mobile apps. This is how the groundwork was laid, and then, success, React Native is working, we're all happy, nothing left to do, and we're all set, except for I was not a big fan of how the experience was at first, even though I loved React Native, there were so many headaches, and I wrote an article, please, everybody, this is such click bait, right? But it was a fantastic article and I wrote what sucks about React Native, and I went over all the things that sucked back in 2016, and it was actually, all those things are significantly solved now, but during this chaos of first connecting these two things together through that single thread of this bridge and everything else like that, we had these questions, people had questions about how do we talk to native, it wasn't understood immediately at first. People had questions about backwards compatibility for as React Native updated. People had questions about async versus sync. It was very interesting because in the React world, you weren't used to this asynchronous structure, there was no such thing as async inside React. So then you come over to React Native, and everything that goes across the bridge is async. And then people had questions about what libraries to use as we make progress along the way. So, has anybody been doing React Native since 2016? Remember the pain points? Oh, I see some pained hands. Lift! And so, also, a funny thing, I had this one part in the article, the fight of the navigator, if you remember back then. Navigation. Fortunately, people improved that significantly. But our goal was to share the wisdom. And just open source. We're an open source company. So, of course, I had this one solution.

And back in 2017, I thought my solution for this was just to go ahead and create a kitchen sink, a sort of boilerplate of information that says, like, here's how we are delivering apps at a paid consultancy. Here's the problems that we have, here's our solutions, and here you go. And it worked fantastic. Ignite has over 14,000 stars. It does extremely well. We have tons of success stories that people have shared with us, in lots and lots of production apps out there, and it's just kind of nice to have that, you know, people are constantly telling us, why are you giving all this away? I can't tell you how many open source libraries, I'm sure all the wonderful companies out there that do open source hear us all the time, Formidable, I'm sure everybody is like, how are you giving away VictoryCharts, things like that, how are you giving away Ignite. How are you doing all these things for us? We give away stuff, and that's just what we do, that's what consultancies need to do, because it's a community. So, ta-da, the problem's solved, right? We've told everybody how to do it.

So then, we move along some time, everything's working now, how do we get this perfected? And so we have some big changes coming in, right? As I mentioned earlier, you have React being synchronous, and React Native being asynchronous, but now that React 18's coming in, we actually have functionality to have asynchronous React, and we have the ability to have a synchronous React Native. And so this is blowing everybody's minds a little bit, and we're coming along with the Fabric Renderer, which is giving us concurrent features, interoperability, and priority and synchronous events.

There'll be lots of talks, I'm sure, about Fabric Renderer later on. But we have this new structure, and then it's coming in to all kinds of new functionality, Now we have no more bridge, we have the JSI with direct access across a shared C++ core. So originally you had to do the React Native structure was under iOS and under Android and under each particular host platform, and then now you have this shared C++ layer, so if you come up with an optimization one, you don't immediately get five tickets to do this on every other platform as well, right? We have this improved shareability and faster startup.

So Fabric Renderer is coming in, and of course we've got JSI mixed with Hermes and React Native going to a shadow tree. So now we've got this huge change. The thing I showed you earlier about passing strings between JavaScript and passing strings back to the native platform, the host platform, one of the things that's happening there is this bridge is becoming displaced by the JSI. So we have this new architecture. We're ready. Sounds great. When can we have it? Everything's going fantastic. And then people start working with the new architecture, and I have seen, personally, a ton of questions, including, how do I talk to native? What's backwards compatibility? Questions on async versus sync. Questions about what library to use while progress is made, because not everything is supporting the new architecture. I've heard these questions before. I'm not that old. I'm old, but I'm not that old. So I just go ahead, and I think that one of the best solutions that we've ever had is a great solution again, and of course, I have to say, that's amazing, Ignite. It's a wonderful, wonderful way, and now it's on version 8, and I have to say Ignite Maverick is second to none. This is a beautiful, beautiful boilerplate and information source for everybody, and our goal is we've improved what we learned from the first iteration. We learned how to help people more. So we've had 110 pull requests, 400 plus changes, 14K lines added, 22K lines removed, and yeah, we paid for 800 plus developer hours to go ahead and improve this thing, and that's at U.S. rates, okay? If you see... Zoom in on the tears, if you can. So personally, this is our company's shuttle into the new architecture. We are learning things, and then we're implementing them in a way that we feel like we can share them. And so the question comes in, like, what is it... When you create a brand-new React native app, what kind of things do you add? You always add to your apps. Anybody just shout out a few. You have to add...

What's that? Navigation, yes. Any other ones? Testing. Testing, yeah? You also have crash reporting, right? You have a few other things. So I mean, you're always... My personal favorite. I've always got to update that little icon every time I've got like a weekend project. I need it to say my new app name immediately and all the other cool stuff. These are the things that we solve every time and they shouldn't come with a vanilla React native implementation of an app. But these are the things that come in with Ignite. We have all these features here.

So if you want to, this is the tech stack. You can see TypeScript, a bunch of expo libraries, just detox. So we're talking about testing, talking about state, talking about animations with reanimated. These come in with examples, getting you set and ready to start. And then also we have a bunch of components that we've thrown in there. Almost all the time we have to do customized components. Bringing in a library, you hit the barrier where the library stops. Here you have examples of how to make those components. How to have it all set. An extremely well documented setup of the entire infrastructure of Ignite Maverick.

So when you create a new weekend project, or you create a new project as a proof of concept that we could move to this, or you have anything else set, you are not starting off cold. You're starting off with what we start off with. With every client that we do. And so here's an example. For instance, Gatsby, take a look at this little bug that you see right here. You click, you see that little jitter as it jumps up right there. Can I go to that? Has anybody identified exactly if you saw that right now, would you know exactly the fix? Do you know what that problem is and how to do it? And how to circumvent that issue? No, that was all wrong. I can do that. He's the MC. If there's one person you can pick on, it's the MC.

So you don't have to worry about that. If you're using RView, here's the pull request and you see the number is 2234, the pull request to fix that, and that fixes it in every project that's happening there forward. So that is a solved problem. You just using RView, you just won't see that problem. You're getting R value there specifically. That's what I want to say.

I can't contend with what everybody can do. It's teaming up. Also internationalization is great. We've got left to right, right to left. If everybody can do that. We've got team members who've translated that. It's wonderful. My personal favorites, you immediately get a splash screen and icons in there. I know everybody's got their own tricks to do it and all this other stuff, but it's built in. And so here we are. This is the payoff from real projects, from our experimentations which happen in small increments. And then when we find that it works, we bring it into Ignite so that it works for everybody. And so that's how you kind of get this advantage without having to do the experimentation yourself.

This brings on something I really, really think is what we should have done the first time around, but this is great. We are this time adding... You can't add everything in there. It's too complicated. Now we're adding this beautiful idea of Ignite Cookbook. It's free. It's not a published book. It doesn't even make any sense. You go to ignitecookbook.com, and there are added recipes. This is where we would love to have people contribute back. You've added a particular library.

Your particular library needs to be added into React Native. Add it to the Ignite Cookbook, and now it is a step by step formula on how we can kind of add that in. It's not things that every single client would need. It's the things that a client might need. It's something you might need. And that's growing. That list is growing every day. So expect that to continue happening. There is a pull request on it right now already.

So here's the big question. How much is Maverick utilizing the new architecture? And like I said, it's a shuttle into the new system. So, first of all, everybody's heard of Hermes and it's faster start-up, decreased memory. And it's an open source JavaScript engine that's, I believe, been turned on by default. Now, that's something that we've also given a thumbs-up for. Turned on by default. It gives smaller app size. We've seen this. And it's working wonderfully. We have it on an iOS native, Android native, Xbow Go Android. And then because it's not supported yet, it's not inside of Xbow Go iOS. But if you ignite a new app, you get those three, it will be turned on. And so you can almost use that as the litmus test of what we think is capable and supportable.

And is it fabric ready? It's going to be. As we venture in, we are constantly researching what we're doing with fabric. But as you saw, we have a huge tech stack to bring behind. Animations. Things like that. So we have React Native reanimated. But we're using two. We're not using the alpha that's supporting fabric yet.

So since we're not using that on client apps, it's not on inside Maverick yet. Soon as we can, it will, and that's how we get there. So it's almost like I would follow that as a proof of list. And the real big piece of that is turbo modules. Because just as a tidbit about turbo modules, as you know, in the original architecture, native modules had all kinds of issues. Eagle initialization would be cool. But they had eager. Mistakes. And they repeat, there's no way to do tree shaking or anything like that. So what ends up happening is obviously things are moving over to turbo modules, which have a significant set of benefits that are coming in. So obviously as soon as we can, we will be using turbo modules. I'm pretty sure you'll hear about turbo modules a ton of times. I'm pretty sure some of the speakers coming up have it tattooed, right? Is that correct? Yeah. So Maverick and turbo modules, do we have that? Kind of. As soon as the new architecture flag is flipped, it will immediately start using it. So we put the code in there preemptively to make sure everything's ready. But unfortunately, it only works once we can turn on everything in a new architecture. There's not a gradient of adjusting these things. So we have to wait for the green light for it to work. Then turn those kinds of things on.

So like I said, Ignite Maverick is already on version 8.2.5. And we just released 8, not that long ago. So that's quite a lot of improvements already. And during this talk, like I said, I wasn't even able to cover all the cool features that we've actually integrated into this, either. So there's a lot of information. If you have a lot of information, you're looking for a good place to share it, come talk to us. You can see what kind of recipes, what kind of ideas that you have. Maybe even get you on Jamin's podcast and see if you can talk about your opinions. That'd be kind of fun as well.

So what I'm trying to say is that specifically, when you're looking at all these things, React Native has been a proven, solved, wonderful solution that has these speed bumps, as we kind of get these new features. There's this growth pane that we have. As we're seeing it be a success across multiple, multiple platforms, and Taz has a talk about React Native on all platforms today, we have to think to ourselves, well, how are we gonna go into this? And we have this, there's this motto, it's an old proverb that we like to say, that if you wanna go fast, go alone. But if you wanna go far, go together. And if you're looking for people to make sure that what you're talking about is going to and that your company can build their products off of that, this is how you can do that.

I have to say, thank you so much to all the wonderful people. I call them, actually, Jamin coined the term, but I love it, the Ignite Pyromaniacs are the contributors. We've had over 170 contributors to Ignite. And these people have helped out immensely in bringing their information and their intelligence into the product. Again, I am Gant Laborde. Definitely follow me on Twitter, and definitely I'll look to see who's gonna win a book. And then Infinite Red, we have down there at the bottom, that's Infinite Red's Twitter. And thank you very much.

Thank you so much, Gant, for giving us such insights about Ignite. Thank you so much for putting so much effort into Ignite, because yeah, V8 was amazing, and still is. So we have some time for some questions, but before that, I would like to also ping Jaymon here to come on stage and help us out with some questions as well. You sit closer. You have it. Take the nice chair. We do have some questions from the audience. I just want everybody to know that as I hit the very last slide, this timer right here hit 0, 0, 0. It was like a movie where I'm disarming a bomb, but it was in my head only. None of you got to see the timer. I was so proud of it. So you haven't heard anything on the other track, right? Nothing? So let's start with the first question. So Ben is asking how compatible is Maverick with React Native Web. So we mostly support it through if you're using EXPO. One of the cool things about Ignite version 8, which we're codenaming Maverick, is that you can run it on EXPO with no changes. Before you used to have to choose like dash dash EXPO and then it would only work on EXPO and not work with vanilla kind of React Native CLI. Now it works with both out of the box and so if you want to use it with React Native Web, you really need to use it with EXPO but it works quite well with EXPO.

We're still working on potentially bringing it to more vanilla React Native Web but that's a pretty big job and EXPO has done a great job of getting it to that point. And my two cents on that is that in the original Ignite there was this huge separation between having to choose EXPO or choosing Ignite and we've been working on for a long time the idea of when can we have a lot of the same features and with the advancements that they've done in EXPO I'm really happy it's not a mutually exclusive option anymore.

Yeah EXPO did an amazing job as well. Absolutely. They are pioneering a lot of things.

The next question is, Gant what are the requirements for adding recipes to the cookbook? OK so the system's all under a docusource I think and you're sending, so when you come along what I would do is go to the GitHub for it. You'll be able to link directly to GitHub so ignitecookbook.com it will bring you to the GitHub, then do a small proposal as saying, hey is anybody working on this, is this something I want to do, because we might already have somebody, we're adding stuff constantly, and then say, would this be accepted and just is this something as a piece of it? And you're most likely, I'm going to say 99% unless we're already like rounding the corner on finishing that particular recipe. We will just say, yes, please, that sounds great. Of course, we'll probably have a little bit of a copy pass and the pull request and making sure everything reads properly, renders properly, but adding recipes to it right now is a yes, please.

And can I add? Yes, sure. Sure, go ahead, yeah. Yeah, absolutely. So one of the things I want to mention is that, as Gant said during the talk, in order for things to make it into Ignite, they have to be really, really well vetted by us, by our teams, by our projects, actually go through a project or two or three before we'll actually bring it into Ignite. So anything you see in Ignite is already pretty well vetted and rock solid. We don't want everything to have to go through that rigorous of a process. So the cookbook is a lower bar. It's like, this is something kind of cool. It's an idea. I want to get to, I want to get that information out there. Maybe it's not something that's in every project. So that's where the cookbook comes in. It doesn't have to be Ignite focused. It can be more React Native focused. But generally speaking, it's going to be for an Ignite audience, people who are using Ignite. So kind of keep that in mind when you submit your recipes. Cool. Thank you very much. And I think we have enough time. Yeah, two minutes almost for the last question. Do you have any benchmarks showing the difference between the old and the new React Native architecture? Ooh, that is definitely, yeah.

Yeah, you got it. Yeah, that's good. We're working on it. Oh, that was fast. Okay. So I actually have another question. Also, I just want to say I'm going to give away the book after. I don't have my phone to check the Twitter to do that. So I'll go to the back. And then I'll give the book away after.

Okay, that will be great. So I actually have a personal question. When to use or not to use Ignite? Ooh, that's a great question. I have my opinions. But this will be a different one. Well, this will be two different opinions. You go first. Okay. So when we have a choice, we use Ignite every time. Like for a new project. With the exception of if it's something like a tvOS project or something a little more out there. But for your standard iOS Android project, we're going to use Ignite. It's our best practices. It's how we like to do things. Where we end up not using Ignite is when people come to us with a project that's already started. And since they didn't use Ignite, it's all screwed up. And so we've got to fix it for them. So we're going to make it more like Ignite. That's great. That's more true than you think. And then I'll say specifically that we have this removing the demo, we have a bunch of remove commands that are in there as well. So one feeling I used to have sometimes is, like, you get the whole kitchen sink, and you don't want all of it, or you don't want some piece of it, or something like that. We find that getting a lot of these options, and then removing a piece or removing a large portion of it and still using that structure works well. So in my opinion, even if there was something brand new, and you're like, oh, Ignite's stable and I want to do something crazy, I would probably just take the 90% of the stable stuff and swap out the crazy parts for most of it. So that's a great way to sort of get most of the benefit.

Thank you very much. Unfortunately, we ran out of time, but if you have questions, don't hesitate to go to the speaker's Q&A room or just poke those two amazing and beautiful developers that came all the way from the US.