Fetch Once, Render Everywhere: React Server Components in Expo Router with Evan Bacon
===

Paige: [00:00:00] Hi, and welcome to pod rocket, a web development podcast brought to you by log rocket. Log rocket provides AI first session replay and analytics, which surface the UX and technical issues impacting user experience.

Start understanding where your customers are struggling by trying it for free at log rocket. com. Hey everyone, I am Paige Niedringhaus, I am your podcast host for today, and we have Evan Bacon, artist and technologist here to talk about his talk that he just gave, Fetch Once, ~Render Anywhere, ~Render Everywhere, React Server Components and Expo Router.

Welcome to the show, Evan.

Evan: Hey, Paige. Yeah. Thanks so much for having me.

Paige: Absolutely, we are very excited to have you on. ~Um, ~so let's just dive right into it. You talk about React Native, and you start off in your talk saying that it started with the concept of web the good parts. ~So, ~how has this initial premise evolved over the last decade, especially considering the major impact on mobile development for today?

~Mm~

Evan: people were [00:01:00] not doing compositional declarative reactive UIs for native, like not like they're doing today, where it's basically the way everything is done. ~Uh, ~it was a lot of imperative C or Java calls to draw to the screen.

~So, you know, ~that, that was ~a lot of, ~a lot of good parts from the web. ~Um, ~but yeah, the web has a lot to offer there. There's, and it's changing all the time, lots of great stuff, ~you know?~ So, ~you know, ~now there's things like API routes are very common, having some sort of backend for front end, the ability to, ~you know, ~just really tie data to your UI, but I think ~the, the, ~the biggest.

overarching thing with the web is iteration speed and the ability to just~ get, ~get your idea into the hands of users as quickly as possible. And so that's something that we're always striving to bring to native.

Paige: That's fantastic. So can you walk us through some of the architecture for Expo Router? How does it manage the differences between the web and the native navigation under the hood? You know, depending on ~what,~ what [00:02:00] screen size and what device you're working with.

Evan: Yeah, good question. ~Uh, ~so,~ uh, ~for those who don't know, ExpoRouter is a universal file based framework. It's the first file based framework for native apps, as far as I know. And so it kind of works like Remix or Next. js or PHP, depending on how far back you want to go. You can add files into an app directory.

And then if you export some default React component, then you can navigate to it. ~Uh, ~so this is something that was very tricky to get working right on native because native just has very complex patterns. You need things like nested layouts. ~Uh, ~you need groups, the ability to present. ~You know, ~the same URL in parallel across different, ~you know, ~sections of the app.

~Um, ~so you think about ~like ~the Twitter app, how you can show a tweet on one route, and then maybe you could switch over to your profile or the search tab and show that same tweet. ~Um, ~you need the ability to express that in a file based system, very tricky. ~Uh, ~so.~ You know, ~there's really no reason that the web doesn't do these things.

I think it's just as an optimization, you're able to get away with not really [00:03:00] having that all the time. like, if you, for instance, go to the X. com or the Twitter website, wherever, and you,~ uh,~ try to do a lot of the same navigation, cause they look very identical. ~Um, ~you'll notice that it doesn't actually preserve, ~you know, ~like stack history.

If you click on a tab, it will reset you to the top of that tab. So if I, ~you know, ~click on search, go down, drill down somewhere, click Profile and click back to search. It'll be on the search page. So a native, they, ~you know, ~since there's no tab bar, there's no ability to create multiple instances of the Twitter app.

They use ~these, ~these stack of patterns to,~ uh, you know, kind of ~have some dynamic version of multiple tabs,~ um, ~less important on the web. So what this means overall is that ~you, we can, uh, you know, we can just, there's, ~there's no reason that it doesn't exist on web. I think it was just like client history.

~Uh, you know, ~it's just some object. So ~we, ~we try to make everything work as close everywhere. And then if you want to, you can, ~you know, ~just ~kind of ~fork at the layout level and say, when I'm rendering for web, it renders this way. And when I'm running for native, it renders this other way. ~Uh, ~the layout is actually usually the thing that is pretty different across platforms.

So a file based nested [00:04:00] structure actually lends itself really nicely to code sharing.

Paige: Very interesting. ~So,~

