Breaking through the Browser Barrier (With Expo)

So, my name is Cedric van Poethe, I work on the DevTooling team at Expo, and today I want to talk about breaking through the browser barrier. Before I begin, I realize we're in React Advanced, which is mostly a React web conference, and I'm here talking about React Native.

So, while I could try to convince you to use Native instead of web with the mobile vs desktop usage stats, it has been mentioned way too often already. And frankly, stats can be boring. So, instead, let me tell you the story of Rosebud.

Not too long ago, Chris Bader, co-founder and CEO of Rosebud, wrote a blog post about their app on our blog, explaining the whole process of why and how they went from web to Native using Expo. Now, the app itself is just a journaling app. It's built to support your mental health. They built a progressive web app in roughly a year. Am I a bit? There we go. There we go. They built a progressive web app in roughly one year and have moderate success with over 100 million words journaled.

Now, after the initial web-only release, they ran into some pain points. The lack of distribution, like an app store where people search for Rosebud, but since they were not present in the app store, they were actually losing out on potential customers. It was hard to re-engage with customers due to the lack of push notifications. And while they did grow, the growth was somehow below expected, resulting in their runway running out in about a year. And on top of that, the most common feedback they received was, I would use this if it was an app.

Now, while Chris was hesitant to bet the future of the company on a Native app, he luckily did get convinced after talking with some advisors. So they set a goal, get into Native app as quickly as possible. Now, the originally web app was written in React. So the team was already familiar with React. They have React related business logic, like hooks and other data management. So they picked Expo as being the best fit for both their goal and what they already had. So they went to work and an app they built. The app currently has a 4.9 rating in the app store. So it's definitely well received. But what about the business impact here? In just 14 days since launch, the app alone collected over $20,000 in revenue. It added a roughly $6,000 in monthly recurring revenue. And both the day 7 user retention and the upgrade conversion doubled compared to their PWA, meaning they extended their runway to build out their app. Now, you can read the full story of Rosebud on Expo's blog.

Here, Chris Bader explains why they switched from web to Native, which frameworks were under consideration, why they chose Expo, and of course, how they did it. Now, this is something I like to call the browser barrier, where the barrier reflects on being limited in the growth by going web only. Like you're missing out on some really cool Native features like wish notifications and other things.

While this barrier is different for every business, there are overlapping teams. Like, you have to get as close to your users as possible, like right in their pocket. And of course, you have to keep the users engaged to build habits of using your app. Now, Rosebud's story isn't unique. And at Expo, we thought on how to improve this whole brownfield path of going from web to Native. And I think we found something great. So let's go through this process together.

Meet Music Finder. Our example project for today is a super simple music catalog where you can find music artists, you can see some audio books. It's based on the ShadCN's music example. So maybe it's somewhat familiar already. And for the sake of simplicity for our demo, I'm already using Expo Router, just web-only stuff right now. Now, our app is fairly simple. We have the artist page, which is our default page, so the main index. We have our books page, which of course contains the audio books. And we have the login. Now, each one of them contains super simple basic HTML and some Tailwind, all copied from ShadCN.

So from the top to bottom, we have a simple container element. We have some toolbar navigation for the menu and the login bar. We have a header to tell the user what page they're on. And of course, in this case, we have a scroll area for the album. Well, we actually have another one, but for the sake of simplicity, I only showed one. Then our books is almost identical, except we're not using a scrollable area, we're using the book grid. And the login is slightly different, but it's using, of course, a form instead. Now, if we were to run this directly on native, it will crash right away. And that's because, well, React Native doesn't know HTML elements at all. React Native is built on top of native primitives like UI TextView or, well, all kinds of other But nonetheless, they are not using HTML elements.

Now, if we want to actually make this work on natives, we have to commit to swapping all HTML elements for React Native elements or some other UI library that works with both React Native and React. That's quite a big commitment if you just want to try things out, right? So, instead, we can use a new thing we call DOM components. And DOM components actually was already released in a Canary release by Evan Bacon. Both Evan Bacon and Kudo Chen actually worked on this at Expo. And it can help us to get to a working native app using only minimal efforts.

So, let's try this out in Music Finder. So, going back to our artist page, the only thing we have to do to enable DOM components here is use the DOM director. That's it. This will enable the whole component to be somewhat differently rendered. Um, now, the name kind of already implies that it only applies to components, right? So, let's swap our route over to an actual component. So, in here, we just moved everything to the Screen Artist component. And then we update our route to just render that one instead. I will circle back to this on why this is important. But, yeah, you'll see.

