The New React Native Architecture

I'm not going to sit here and pretend react native's always been perfect there are some skeletons in that closet but thankfully the Facebook team recognizes it and they've just rebuilt the vast majority of the react native core to make it significantly faster significantly more scalable and most importantly way easier to plug native code into I want to go over all of this because these changes are huge and fundamentally shift the way we should think about and use react native so let's dive in to everything the react team themselves have to say about the new architecture since 2018 the react native team has been redesigning the core internals of react native to enable developers to create higher quality experiences as of 2024 this version of react native has been proven at scale andwers production apps by meta the term new architecture refers to both the new framework architecture and the work to bring it to the open source world I like they're using new architecture here because with server components we don't have a good word that encompasses everything because server components are like a way to render components on the server and a way to interface them with client components but then there's also server actions and there's also streaming and the new suspense stuff there's a lot of these new Concepts that all fall together under one umbrella that there's no term for wherein the react native World they just straight up said oh this is the new architecture it has like 15 things in it but this is all encompassed under the new architecture I wish we had a term like this for the server side but honestly generally speaking the react native team has been way better at communicating both with their like immediate dedicated users like the react native team talks to a lot of the companies that use react native much more so than the react web team but as such they're much more familiar with how people are understanding these things as they talk about them so a lot of this communication gets cleaned up a ton before it goes public and it's cool to see just I know it's such a small thing but the use of a a term to describe these changes as one thing is really really nice and I wish they did this for react itself anyways the new architecture has been available for experimental optin as of react native 0.68 which by the way they're on 0.73 so it's been a while and it has continued improvements in every subsequent release the team is now working to make this the default experience for the react native open source ecosystem cool to see so many versions since then of them really refining it like this original announcement was in 2022 oh good old Lorenzo he's a legend as I said like react native isn't just within meta the same way like react is Microsoft is an active contributor to react native Amazon has been helping a ton with things like the static Hermes compiler there are lots of companies that aren't meta themselves that are interested in making sure react native succeeds Shopify is another huge one Shopify puts so much effort into making react native go from good to great so this is not just some quick thing they put out this is years of effort possibly like half a decade plus of effort and two plus years since it initially was released now we're seeing them working finally towards making it a default lots of effort lots of dog fooding lots of time put into this if you're wondering how I know so much about these inner workings it's actually pretty simple it was one event I went to last year chain react and I'm thankful to say they're actually sponsoring this video right now at least this bit so I can tell you all about why chain react is hype last year I was blown away I got to Keynote the event I got to talk with all sorts of cool people the food was incredible obviously chain reacts happening again this year from July 17th to 19th and that first day the 17th is dedicated to workshops hosted by infinite red Expo and even Microsoft helping out too but honestly I'm even more excited for the talks this year we're going to hear from everybody from Microsoft to meta to Amazon to Shopify to coinbase and so many more talking about the new architecture for react native the crazy things have done to scale their code bases and just diving deep on all the nerdy details if you enter the code Theo you get 50 bucks off and I get paid so if you can enter that discount code go buy these tickets or better convince your company to buy them for you if you work at a company that's interested in or using react native and if you're not interested in react native there's a code for you too enter Swift at checkout instead and you'll see there's a new option that costs twice as much because building your apps in Swift takes twice as long back to the video but why why make a new architecture in the first place after many years of building with react native the team identified a set of limitations that prevented developers from crafting certain experiences with high polish these limitations were fundamental to the existing design of the framework so the new architecture started as an investment in the future of react native the new architecture unlocks capabilities and improvements that were impossible in the Legacy architectures interesting nobody's better at on react native than the react native team and it's nice seeing them do it and calling out the fundamental limitations that prevent the levels of polish that they wanted people to be able to achieve especially when you consider that react native isn't just targeting mobile anymore it's targeting desktop it's targeting vdr it's targeting consoles like so much of the Xbox interface runs on react native it's crazy they need these things to not just work well but bind well to Native platforms synchronous layouts and effects building adaptive UI experiences often requires measuring the size and position of your views and adjusting the layout today you would use the on layout event to get the layout information of a view and make any adjustments however State updates within the on layout callback May apply after painting the previous render this means that users may see intermediate States or visual jumps between rendering the initial layout and responding to the layout measurements think of this as like I'm resizing my window the browser does a great job of moving things there because react isn't running when when I do that when I resize this window the react code isn't changing anything the react's already run and painted the Dom it's CSS that's doing the shifting on mobile we don't have CSS so when your viewport changes for any of many reasons especially when you're talking about these new environments like VR or game consoles those views might change in size in all sorts of different ways and if you're writing react code to change that UI and change the view as the viewport changes that's going to suck and that's going to be really slow to have react updating every frame to try and render the right content and it's not going to know until the window changes so yeah makes a lot of sense that's the type of thing they want to Target here with the new architecture we can avoid this issue entirely with synchronous access to layout information in properly scheduled updates such that no intermediate state is visible to users let's take a look at this example tool tips everyone's favorite measuring and placing a tool tip above a view allows us to Showcase what synchronous rendering unlocks the tool tip needs to know the position of its Target view to determine where it should render in the current architecture we use on layout to get the measurement of the view and then update the position of the tool tip based on where the view is so this is even just like scrolling it has to call this in order to put the thing in the right place so here we see function view with tool tip Con on layout equals react use call back Target ref and then this on layout call for the view this is what's called when the view changes in any way and in order for this to work they grab the target ref from this change and then they set the re rectangle's position to be the new position based on what they're grabbing from the window here and this has to run on every frame in react that sucks with the new architecture we can use use layout effect to synchronously measure and apply layout updates in a single commit and avoid the visual jump entirely so this is still running within react the difference is that layout effect runs before the render instead of after so this will move the tool tip before the user even sees the change this will effectively block the new frame from displaying which prevents the Jank of the tool tip moving after you scroll if we see the example here when this moves the tool tip moves afterwards in the new version it just moves all at once because the tool tips moving is is blocking the rest of the view sounds bad to block but when you make these types of things synchronous you prevent a ton of potential additional issues somebody said why can't you debounce in chat and you can debounce but then you're going to have the tool tip moving at a different rate from the rest of the view so if you're scrolling up in the view the tool tip's going to stutter based on how much you set the debounce for you can't debounce UI in that way you cannot debounce animations Scrolls all those types of things in that way you can debounce like a fetch call but you can't debounce this so I just saw the code Bas of 26 % Java yeah because react native targets Android and in order to Target a platform you have to write a lot of code for that platform react native writes a really good Android app in Java and a really good IOS app in Objective C they're playing with Swift and they're playing with cotlin but they focus on the technologies that are the most stable that they've been building on forever because I as a react dative developer I'm not writing Java so that's synchronous what about concurrence because blocking is great but parallel is greater the new architecture supports concurrent rendering and features that have shipped in react 18 and Beyond you can now use features like suspense for data fetching transitions other new react apis in your react native codebase further conforming codebases and Concepts between web and Native react development the concurrent renderer also brings out of the box improvements like automatic batching which reduces re renders in react in this example a slider specifies how many tiles to render dragging the slider from 0 to a th000 will fire off a quick succession of State updates and reenders in comparing the renderers for the same code you can visually notice the renderer performance provides a smoother UI with less intermediate UI updates you can see here with the old new when you scroll around this happens almost immediately where this one fills in slowly as all the new updates render I was actually building like a shared music listening experience in react native a while back that had like people moving and such in it and I had to defer most of that animation over to be in like react native reanimated and not within the react native JavaScript site itself because of how much these types of things hurt your performance CU they weren't parallel so this is really cool to see quick look at the code for the sake of it yeah we have all our colors view value is a number and then for all of these we add a view in the views. push and then we render them all and this is the same code used for both you don't even have to change the code it just runs better there's nothing better than you install an update and your existing code just works faster that's so cool I will say react native version upgrades are not the smoothest thing in the world but if you can get to the new version this is huge new concurrent features like transitions give you the power to express the priority of UI Updates this is also really big because some UI updates might be more important than others and it's not easy to tell react hey don't do this until this is done and now it's just built in marking an update is lower priority tells react it can interrupt rendering in order to process things that are higher priority let's take a look at an example here this is using the tile slider again is pending start transition VI text renderer animation is pending slider on value change start transition so because the value change now triggers a transition react knows okay if a transition is happening and a new update calls that calls the same transition I can interrupt that and here yep tiles generate tile views these all take higher priority because they're not wrapped in a transition so you'll notice with the frequent updates in a transition react renders fewer intermediate States because it bails out of the rendering the state as soon as it becomes stale that's the big difference if you don't have a transition for this it won't process the next update until it's finished this one when you wrap it in a transition you were basically saying hey react by the way if this gets called again dump whatever the you were doing before or use this new state instead which is really nice to explicitly tell react hey you can skip that step by the way fast JavaScript and Native interfacing this is honestly what I thought of when I thought of the new architecture and I'm happy they called out at the top that it's a whole umbrella term for a bunch of things because this was what I was thinking of the new architecture removes the asynchronous bridge between JavaScript and Native and replaces it with a JavaScript interface the JSI is huge JSI is an interface that allows JS to hold a reference to a C++ object and vice versa do you guys know how nuts this is you can't even get JavaScript to hold a reference to a JavaScript object having the ability to call a like like have an object in C++ that is shared memory with JS and have that binding native without an async layer transitioning things over the wire this is huge this changes everything as I say with the memory reference you can directly invocate methods without serialization costs nuts so cool just like one of many dumb examples the code for chat on Twitch chat specifically for the colors is sign significantly more complex than one would like to imagine one of the important parts of the twitch colors is that anyone can pick whatever color they want the more important part is that in dark mode or light mode or whatever modes you're using the contrast is high enough for the names to be readable previously that wasn't the case and a common troll people would do is they would change their name color to be really close to the background color of twitch so you couldn't see their name in order to fix that twitch changed the default chat mode and when I say twitch did this I mean one particularly dedicated engineer worked her ass off to fix the chat colors on Twitch to make them read and accessible see this readable color switch if I turn that off i' have to refresh seems like nobody's colors are off enough to be hard to read but if somebody had a dark enough color and I turned this switch off it would be very hard to read their name the math they did to make that color thing work is why I'm bringing it up though because they wanted to make sure the colors matched across all platforms so I need to make sure on desktop on iOS and on Android that the colors are the same and any math I'm using to transform the color based on your color schema needs to be consistent the only language that they could find at the time that let them apply the math to transform the colors consistently was C++ so the code that actually takes the chat color and transitions it to the color that looks right for your display regardless of your platform it's the same code written in C+ plus as insane as that sounds and I believe me I was weird out when I first heard it that justification of we want the colors to match everywhere and the only way we can guarantee that is a language we implemented the math of that was crazy and I have a ton of respect for them for doing that writing the bindings to get that C++ code into the Android app was not fun they did it but it wasn't fun now that's just a feature built into react native you can just call a C++ object or a C++ function whatever you want and it just works so as much as I don't want to write C++ code the idea that someone could write some really complex math in C++ and I just have access to it in react native that's crazy and I love that let's see how they actually use this though cuz it's cool as it sounds I want to see their recommendations JSI enables the vision camera a popular camera library for react native and it can now process frames in real time typical frame buffers are 10 megabytes which amounts to roughly a gig of data per second this might sound insane but as someone who shoots in 4k the stream that I'm recording right now is going to be 6 to 7 hours that's going to be about 500 GB of content these sizes make a lot of sense especially when you're not compressing like my camera footage is compressed that was uncompressed each frame is insane and if you want to know more about frame compression I have a whole video about how h264 Works come in very soon if it's not out already YouTube search Theo h264 and hopefully a video comes out by the time this is out anyways that's a shitload of data and when you're getting it straight out of the frame buffer it's going to be full size depending on the frame rate especially like it gets worse if you do like 60 or 120 or any other frame rates or increase the resolution there the the data you get from the frame buffer from the camera is nuts I I God I'm trying my best to not do a long rant about cameras in multiplat stuff because I could like I could do an hourong tangent about the Snapchat camera on Android what I will say is that the camera Bindings that exist for these platforms like in the case of Android the Android camera SDK was so atrocious and so slow and inconsistent that in order for the Snapchat team to add a good experience where you could do like the sliding to and from the camera part they didn't use the camera SDK they used the camera viewfinder SDK which was meant to be used to give you like a little preview of what the camera was doing that didn't require pulling shutter for every single frame and it looked awful and rather than when you click the picture button telling the camera C hey take a picture and send it back to me they would literally take a screenshot of the like viewfinder SDK hilarious that's why Android Snapchat and also Android Instagram for a long time looked so because the camera SDK on Android was so it was the only option they had but now that we have native bindings here and awesome stuff like vision camera as well as the Android SDK getting a little bit more viable we don't have as many of those problems anymore I think Snapchat might still be the case like that on certain phones I think the pixel line generally has better SDK support but that I could literally R about that for ever I'm so sorry for the tangent back to react native in comparison with the serialization costs of the bridge JSI handles that amount of interfacing data with ease JSI can expose other complex instance-based types such as databases images audio samples Etc why would you ever want to expose a database like this I can think of a lot of reasons one of my favorites that I pulled up on stream earlier project light speed which if you're not familiar was the rewrite of the Facebook Messenger app Rewritten in of all things sqlite yes the UI is powered by dynamic sqlite templat because much like C++ sqlite's one of those tools that is basically identical and really performant on literally every single platform so if they write everything in the SQL light binding it works everywhere and it's crazy how these other things we've invented to try and make truly multiplatform code basis experiences and consistency like C++ color math or craziness here with SQL light as your UI layer these are all the things companies like Facebook invented in hopes of making things consistent across platforms now we just have it built into rea act native so if you want to use something like databases in your react native code performant with a native database running in C++ land just built in now so cool JSI adoption in the new architecture removes this class of serialization work from all Native JavaScript interal this includes initializing and rendering native core components like a view or a text element this is huge not having to go through the async layer just to update a text component huge you can read more about our investigation into rendering performance in the new architecture and also the improved benchmarks that they measured a 1500 view component went from 282 to 258 so slightly faster 5,000 still just slightly faster this is also on a pixel 4 if we look at an iPhone 12 though we see a much bigger jump here because oh God I'm going to get in trouble for this one uh since Android's already written in a pretty big abstraction javascript's not a massive cost on top and the pixel 4 when did the pixel 4 come out 2019 iPhone 12 release date okay the iPhone 12's a year newer but like a one-year difference between these phones even like the old react native architecture was twice as fast as the new one like Android's just a little rough Java's not the right thing to write your operting system in and that's why we're like the base performance possible on Android is because it's so gimped by architectural decisions I'm not saying Android itself is bad and terrible and you shouldn't ever use it I'm just saying it's fundamentally flawed and cannot ever perform as well as iOS just cannot do it due to the way they obstructed the like language and had to reinvent Java to make it perform at all the difference here is roughly the same as here it's about like 22 is 24 milliseconds here it's almost identical difference the key is that the base potential performance on iOS is so much higher that the percentage difference is bigger so yeah Android slow hopefully not news to most of you flame me in the comments I know you're going to but uh yeah what happens here is like no I don't I'm not going to say the flutter word I'm not going to say the only reason flutter is acceptable is because Android is already so slow that the abstraction doesn't matter I'm not going to go on that tangent I'm just going to say that iOS apps and iOS users have a certain expectation of performance on their device and that expectation comes from how fast iOS can be at doing all sorts of crazy and what I'm excited about when I look here is that react native now performs significantly closer to what iOS users expect from their applications this is really cool to see they call out a section where you can go learn more a bunch of updates to the document as well as the working group I love that they've been doing these working groups too where there's like a place where people who are deep in the weeds for these new things can go and talk and play with them I know like nille was deep in the working group for Server component stuff and ended up building the tools you need to make your own react server component framework I know that somebody like uh Dai who built waku and also built Jodi and maintain Susan and a bunch of other stuff he's part of the react working group as well in order to talk about these new things it's really cool seeing the meta react communities as a whole embracing community in this way it's been a huge shift from not just how I think of react but how I think of web Frameworks as a whole it's really cool to see so what can we actually expect from enabling this new architecture well the new architecture enables these features and improvements enabling the new architecture for your app or Library may not immediately improve the performance or the user experience for example your code May needs some refactoring to leverage new capabilities like the synchronous layout effects or concurrent features although JSI will minimize this overhead between the JS and Native memory data serialization may not have been a bottleneck for your apps performance in the first place this is also an important thing like if you're just rendering views with a bunch of stuff in them serialization between the native layer and the like react native layer probably isn't the problem you're having and there's a lot of other things you can do to improve performance for that stuff too like flash list which I don't talk about enough flash list is a new list component written to make your lists that are really long with a ton of data perform much better in react native and it is a huge win the FPS you can get on a giant list of flash list versus the built-in flat list in react native is hilarious in the UI thread it's up to 5x but in the JS thread 10x plus and this is on an Android Moto G10 so they're testing it in like the worst possible scenario too this is such a phenomenal update and I'm so happy that this exists also big part of how I learned about this was hanging out with the guy who built it when I was at chain react and I watched one of my favorite talks I've ever seen yes this talk default to Performance from chain react last year was incredible phenomenal talk about how performance happened at Shopify with react native and all the things they did to make it possible and it has 100 views that's insulting I'm going to put a link to this in the description of the video so you can check it out if you haven't and you're curious cuz it was such a good talk and before someone says it well if you wrote that code in Native it wouldn't be slow let me tell you something see this button here this is for the library of all my downloads in Arc which was written in Swift I don't know if you guys can see that there that is some noticeable lag and it was way worse before they've had to rewrite this component like five times in order to make this list work at all and it it still chugs when I scroll it is hilarious how bad long lists perform in Swift by default without you building your own list primitive so yeah write in in Native except the native code sucks too flash list fixed all of that for all different platforms that you might Target they did the hard Swift code and the hard Java Android code so that you can just write nice basic boring react code like this is how you render a list that performs well in react native now that's it should be that easy should always have been that easy one more important call out from Evan here very worth pointing out is that the new architecture is actually required for building server components in react native things like use suspense and youth transition they just don't work without the new architecture and how it changes the threading model within react native which is huge and very important especially now that I'm predicting over the next couple years react native devs are going to slowly become full stack the same way react web devs are becoming full stack with tools like next I already have a video talking about mobile devs hate servers Expo wants to fix that where Expo is working very hard to slowly push people in the direction of react native and server code and the relationship between those things anyways enabling the new architecture in your app or library is opting into the future of react native I like that nice call out and I personally like opting into the new future when I have the opportunity to experiment with and really use these new things but over 2 years of release later and a ton of iteration in dog fooding this isn't that experimental anymore the team's actively researching and developing new capabilities that the new architecture unlocks for example web alignment is an active area of exploration at meta that will ship to the react native open source ecosystem I've talked about this a little bit especially like the conformance stuff if you guys have seen my video on uh react next big change is the react strid they're not going to force everyone to use strict they might not even go with it long term but the goal of strid was to make it so you could write code that is reusable as like one code base on iOS Android other platforms and web by abstracting enough of The Primitives that it can be applied correctly in these different platforms because there's no such thing as a div on Android or iOS unless you're under web view which then sucks so all of these types of things are work in order to make fully sharable and repurposable building blocks for react across all the places you can use react code this includes the changes to the event Loop model they're working on node and layout apis that are making things more consistent Dom traversal stuff like that layout conformant stuff and the chaos that is yoga if you're not familiar with yoga it's tldr it's how things like flexbox work in Native really really cool stuff I've even seen people using yoga outside of react native but like flexbox and GAP and all these crazy behaviors that we expect from the web only work in react native because yoga is built to make a flexible pun intended UI layer so enough about what it is should we actually use this new architecture today well today the new architecture is considered experimental still and we continue to refine backwards compatibility for a better adoption experience the team plans to enable the new architecture by default in an upcoming react native release by the end of 2024 our guidance is as follows for most production apps we do not recommend enabling the new architecture today waiting for the official release will offer the best experience imagine if they said this with something like nextjs when it came out I don't know how much stress this would have avoided but it would have been some amount it would also have hampered the hype which might not have been worth it but react native is not trying to Hype us up here they're not trying to shout from the rooftops everyone used this now they're trying to show us what the future looks like and I like that they're calling out that you shouldn't adopt this for real production apps or at least they're not recommending it I know I'm going to be using this if I build the react native out because that's just who I am as a person but they're giving an easy out to people who aren't sure because I know a lot of people don't want to ship Pages router on next today because app router is the hot new thing it's fine to ship Pages router it's still more stable it still has great support from everything and they're not going to get rid of it anytime soon the old architecture react native it's the same deal but they're communicated differently also calls out that if you maintain a react native Library they do recommend enabling it and verifying that your use cases are covered you can find instructions to that here this is also really cool because I know a lot of the complaints around server components have been the lack of resources for library maintainers in order to adopt these things cool they have a whole section here a place to chat about third party libraries in their migration story to the new architecture this is the react working group react native New architecture repo and here's the community for discussion you can talk about these things really cool to see this type of opportunity for anyone that's building reac native tools and Technologies to communicate with the team what a read I love talking about react native I need more opportunities to ship it but haven't had too many as of late just building everything for the web but when all this stuff ships it'll be easier than ever to share that web code with mobile code and make a great experience for everyone curious what you guys think about the new architecture is this going to finally shut up the flutter people or is this nothing interesting to you at all let me know in the comments until next time peace nerds

Channel: Theo - t3․gg

Views: 130,514

Keywords: web development, full stack, typescript, javascript, react, programming, programmer, theo, t3 stack, t3, t3.gg, t3dotgg

Id: BdPkVl4Y8TQ

Length: 25min 58sec (1558 seconds)

Published: Thu Mar 21 2024