Evan: I feel like I did a lot of buildup to this and then maybe missed the original question.

Paige: No, I think that you did a great job because it's very much about the architecture and, ~you know, ~that's something that I don't think I even realize because I don't build mobile apps a lot is that the things that I ~kind of ~take for granted when I'm using a mobile app are not the way that you would typically build it when you're building a web app, because I.

~You know, ~we don't have gestures, we don't have swiping, we don't have the option to have multiple tabs open of different pages or different routes within the same application. ~I never,~

Evan: be really cool if you did.

Paige: it would be very cool if we did. Maybe that's something that Expo can support for the future.

Evan: ~Um, ~yeah,~ uh,~ so maybe one key difference between exporouter and standard react native frameworks and just react native in general is that exporouter is universal first as opposed to native first. ~So, ~um,~ you know, ~it's somewhere [00:05:00] between approaching app development from like a web first or a native first, but really it's like you think in terms of.

~Uh, I mean, ~I render text to the screen and this text should run the same way everywhere. So if your interpretation of how to do that is to use web based approaches and primitives, then exporouter needs to accommodate that. ~Um, ~whereas in the react native world, it's more like, all right, here is this. It's got its whole own world.

Everything's very like quasi native. ~Um, ~and yeah, that, that is fantastic for native development, right? Native is number one cross platform framework in the iOS app store. ~Uh, ~but,~ uh, for approaching the, the wider, you know, for, ~for delivering on this promise of react for native,~ uh,~ it needs to~ like ~lean more into the.

React DOM space ~and, ~and how the web works,~ uh,~ which I think we've captured a lot of.

Paige: Yeah. ~Well, ~Expo ~was ~recently, became the recommended framework for doing React Native apps. Is that correct?

Evan: ~Uh, ~yeah, so React Native has shifted,~ uh,~ in this similar direction to React,~ uh,~ [00:06:00] DOM, React proper, whatever,~ uh,~ where recommend a framework by default for development. Now in ~the, ~the web space, this is maybe a bit more controversial because You can just use react dom as is, and it's fine,~ uh,~ but in the react native space, there, there's just so many problems that you need to account for and solve, like authentication and code signing, and even things like upgrading and dependency management.

All these are very difficult. ~Um, ~so yeah,~ uh,~ Expo is currently the, is the recommended way to, to build a react native app. ~Um, ~but more so than that, using a framework is the recommended,~ uh,~ system. ~So, you know, if, ~if there are other frameworks that emerge and,~ uh,~ have, ~you know, ~new and innovative ideas, then those would also ~kind of ~fall into ~this, ~this category recommended way to use React Native.

Paige: ~So, ~going a little bit deeper into Expo and Expo Router, how does it handle state management across different platforms? And can you just describe a little bit more,~ like,~ what that might look like for a user or for a developer?

Evan: Yeah. ~So, ~yeah, state management is often handled by ~like ~React or some sort of other,~ uh,~ tool, [00:07:00] like maybe ZooStand or,~ uh,~ Jotai. ~Um, ~those are maybe the two that I like. ~Um, ~And those are completely universal. So they right once run everywhere. ~Um, ~and yeah, all the same things that you have a context and providers, all that works the same with expo.

You can use experimentally react 19. And ~um, ~so if you want to use the new context format, you can.~ Um, ~but yeah, generally you try to keep the state the same across all platforms. ~Um, ~And if you can help it because, ~you know, ~if you think about like how you connect a database or back end to a front end or a client,~ uh,~ there's various trade offs, like maybe people will try to really front load ~the, ~the back end and then have it, ~you know, ~control and manage all the state and then have the client be some loose shell.

~Um, ~and, ~you know, ~just in the way that the web works, where you try not to report a lot about like ~the, ~the device to the back end. I think a lot of that bleeds into native. So generally the state is usually very universal and it's just how you display and render that data where things start to fork and get more native [00:08:00] specific.

Paige: Okay.

Evan: to that, ~you know, ~as we try to build a more perfect universal system, The goal is to make the front end easier to, ~you know, ~fork and branch out and become more platform specific while,~ uh,~ preserving,~ uh,~ as much of the dev tooling and the deployment and the state management as we can across platforms.