Now, doing the same for the Books and our Login component, we actually have our web app running natively. Now, the good thing here is that the app works. The bad thing is, as you can see on the top, the menu and the Login button are being rendered under the system UI elements. And, of course, that is non-standard navigation. So, let's iterate on this. In order to fix that, let's implement a really basic, well, standard navigational pattern included in Expo out of the box. In this case, we're going to use the tabs screen, or the tabs navigator. Now, we only want to render this on native, as tabs actually also work on web, but it's non-standard on web. So, on the top, you can see that we exclude the whole tab stuff only on web. But, yeah, on native, we just render whatever.

Now, going here, we don't want to render both the bottom navigator and the menu on top. So, we just hide it. We might change the detection here a bit because it's a little bit rough, but you get the point down there. If it's not running as a DOM component, render the top navigator, and if it's not running as a DOM component, also show the header. Now, going back to our app, this looks way better. We have native navigation, meaning that we actually adopt the platform-specific behaviors.

Like I said, on the bottom, we can swap between the tabs. On the header, we actually have the title of the screen. Now, you just saw we actually have a modal overlay login, which displays the whole login as an overlay over the app, which is also standard on iOS. But we haven't changed any of our React web code. So, how does this work? Well, for that, we're going to take a look under the hood. To understand this better, it's easier to just see it. So, we're going to use Expo Atlas. It's a simple tool that we released earlier this year, where you can actually take a look at your bundle itself. Now, in React Native, the bundles are big, and they become sort of a black box, and Atlas tries to remove that. So, looking up our artist component, we can just search for it, click it, and there we go. On the left side, we can actually see... Well, I hope you can see it, but on the left side, you can actually see our HTML elements, our chat-cn, and on the right, you can see how it's getting bundled inside of your app. Now, as you can see, this is not our code at all. And you can spot another thing. It's actually using a WebView. Now, why a WebView? Like, isn't Native supposed to be fully native? Well, in some cases, it actually makes sense to use a WebView. But before we dive into that part, let's check out the web part of that WebView. So, just like Metro, Atlas can actually inspect the different platform targets. So, right now, we're only building for iOS, but we have three different web bundles as well. Now, each and every single one of them is actually the DOM component. So, if we swap to that one, we can actually see our code being rendered properly. We actually have our chat-cn code and the properly transpiled web code on the right.

Now, can we use this for everything? It's like, can we use this for, I don't know, all of our pages, all of our screens? Actually, yes, but I wouldn't recommend it. So, I just showed you how you can, like, run the web part on Native with minimal efforts. So, it's perfect in a migration path. But there's one big important trade-off, and that is performance. You will lose some of the performance. So, in a traditional React Native app, we have something called Hermes, the engine, right? And it's not actually executing JavaScript in production. Instead, it's using some form of JavaScript instruction code, which is called Hermes bytecode. And it helps the app to be, like, even if it's 10 MB, 20 MB, to boot up near instant and to run near instant, which is important in React Native apps.

But web queues are not running Hermes. So, what kind of effect do we have there? So, on the left, you can see our actually DOM Component app. It works, but when we swap pages or when we first load a page, you can see a little bit of, well, styled-wide content, unstyled-wide content. While you can hide some of it by, like, applying some face or preloading the screens, you can't really remove it. This is why, like, one of the things of DOM Components is you shouldn't use it for everything. Now, if we compare this to our actually fully converted React Native app, you can see that our React Native app is pretty much instant. Granted, it does not include any data fetching, but even without that, you kind of want to have the UI part of your app being able to run instantly. And, of course, like, if you just spotted, if you go full native, you can also implement very specific platform features, like the long press. Whenever you hold any of the images, you actually get a context menu. This is made with Zego, and it's super easy to implement if you use React Native. Now, this is not possible on web. And if you look at them side-by-side, you can see which one is faster and which one is not. Now, it's important to understand where and how you can use DOM Components. You can start with only DOM Components for everything to get up and running as fast as you can, but try to iterate away and, well, improve the app as you go.

