React Native: 2022 & Beyond

Good morning! All right, perfect. So we have a relaxed just three-hour talk, right? It's talking about react Native 2022 and beyond. Oh, 20 minutes. Okay, I can shorten it. No problem. So you've already heard about me. I'm CIO of Infant Red, published author. Take pictures of me during this presentation and tweet them at me, at Gant Laborde, because 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 Infinite Red, 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 US 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 react Native works, right? We're all adept to this. But 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 that if I don't cover it in this, I know that 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 kind of 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. And so it took this sort of 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. They could have been called anything. A view could have been called a div, albeit I think that's moving backwards in a certain degree. It's always a view and different things. But you have in react Native, you have these sort of higher sort of 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, ta-da, success. Now react Native's 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. I wrote an article, please... Everybody... This is such clickbait, 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, like, 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? Yeah. Oh, I see some pained hands lift. And so... Also, funny thing is, 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. So we're an open source company. So of course I had this one solution. And then back in 2017, I released... 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. And we have tons of success stories that people have shared with us. It's in lots and lots of production apps out there. And it's just kind of nice to have that... People are constantly telling us... Why are you giving all of 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's like... Oh, how are you giving away victory charts? Things like that. How are you giving away Ignite? How are you doing all these things for us? If it read, 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 is solved. 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. As I mentioned earlier, you have react being synchronous and react Native being asynchronous. But now that react 18 is coming in, we actually have functionality to have asynchronous react, and we have the ability to have synchronous react Native. And so this is blowing everybody's minds a little bit. We're coming along with a 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 into all kinds of new functionality, because 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 US 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... What is it? So 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. 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 is... I've always got to update that little icon every time I've got 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. And 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. Because almost all the time, we have to do customized components. And bringing in a library, you hit this 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, 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? It kind of goes 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 could 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 our view, here's the pull request. You can see that number is 2,234, 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're just using our view. You just won't see that problem. You're getting our value there specifically. And 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's wonderful. My personal favorites. 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. So now we're adding this beautiful idea of Ignite Cookbook. And it's free. It's not a published book. It doesn't even make 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 to 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's a pull request on it right now already. So when you take a look at the... 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 its faster startup, decreased memory. 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, Expo Go Android. And then because it's not supported yet, it's not inside of Expo Go iOS. But if you ignite a new app, you get those three. It'll 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. Because we at VentureInn, we're 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 it would follow that as a proof list. And the real big piece of that is TurboModules, because just as a tidbit about TurboModules, as you know, in the original architecture, Native modules had all kinds of issues. Eager initialization. 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 TurboModules, which have a significant set of benefits that are coming in. So obviously, as soon as we can, we will be using TurboModules. I'm pretty sure you'll hear about TurboModules a ton of times. I'm pretty sure some of the speakers coming up have it tattooed. Is that correct? Yeah. So Maverick and TurboModules, do we have that? Kind of. The code's there. 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's 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. We'd love to go ahead and see what kind of recipes, what kind of ideas that you have. Maybe even get you on Jamin's podcast and see if you could 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 pain that we have. And 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 going to go into this? And we have this... There's this motto. It's an old proverb that we like to say, that if you want to go fast, go alone. If you want to go far, go together. And if you're looking for people to make sure that what you're talking about is going to last 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 Pyro and Maniacs 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 going to 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 V8 was amazing, and it still is. It was amazing. I think we have some time for some questions, but before that, I would like to also ping Jamin 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 zero zero zero. 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? No. Nothing good. So let's start with the first question. So Ben is asking how compatible is Maverick with react Native Web? We mostly support it if you're using Expo. So 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 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's 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 that it's not a mutually exclusive option anymore. Yeah, Expo did an amazing job as well. Yeah, absolutely. They are pioneering a lot of things. The next question is, Gant, what are the requirements for adding recipes to the cookbook? Okay, so the system's all under a docusource, I think. 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'll bring you to the GitHub. Then do a small proposal as saying, hey, is anybody working on this? Is this something I can do? Because we might already have somebody. We're adding stuff constantly. And then say, would this be accepted? And just is this something that's a piece of it? And you're most likely, I'm going to say 99%, unless we're already 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 in 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? Yeah, sure. Sure, go ahead. 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. You know, it's like, this is something kind of cool, it's an idea, 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 in Ignite? Ooh, that is definitely, yeah. Yeah, you got it. Yeah, that's good. We're working on it. Oh, that was fast, that was fast, okay. Okay, so I actually have another question if that is... And 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, yeah. 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 kind of out there. But for your standard kind of like 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 make it more like Ignite. That's great, yeah. It'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, and 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 then kind of 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 stuff and I want to do something crazy, I would probably just take the 90% of the stable stuff and swap out the crazy part for most of it. So that's a great way to 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 speakers Q&A room or just poke those two amazing and beautiful developers that came all the way from the US. So once again, just a round of applause for them.