Paige: ~Mm hmm. ~So you mentioned Jotai and Zushand, are those two of the libraries that you would recommend for doing state management? Or ~would you, you know, ~would you still do something like Redux or Redux Toolkit in this day and age?

Evan: ~Um, yeah, yeah. ~I think ~they're, ~they're all fantastic. ~Um, you know, ~MobX,~ uh, ~state trees also, I've heard really great things about. ~Um, ~I just, I personally use those because ~the, ~the author. ~Um, ~who may like Waku, I think he's really talented. ~Um, ~so ~I, ~I tend to follow ~his, ~his work pretty closely.

Paige: Fair enough. Alright, so could you explain how React server components are implemented within the Expo router? Which I think is a question that many developers still have today as we try and wrap our heads around RSCs in general. ~Mm~

Evan: ~fantastic. So, um, ~they currently are not implemented in Xperator. ~Um, I'm, ~I'm [00:09:00] actively developing them. ~Um, ~there is a branch that's open currently, which has, ~you know, ~the, renderer. ~Um, ~so today. As of Expo SDK 51, all the native parts for the most part,~ uh,~ are landed. So we have the new architecture, which is required.

It has ~like ~the synchronous render that is required in React to make server components work and to use things like the use hook. ~Um, ~then the ability to use React 1918 is landed.~ Um, but the. ~And then also ~the, ~the file based router is out there and that is a very important part. ~Um, you know, ~since the beginning, ~my, ~my goal with Exporouter was to create a framework which could leverage,~ uh, ~server components universally.

~Um, and, ~and so a lot of what is required is currently present in Exporouter. ~Um, ~but the server renderer. So the part where we,~ um, you know, ~create multiple different bundles for each server platform, then we render out to a RSC payload, and then we send that down to a new concurrent router, those parts are,~ uh, ~still ~in, ~in Draft PR.

~Um, But yeah, and then like, ~one thing that's really exciting about them is if you think about how web only frameworks have functioned [00:10:00] historically,~ they, ~they have all these things where they kind of sidestep react. ~Uh, ~so if ~you, ~you think about like maybe old school Next. js, where they have like, ~get, you know, state from whatever, like get, ~get server side props and get static props, all that.

Yeah. ~Um, ~A lot of that functionality has now been folded into React,~ um,~ with server components. And by being in React, it means that it can now be universal and can apply to any platform. ~Um, ~and so,~ a~ lot of the parts that needed to change,~ uh,~ exist currently in Expo Router. ~Um, ~and then what is really exciting is that we can then just kind of use React as is, ~so ~verbatim.

So we're using, you know, React server webpack. verbatim react verbatim in order to create ~the, ~the flights. ~Um, ~and then we have,~ uh, you know, ~very custom bundler stack,~ uh,~ which is based on Metro, which is based on Meta's internal like bundling system called make haste or whatever. ~Um, ~and. Yes. ~Uh, ~so we've had to change a few things, but I actually think a lot of developers have already,~ uh,~ who are using Exporouter have already made the changes required to,~ um,~ to access server components.

~Um, ~and then [00:11:00] in terms of architecture,~ um, The, ~the magic was really in getting it to work,~ um,~ almost as close to the web as we possibly could took a lot of shoehorning, but we were able ~to, ~to get it in there and in lots of like little different ways. So one really novel approach,~ um,~ is when. For instance, an iOS app makes a server component request to ~the, the, ~the react server,~ uh,~ environment.

~Um, ~it sends up headers, which indicate like this is the version of the iOS app, and this is, it is an iOS app. And then we have a iOS specific bundle of the server environment, which then renders out the application. So this means you can have a. Universal server where you can do things like render view image and text.

~Um, ~but then it knows, ~you know, ~to resolve like dot iOS and dot native extensions,~ um, you know, ~look for things like if you have ~some, ~some sort of forking function or like if platform is iOS,~ um,~ then it automatically is able to render for iOS. So you, you have ~like ~a multi platform,~ uh,~ server as well as a multi platform client.

~Um, ~and yeah, I think those are maybe the aspects that make it kind of unique. [00:12:00] And. In addition to that, one thing that makes this a pretty tricky problem is having a hosting environment, which can support. ~Um, you know, ~different versions of an app simultaneously, different platforms simultaneously, and then report.