Now, as I said, DOM Components actually has been released already as a canary feature. And luckily, some of our users were actually adventurous enough to try a canary build. Now, for example, Thor from Superbase actually created something super neat. He created a whole guide on how to use DOM Components to self-host your own maps using Map Libre, ProtoMaps, and Superbase. Now, again, it's super hard to compare in terms of maps compared to Apple and Google because it's such a complex concept. But he actually did a great job here. And the fact that he's actually using the Web API or Web SDK for Map Libre and it actually works on a native app is pretty impressive to me. Now, another really cool feature is this one, or example, where Devloop actually created an app using React Swappy.

Some of you might know it. But this clearly demonstrates that you have the ability to, well, use any of the React web libraries on native as a first implementation. And even the gestures here work pretty well for a web view.

Now, this one I like the most because over here, Raphael Moreau showed us how to use React Photosware viewer on native. Now, rendering on native is actually possible to implement natively with William Cantillon's WebGPU and many other libraries. But if you go native, it usually means that you have to implement something way more complex. While in this case, it's literally just this, where you can just use any of the web libraries, just smash it into a DOM component and then try it out. And as you can see over here, he's actually passing props data towards the DOM component.

Now, you can do that, but make sure you only use serializable data because we're actually bridging two different environments. We're bridging the native context and the web context. So to summarize, with DOM components, you can actually start using the whole ecosystem, even on native. So not just React Native, libraries also react libraries. It can be used as an incremental migration path from going from web to native. And like I said, you can interact through props, but be careful with this because again, there are two different contexts here. You cannot pass class instances from one different environment context to another, where we're using even a whole different engine. Now, you can actually use this today as Xpressdk52 got released as a beta yesterday evening. And in Xpressdk52, we're releasing DOM components as an experimental feature. Now, if you want to try it out today on your phone, take a look at Evan's app. Like I said, Evan announces at React Universe, he created an app where everything is a DOM component, but it's ultra poly. You can scan it from TestFlight and actually run it on your app, or you can scan the website so you can put them side by side. The code of this one is open source actually, so either find it yourself or come say hi to me.

That's all I have for today. My name is Cedric van Putten and today we broke through the browser barrier using DOM components. That was a great presentation. It's so wonderful every year to... I don't work in React Native actively anymore. About once a year I see an expo talk at a conference and it's just amazing what you guys keep putting out like year after year. It seems like a real sort of like a commitment to a continuous mission that kind of keeps making sense. Every SDK version is packed with new kind of things, like SDK 52 is the largest one yet, I think. It contains an early preview of RSC even, developer preview, you cannot use it in production yet, but we're working hard on that.

And of course it includes like very interesting concepts like DOM components. So yeah. Nice. Well, you mentioned RSC and I think as I was watching your talk, it seemed like as a paradigm it's relatively similar to server components, even caution people to only pass serializable props to across the boundary. And it's very similar to how we now think about the component boundary in React server components. So two questions about that. One, is there any sort of like connection in terms of like the API implementation? And also, can we sort of interleave native and DOM components in the same way as we can do with server components where you can pass a server component as a child to a client component, et cetera?

Yeah, so I mean, the API design is somewhat related to like RSC, right? Where we have a directive to enable a different property like a different behavior of the component itself. So with RSC, you, well, you actually, we actually doing the same thing, right? Where we have a native context, well, in this case, the server. And we run it like we connect or bridge two things that are completely separate. But we make it so that it's all React. So you can just pass in props, you can pass in some other stuff and it works on both platforms. Now it's somewhat similar. I mean, both are an advanced bundling feature that we're adding to Metro. I wouldn't say they're like using the exact same code, but they are related in that sense, yes.

Nice, and I guess I was curious, like, would it ever be possible in the future to sort of go the other way around where you could just, you know, have most of your app being rendered as a DOM component and then just interleave a sort of a native component in there? Well, I mean, there are, with every approaches there are trade-offs, right? So in this case, the web view is somewhat slow. Like if you use it as a full screen, you can do tricks like eagerly load all the tabs in your app. So the load time when you swap the screen is almost nothing. And then if you add like a nice transition from one to another screen, it fades away completely. So I would say it's not necessarily, can you do it? It's like, of course you probably can, but it is better to just try it and iterate on it to see how good you can get it. That's also why like we showed the DOM component app or DOM comp.