Yeah. Cause it's not just like getting that handshake to work, but also there's like, if you think about how hard it might be to get error reports or stack traces for your server. Now ~like ~scale that out on multiple different dimensions across,~ uh,~ it becomes an even harder problem.

Paige: Yeah, that's not an easy problem. You're trying to solve for. Wow.

Evan: know, makes it worth all the,~ uh, the ~turmoil, ~ um,~ cause yeah, I'm frankly, I'm very excited to see what people build with RSC, just the stuff that we're able to prototype and build. ~Like, uh, ~I had this talk at React Conf and a few other places, like AppJS Conf,~ uh, ~where I showed off this AI app that I built,~ uh, ~with React server components, ~and it only.~

I think I made like the first version of it in like maybe six hours, just ~like, like ~one day or something. [00:13:00] Um, in my mind, we're just being blown,~ like, you know, ~being able to render native UI in the server and stream it down and have it be interactive. ~And, um, ~it really that granularity and ability to switch back and forth that makes it really magical.

And I think there's still a lot more magic to be accessed as well. Sorry, you were saying?

Paige: No, ~I mean, ~I would love to hear more about that. ~Like, talk, ~can you talk a little bit more about why RSCs make AI functionalities easier to build in mobile apps?

Evan: Yeah. ~Um, so. Thank you. You're welcome. Yeah, with, um,~ with AI applications,~ uh, you know, ~at least at the time when I made the thing, there was not a lot of, ~you know, ~local LLM running. ~Uh,~

Paige: ~Mm hmm.~

Evan: now we're seeing that like with,~ uh,~ Gemini, Nano or whatever, anyway, that there will be some version of LLM that runs locally.

~Um, ~but historically, if you want to. Interact with an LM you need to just make a lot of server round trips and on top of that You also need to be doing streaming and like streaming and data and rendering it as it's coming in The web is fantastic at those two things because the web is it has streaming built in and it always comes from a server [00:14:00] Native is ~the ~the opposite.

And so we've had to build a system which makes it work more like the web,~ um,~ but still allows you to do things that are, ~you know, ~very local first ~and, and, ~and friendly to a native environment. ~Um, ~and then on the web, there's, ~you know, ~this well defined backwards compatible set of UI primitives. So think like the Dom, you have like divs and image tags and tech, like these never change.

~Um, ~whereas a native,~ they,~ they're that no such thing. ~So, um, ~with RSC. What you effectively get with use client and use server and expose version of RSC specifically is a system where you're almost like the bundler is magically defining these element tags as you're writing the app. So you are, if you look up like server driven UI, you'll see a ton of different companies and how they've implemented server driven UI.

And at some point they'll talk about how they've had to create this standard and how difficult it was. ~Um, ~With expose RSC, it is automatically generating that standard for you as you're writing the app by using things like [00:15:00] use client and use server.

Paige: ~Okay.~

Evan: so ~the, ~the payload, the RSC flight format is part of that.

But then by adding use client, you are effectively saying, all right, This is an element that must be fetched and then downloaded and evaluated before we can continue recursing through the tree and rendering the app. ~Um, ~so a lot of that Bundler magic is what makes this really fantastic. It's actually ~a ~very little to do with AI.

~Um, ~but if there was any other feature in the future, ~like ~if we had done this. ~You know, ~maybe a year ago or something when there was tons and tons of activity in crypto, this would have been the best way to build a crypto thing. And I actually think we're at native in general was the best way to build a crypto app, but they'll sort of made it even better because really just anything where you're connecting with people over the free and open web, building some service where,~ uh, you know, ~servers are involved and you have your own computers.

~Um, ~then yeah, being able to dictate the contents of the application remotely is very important.

Paige: Interesting. Okay, so ~let's, ~let's talk a little bit more about,~ uh,~ Expo Atlas,~ uh, ~because I believe that you touched on that briefly [00:16:00] in your talk. So maybe you could just give people an overview of what it is, and then we could talk about some of the optimization strategies that developers can use if they choose ~to, ~to implement Expo Atlas.

Evan: ~Yeah, so ~yeah, as I've been talking about here, ~there, ~this feature is very dependent on the bundler doing a ton of magic. And so we've built very custom, very complicated bundler stack. We have a multi dimensional bundler, which can fire off new dimensions at will. Everything is,~ um, ~bundled on demand. So you can, ~you know, ~start at any file and bundle all the way down the tree.

~Um, it's very, uh, ~ It is architected for very complex applications across large teams that are working simultaneously across different platforms. And what that leads to,~ uh, ~is a bundling system that's very hard to debug and make sense of. So as we were building, the RSC project, we realized this is going to be tricky.

~So started, uh, ~we started building this thing, which is kind of like the idea was to have something like yarn Y or NPM explain,~ uh, ~where you could just say like, why is this module inside of my [00:17:00] bundle? ~Um, ~but with the bundle, ~you know, ~there's lots of different config parameters, which can change why something is included.

So, created this web,~ uh, ~dev tool, which is kind of like a source map explorer, except you could click on ~a, uh, ~a block and then it would show you the input source and the output source. ~And ~then you could crawl up and down the dependency tree to see, ~like, ~why that module was included or ~you know, ~what includes other modules.

~Um, ~so really just to answer a lot of ~these, ~these,~ um,~ developing ~questions. This is~ complex bundler questions. So that was, you can also switch between different bundles and you can use it live because I never loved it. Like when you're using a source, have explore you to export the app and then you can look through it.

So you, it will update with the HMR of the bundler. ~Um, ~so if you change something, you can see like why it was included or disincluded,~ um,~ And yeah,~ uh,~ so just magic bundler tooling that we were using internally, and then we decided to release it externally because,~ uh,~ just having a lot of,~ um, uh, ~we're just able to move a lot faster when using it.

Paige: Yeah, ~I mean, ~developers always want to debug and understand why their apps are doing what they're doing anyway. So just giving them this tool seems like a [00:18:00] nice addition for the community to have at their fingertips.

Evan: Yeah. But simultaneously it's ~like, if, ~if you were coming from ~a, ~a different development stack and it was like, all right, in order to use this tool, you need the source map explorer because the bundling is complicated. It'd be kind of a. Kind of a letdown. ~Um, ~so it's very much optional and it's more for advanced use cases.

~Um, you know, ~I wouldn't lean too hard into over optimizing your bundle until you have something that people really like and that has been deployed and that you have users for. ~Um, ~it's just, ~you know, ~some words of warning. I find it personally very addictive to like, Oh, look at the number go down. ~Um, ~but yeah,

Paige: like trying to get your perfect lighthouse score. Everybody always goes for it.

Evan: Exactly. ~So why don't we do something like that before people, you know, build ~the key is to make something successful and make, ~you know, ~the world around you a better place.

Paige: Yeah. Do you have any examples of where using Atlas has really helped to improve performance for apps?

Evan: ~Um, yeah, so. ~With Expo Router being very focused on universal, we have a lot of interest in Expo deploying to the web. And so historically [00:19:00] the bundle size just hasn't mattered that much because when we deploy to native, we can use the Hermes engine, which can memory map your bundle instantly. So you can have a massive bundle.

Your app still starts up super fast. But,~ You know, ~there still are issues with bundle size, especially if you're doing OTA updates where you want to keep your bundle as slim as possible, faster network requests. ~Um, ~and so when working with some of our larger users, we have been looking into adding stuff like tree shaking.

So for instance, I said, we, we, when we bundle, we do everything on demand first. ~Um, ~so ~this, ~this architecture is really fast and snappy in development, but it's not fantastic for production applications. ~So. You know, ~like a lot of other bundlers, what they'll do is they'll bundle everything together, and then they'll split it up, and then they'll just send chunks down.

~Um, ~and that's great for production, because you have everything together, and you can like,~ uh,~ minify it. ~Um, ~but not fantastic for development, where maybe you want to just arbitrarily access any piece of code. ~Um, ~so with 52, we will actually be releasing a,~ uh,~ experimental version of tree shaking, which introduces a new architecture for [00:20:00] our bundler,~ um,~ which Preserves everything in memory and then performs optimizations in the serializer at the end.