The second question here, the highest rated question, you know, this goes to a little bit about what you said that, you know, this feature depends on, you know, advanced sort of bundler integration that you have in Metro. And, you know, most web developers today, you know, are not yet using Expo router, you know, as their kind of routing solution. So, you know, if somebody has a, you know, a midi-sized, you know, next.js app and they want it to go and, you know, port it over to mobile, what steps would that involve going from next.js for example? So next.js doesn't work at all on native, right? Like not just the framework itself, but the bundler is different. So there are many differences, like it's not compatible next.js and Expo, but the components that you write in next.js should kind of work in an Expo DOM component. So the only step you have to do first is going from a next router app or like next app router to an Expo router structure. Once you have that, you can fill in the blanks, like just like I did in my example, where I started with just three separate pages and then added the layouts to tie them together nicely on native. I would argue that that is the same steps that you have to take to go from a next app to like a proper native app. It can be daunting for a really large app, but if you move screen by screen and if you tweak them by screen by screen or like group by group, you should get there pretty fast.

I would argue that that is the same steps that you have to take to go from a next app to like a proper native app. It can be daunting for a really large app, but if you move screen by screen and if you tweak them by screen by screen or like group by group, you should get there pretty fast.

Yeah, is there like an incremental migration story from let's say, next app router to Expo router, even on the web? Can you sort of do it little by little? You can do it, but you have to translate it to the Expo router route structure. Like there's not an automated tool that you can use to swap between them. And even then you still have to iterate and polish them all at the same time. That makes sense.

All right, so we have the next highest rated question here, is can you interact with native APIs from DOM components like haptic feedback or push notifications? Actually, yes. And that's actually what Evan is also demoing in the DOM-COM app, where like it is kind of hard to have interactivity between components if you can't pass in functions or can't pass in something that is callable, right? So both Kudo and Evan worked on something crazy that where we actually bridge also functions. So what you can do is you can pass in a function to the DOM component, which is available in a web queue. And then whenever you have haptics or whenever you want to do a push notification, you can just call the function that actually triggers that on a native site. So through that, you can hook into whatever you need. If you have too many things at once, it can be a bit awkward, but if you use it wisely, it should be pretty straightforward. Nice. Yeah, that was a good question. And I had a good answer. I was actually surprised to hear the answer. I thought it was going to be a nope. No, it's there. It's there. Very cool.

All right, so next question is can DOM components be used in an existing non-Expo React native app? So we always get this question and it's a good question. Like, can this framework feature from Expo be used without Expo? And the short answer is no. It's the framework. Like what you have to understand with Expo is that we also expand the feature set of Metro. Like we had the fast resolve at first. We had all kinds of additional things around the resolution to speed things up quite a lot. Luckily, that got upstream pretty fast. But these very advanced bundling features like RSE, DOM components, they're just not available without Expo as it is the added functionality on top of Metro. Granted, I mean, not going to say never that it won't be upstream, but for now you can't. Nice, thank you.

All right, so we have four minutes left and we have three questions still here. Let's see if we can get through all of them.

All right. So the top question is would you recommend this for a greenfield project instead of using React Native, you know, to make a sort of like a web and native mixed target app? I would say it depends on the team. If your team is capable of using web, go for it. I mean, there is no trade-off in actually starting like that and then moving back to native as you go. You will get an app way quicker, especially if your team already familiar with web. So yeah, there shouldn't be any trade-offs.

And I think this is a related question in a way as well from like an implementation point of view is are Expo DOM components related to React Strict DOM in any way? Like what are the trade-offs between the two approaches? So React Strict DOM is like the next version of React Native web. And React Native web is basically the layer in between how you write your components or how you write your UI and how it gets translated on web and native. Now it is not related like RSD is separate, but it is like the missing part that could help you get to React Native way faster. And like personally, I'm very excited about RSD. It does need a bit of work still, but there are promising things in there.

All right, so next question is can DOM components be used in an existing non-Expo React native app? So we always get this question and it's a good question. Like, can this framework feature from Expo be used without Expo? And the short answer is no. It's the framework. Like what you have to understand with Expo is that we also expand the feature set of Metro. Like we had the fast resolve at first. We had all kinds of additional things around the resolution to speed things up quite a lot. Luckily, that got upstream pretty fast. But these very advanced bundling features like RSE, DOM components, they're just not available without Expo as it is the added functionality on top of Metro. Granted, I mean, not going to say never that it won't be upstream, but for now you can't. Nice, thank you.