~Um, ~and ~The, you know, ~the default state of tree shaking is to ensure that your bundle is never malformed, you know, ensure always working because like tree shaking runs in production. It's a bit slower. ~You know, ~it does lots of recursions into your AST. ~Um, ~and you really don't want your production bundle to fail because it's also minified.

There's fewer dev tools. There's ideally no dev tools inside of your production bundle. So if it breaks, it breaks very cryptically. And when I was developing our tree shaking, I realized that What we would need is some dev tooling like Atlas to help introspect, ~you know, ~why,~ um,~ a module is included basically in order to ensure that your bundle is never malformed.

If there's something that maybe could be removed, but it's not certain that it needs to leave it in. And so having the ability to, ~you know, ~understand why tree shaking failed is almost as important, if not more important than tree shaking on its [00:21:00] own.

Paige: Do

Evan: maybe about as important if not more than tree shaking ~um ~but with 52 we will experimentally ~have ~have both so User should get the best of both worlds and it will work across all platforms the same way.

Paige: you have any timelines for when 52 might be out there for people to start using? Yeah.

Evan: out in September Yeah, should be exciting. We should probably also have ~the first like ~the ability to do a single component RSC handshake Behind a bunch of experimental flags because you have to turn on like right 19 and new architecture And so ~like ~all the flags will be out and we are actively working on folding them in and making them the default.

~Um, ~but people will be able to turn them on and then try RSC, which will help for migrating libraries over to [00:22:00] RSC. ~Um, you know, ~adding the right use client directives. ~Um, ~let's see. And then what else will we have? We'll have some RSC, we'll have some tree shaking. Oh, and then another thing, which ~I'll, ~I'll probably announce,~ uh, ~later,~ um, ~which will just help a lot more for migrating incrementally from web over to native,~ um,~ so you should ~be ~some mechanism.

Inside of Expo where you could just take your website and then just run it on native and then incrementally move it step by step component by component over to native. ~Um, ~so that you can truly feel like react on native as it lives up to its name.

Paige: mods or just documentation for how people can get started with, ~you know, ~the things that are locked behind feature flags or just Updating their own architecture so that it's ready for the new features that you're adding.

Evan: Yeah. ~Uh, ~so using exporouter is number one key to, so ~like ~if you migrate, we have some docs on how to migrate over to exporouter from,~ um, you know, ~other stacks. And if you're on exporouter, that is number one thing that will help you be ready for RSC. Then we're also going to be [00:23:00] releasing a change to our Jest preset.

So we use Jest Expo. And it will have RSC testing built in, which is pretty sweet. So it will be able to evaluate and run your components in an RSC, a pseudo RSC environment. Which will be fantastic. So you can, if you're writing a react native component or anything universal, it could even just be a regular react component.

You can import it here and it's got like some custom snapshot ~master~ matcher. So you could do like, you know, expect then like JSX and then to like match flight snapshot, and then it will render it out to a flight and then you can compare it to the snapshot, which is pretty sweet. ~Um, ~so when that comes out in 52, people will be able to pull that in and then see if their libraries support RFC correctly or

Paige: Mm hmm.~ Mm hmm.~

Evan: ~um, ~which will be fantastic because, ~you know, ~there's so many targets here and there's so much to look at and think about and focus on that if you just hop in and you're trying to ~like ~fix some Android bug,~ uh,~ you're not thinking about every possible use of your super isomorphic react code.

~Um, ~so having some really fast tests, I [00:24:00] think will ~make, ~make things really fly.

Paige: Absolutely. So one of the questions that I always wonder about is how flexible is ExpoRouter when it comes to things like customizing, navigation transitions and animations? Things that are just so central to any sort of React or any sort of native application. ~Um, ~are there hooks? Are there APIs? Are there other things that kind of make this a little bit easier or more natural?

Evan: Yeah. ~Yeah. Uh, so. ~Expo router is built on this library, react navigation,~ uh, ~which we worked on at expo and ~what, ~whatever is possible in right. Navigation is possible on expert router. Um, but we are finding that, ~you know, ~with right navigation, it does have this more dynamic,~ uh, ~ routing system. So you can, ~you know, ~arbitrarily at runtime, add new stacks and screens and such.

~Um, ~which means that when you go to customize a stack, you kind of need to account for all of the routing information. Whereas like XBOR router,~ uh, ~everything is statically defined in the file system. So you can have simpler components, which can [00:25:00] intrinsically,~ uh, ~determine how routing should work. ~Um, ~so there's a fair amount of customization right now, but I think.

~Okay. ~There's ~uh, ~room for a lot more. We are working on ~some, ~some headless. ~Um, ~navigation components now, which will be, ~you know, ~like maybe a tab bar where you can then go in and you have ~kind of ~a radix UI style API, where you can just define like tab, tab, tab. And if you want to hide something or remove it and just don't define the component.

~Um, and yeah, yeah, ~overall, I think splitting these out, making them less tied to the routing system. ~So like ~sometimes maybe you just want a modal, but you don't want it to ~like ~have a URL change associated with it. You just want it to be like a pop up. ~Um, we're ~going to be making that. Easier to do here in the future.

Paige: ~Mm hmm. Very cool. ~Very cool. ~So, ~what are some of the next milestones? ~I mean, ~you covered a couple of them for, ~you know, ~what's coming up in 52, but what are things down the line that you're looking to add to Expo or to React Native Development in general? ~I~

Evan: Yeah. ~Um, overall I want,~

~so, so ~my vision for this tool is for anyone who is a react developer or web developer,~ uh, ~to be able to go [00:26:00] to the app store,~ uh, ~immediately. ~And. ~We will solve every problem that stands in the way of ~that, uh, ~that goal. ~And so, you know, ~there is a lot of problems in the past where it was like, if you wanted to use Expo, then you had to give up file based navigation.

Now you don't have to do that. And now it's like ~you, ~if you want to use Expo, you ~kind of ~give up ~maybe ~server side rendering or static rendering. Cause those don't exist on native. Well, server components. that goes away. ~Um, you know, ~we sold API routes. We've solved a lot of these bundling questions. And,~ um, ~you can add CSS and like tailwind and post CSS.

So, um, really a thousand cuts. ~Uh, but whatever, yeah, ~whatever else ~is, ~is a problem we will fix. I think by 52, we're going to have a lot more of the groundwork laid for this and people will be able to see ~You know ~how you can basically just know nothing about native development, take your existing web dev skills and go to the app store.

~Um, so yeah. ~And then there's ~other, you know, ~other aspects of solving this problem from the meta team as well. So we like react strict Dom,~ um, ~which. is ~kind of ~in the intermediary there too. So if you're going from just normal DOM to,~ uh, ~React Native, maybe you could go normal DOM to strict [00:27:00] DOM, and that's maybe an easier transition.

~Um, ~and then overall, I also wanted to see more marshaling across the board. So if you write a React Native app, you should have access to more of the underlying native primitives,~ um,~ instantly without having to make a new native build. I think that's going to be really fantastic ~for, ~for speed, iteration speed and so on.

And then just overall improving the build times, like there's lots of techniques, ~a lot of, ~some of the best like iOS and Android developers I've ever met in my entire life, or could even imagine, work in the React Native space. ~Um, and, ~And so I think there's a lot of room for improving the build times so that you can just build things super fast and, ~you know, ~not repeat any work.

~Um, you know, we've, ~we've really nailed a lot of ~the, ~the CI flow ~of ~with,~ uh, ~EAS build and submit where you can push your build and then have it appear in the app store. ~Um, ~so just making all that faster, easier and more approachable to web developers, I think is going to be the, here.

Paige: ~I mean, ~I think ~that ~that sounds great because that's always been a little bit of a. And I think that's a big sticking point for me, I guess, to ~kind of ~doing mobile development is ~I, ~I'm not sure how great the learning curve is going to be [00:28:00] coming from a web development background where I use next JS or I use felt kit, ~kind of ~just getting into another framework or ~learning things that are ~learning patterns that I guess are unfamiliar to me.

So ~it's, ~it's awesome to hear that you're trying to smooth that curve as much as possible.

Evan: Yeah. I think,~ um,~ the elements exist, but the problem is when you do something like render a div in react native, it has this like terrible error message where it's like a name of you named div doesn't exist. ~Like, it's not, it's like, you. ~It should be obvious that people are going to try to use react code, even as react on code on react native.

And ~we should, ~we should do things like improve those error messages. So someone who has no understood, all they know is react, which is a lot of human beings,~ um,~ that they can run their. ~They're the ~react code in an expo project and something should render this to the screen. It might not be the most optimal or ~the, the, ~the best possible thing that renders to the screen, but something should be there.

And then it should be clear how you make that the most optimal, and you should be able to incrementally component by [00:29:00] component,~ um,~ make it more optimal over time because maybe you just have a website and it's fantastic. And ~it's mobile web, uh, ~it supports mobile web. And you just want to. Add a home screen widget to it.

You shouldn't have to ~like ~change anything or have to start from scratch to do that. You should just be able to add ~a, ~a home screen widget to your otherwise,~ uh, ~totally complete react mobile website. ~Um, ~and we shouldn't have to wait for PWA vendors to support that for us or support some subset of that for us.

We should be able to just do that. ~Um, ~so I think we, that, that's my vision of where this is going and I think we'll be. You're living up to that vision here in the very near future. ~Um, ~like 2025, it should be very clear how you do that.

Paige: That's excellent. So is there anything that we haven't really talked about yet with Expo Router and React Server components that you'd like to touch on? ~Mm hmm.~

Evan: we've added API routes,~ uh, ~which is fantastic because,~ you know, a lot of native, ~the trickiest parts have been ~the, the, ~the front end, the UI and getting the most native feel. ~Um, ~but if you want to build a real product,~ you, ~you do need to connect to an API and have some sort of [00:30:00] database there.

~Um, ~so ~we're, you know, we're really, um, We were, ~we're breaking into new ground there. ~Uh, ~I think it's going to be really fantastic. People should give it a try. You can deploy to whichever server service you want. We have like adapters for Express and I think CloudFlare and Netlify and Vercel. ~Um, and ~so yeah, people should try a lot of that.

And then. Let's see, what else is there? ~Um, ~we've ~covered, ~covered a bunch of it. ~You know, ~going to the store is fantastic, but there's still lots of questions. Oh, and then,~ uh, ~E2E testing is something that I'm really been very passionate about lately. ~Um, ~so with this Jest Expo RSC thing that we're working on,~ um, ~what's really nice about that is, say you just have a lot of logic, which is, ~you know, ~making fetch requests and then parsing data, ~you know, ~validating data and then rendering it.

If you want to run that to end, Even though it's totally headless and there's no UI, you have to run that inside of ~a, ~an iOS device with a JavaScript engine on it to ensure it works. With the RSC stuff, you'll be able to move all that logic over to the server side and then just run it completely end to end inside of a jest test [00:31:00] because it's running in a node environment that is a server environment.

So you do know that it works and to end as much simpler. ~Um, ~and ~that, ~that will shave like ~50 to an hour. ~50 minutes to an hour ~out of your~ maybe potentially out of your CI builds and processes. So I think that'll be really fantastic for stability and improving resilience across the board.

Paige: Absolutely. Silence.

Evan: Yeah, really excited about the resilience and the ability to improve automation in the native space as well.~ Um, ~it's all the little things that you wouldn't expect are the problems with app development and the, a lot of these problems,~ uh,~ have good solutions in the web space.

So on top of solving them, we want to make sure that they feel,~ um, You know, ~very true to the web and the best practices of the web.

Paige: Well, Evan, it has been [00:32:00] fantastic talking to you. If people want to get in touch with you or find out more about Expo Router and how they can start using it or. Use it to the best of its abilities. Where would you recommend ~they ~they find you and find more information about it?

Evan: ~Yeah. Uh, ~yeah. Thanks so much for having me. ~Um, ~I'm a bacon bricks on Twitter and,~ uh,~ you can also follow expo on Twitter or X. And,~ um,~ and then you can follow and start ~the, ~the expo project on GitHub. ~Uh, ~and that's primarily all the things I spoke about today. All of that is going into the ~expo expo, uh, ~monorepo on GitHub.

~So. ~You can see the pull requests and the branches and everything live if you're interested in following that.

Paige: Awesome ~Well, ~we will be sure to include all of that in the show notes and thank you again for joining us on the podcast It's been a pleasure talking to you

Evan: Oh yeah, thank you so much for having me.