Wait, You're Shipping React Native to the Web?!

Hey, everyone. I'm Taz Singh and over here is Marc Delgliche, and I had the pleasure of chatting with him down in Australia where this photo was taken right after he said, wait, you're using React Native on the web. Why in the world would you do that? And so, if you don't know Marc, he's the creator of CSS modules, vanilla extract, and more recently he's worked on React Native design systems over at Rainbow. Today, he's doing awesome work at the Remix team over at Shopify, and this is the answer I gave to him back then.

I said, well, Marc, this is why. Guild is the platform for communities, and communities are everywhere. They exist in all shapes and sizes, and we need to build an application that is also everywhere and can exist in whatever shapes and size these communities come in on all of the different platforms our users are on today. And so, today when you're building a modern application, you need to cater to both mobile and desktop anyway. So, looking at the usage metrics for Guild, 51% of our users are on mobile devices, and 49% are in desktop. This makes sense because people are interacting with our platform on the go, they're looking for events to attend and presentations to watch, and all of that happens, you know, primarily on a mobile device.

On top of that, we're an early-stage startup with a small team. We need every member of our team to be as effective as possible when shipping code. Every change to our codebase needs to have the highest impact possible. However, if we were to ship code to every platform, we'd also need to support and test all of them. So we'd need to test against every single web browser, we'd need to test every single mobile operating system, and it's the same story on desktop as well. We'd need a bunch of physical devices to test this all on, all from low-end Android devices to Linux boxes to everything out there basically. You can imagine additionally supporting multiple languages, for example, English and Spanish, where the number of items to test and support would start to increase exponentially, and it would just become infeasible for a small team like ours. This is why today we're focusing on the web platform in the English language at the moment. Just to support, keep the support overhead manageable for our small team.

And that's because the way I see it working is a bit like this, where this is the web platform that we're building for today. Once we introduce iOS and Android applications, we can see it looking a bit more like this, where maybe there's a common area in the middle, and as we continue to layer on more platforms like MacOS, Windows, and Linux Native apps, you can see the diagram looking a bit more like this. And for me, this is really where the power of leveraging React comes in handy. Where I see React being the superset of all these platforms, and React Native can encapsulate the logic and orchestration for all of them to work together. So let's focus on React, shall we? What do I mean by that? Well, let's say I have an app in React that looks like this. It renders some component, right? Maybe you start to pass some data into that component, and you get some data out of that component. That's the contract that your application cares about. That underlying component could be doing anything. That underlying component could be using React Native. It could be using a React Native view and rendering to a React Native text element. That underlying component could be using HTML elements, using in a way that's familiar to you if you're using React DOM today on the web.

Or it could be using some sort of native view that's entirely platform-specific, in this case an iOS native view that's actually dropping down to some sort of iOS native rendering logic itself. Fundamentally, React Native, and in our case Expo, makes it easy to write the common code on the left, and then override that with something more platform-specific towards the right, just by the file naming convention.

You can see I'm suffixing it with .web.js and .iOS.js to kind of specify one for the web, and one for iOS, and it will fall back of course to the more generalized .js version for other platforms, such as in this case Android or so on and so forth. For us, we always start with the common approach on the left provided by Expo, and then when we need to provide something more platform-specific we'll then override it with the appropriate file extension as I've described here. Because remember, the contract remains the same. It's just a React component that's passing data in and getting data out.

The composability of this model is what really makes all of it possible, and for me, it never feels like I'm giving anything up. It never feels like I'm being let down. It never feels like I'm being run around and deserted. Thankfully, the Expo SDK has most of what you need to make all of these things work. Just looking at a few of their examples from their docs, we can see they have a blur view. They go so far as to list platform compatibility for this right inside their docs itself. So we can see it's supported on the web as well as iOS. But then what do we do for Android? Thankfully, a quick Google search led me to this library, React Native Community Blur, which provides the same functionality for Android. Again, just by naming these files specifically for each platform, we can create an experience that works everywhere with a common API that works across both.

Expo has a bunch of other components and APIs that you can leverage when building a cross-platform application. One of them is Expo AV for displaying audio or video. Again, they have a helpful list of platforms that it's all compatible with. Expo GL View, if you're rendering Open GL, this is, again, compatible across every single platform. On the web, it renders to WebGL, and fundamentally, you can go look at the docs for yourself on the Expo page. They have something for just about everything out there. The lovely thing is that all of these components technically work across any non-Expo React Native application, and they also technically work across any non-Expo web application. However, I haven't actually tried those combinations myself, so I can't speak to my own personal experience from them. I just know that it's all technically possible, so if you want to experiment, you know, go ahead and feel free to let me know how it works out for you. All of this works because components are the building blocks of React Native. We think of components first, and we compose these components in order to make applications. If you want to blur something, you just compose in a blur view instead of thinking about the particular CSS properties to achieve something similar. If you want to display a video, you just compose in the Xboav library and use their video component right then and there. If you want to display some graphics, you can just do the same thing with the Xbogl component. Fundamentally, React Native is true to React's core model of component composition.

Instead of worrying about platform specificities, we simply compose these components and let those underlying components do all the heavy lifting for us. We just care about that top level contract, and that's really what React is all about. Cool.

So, that's basically how we develop using the underlying React Native component system. As you can see, that's everything we need and we don't feel left out because we can always drop down to something more platform specific and compose components in a manner that's true to React.

But how do we build an application out of this? Well, I'd recommend checking out a presentation I gave last year called React Native Everywhere. You can find that by heading over to my profile and Gil, just link there in the top left and check out the presentations I've given. I go into more detail about how I think about React Native design systems and also navigation within cross-platform React Native as well.

But in essence, if I were to start today, what I'd recommend is Tomagui for the design system. We've actually started migrating over to this and we're seeing amazing results, I highly recommend checking it out. It's styling and optimizing compiler and UI kit that unifies React Native and the web. It sounds amazing. I had the pleasure of hanging out with Nate Vinehart earlier this year where we chatted about Tomagui on camera, which will be up on my profile as well when we get around to releasing that. So check that out for a deeper dive essentially with Nate.

In essence, however, the optimizing compiler for React Native applications creates straight platform-specific code for your application. This screenshot shows how we take generic React Native code on the left written, of course, in the Tomagui design system. And on the right, it compiles down straight to the web platform itself. So just looking at the code on the left for a minute and feel free to pause the video if you want to take a look at it a bit more, it's just using a stack component for layout and a heading component for text. That's the code you write, and that's all you need to think about when you're creating UIs. Just the top level of kind of how it works. It's highly declarative and you don't need to worry about what's below because of React's component composition model. If I was to zoom into that compiled output, however, it essentially looks like what you'd write if you were writing highly optimized platform-specific code using React DOM and CSS variables for everything. The semantic HTML has compiled down to a div with an H1 tag in React and the CSS uses all of the appropriate media queries to make it all work just as you'd expect if you were to handwrite this all from scratch yourself. This works obviously extremely well on the web, because you can then use those higher level components to compose your application and let the tooling worry about how to create something better suited for the specificities of that platform. Any serious application should, of course, be using a design system and Tamagui is an excellent one.

To stitch it all together, I'd recommend checking out React Native URL router for navigation. It's essentially React router with all of its state management goodness, plus React Native screens to give it that native swipe from the edge feeling that you're used to when using a native mobile app. As we're currently building for the web right now, we're actually just using React router directly at the moment. However, we're planning on using React Native URL router when we do expand to mobile platforms as well. You can kind of think of React Native URL router as a layer on top of React router.

So, they're both incredibly compatible. So, what we're doing is really a stepping stone towards that mobile future. And since we're rendering for the web, we need one key feature that you may not need if you're not rendering for the web, and that's server side rendering, of course. But for React Native, because we're building a consumer application, I mean, of course we want server side rendering. It's of great importance for us from an SEO perspective as well as performance perspective just to provide that experience immediately when a user lands on our page.

But how do we do this for React Native? Well, I'm sure when I say this, a lot of you think of Next.js. You'd be right. They have a fantastic server side rendering pipeline, and they spent a lot of time optimizing it, and it's really state of the art. It's one of the best out there. But I don't quite think this framework is right for us. And the reason for that is if we were to use Next, we'd have to build on top of their router. And while that in and of itself is fine, it doesn't really provide us a path forward for mobile as well. Sure, we could build out a whole separate navigation stack just for mobile and run that concurrently with a web navigational stack. And we have two entirely differently navigational stacks in our application. But that wouldn't really help us unify our code across platforms. And fundamentally, it would just create more work for the team as well as creating more potential areas of inconsistency, because I mean, it's just fundamentally two different things. And so I don't quite think Next is a fit for us for that reason.

Of course, there's also Remix, which has a great server side rendering engine built directly into it. Right now I say our stack is most aligned with Remix as we're currently using React router, which also powers Remix. However, again, they don't support React native URL router. And so moving forward with Remix would mean that we need to do something different there once again. Perhaps it would be less intrusive than Next because we're currently a bit more compatible with the Remix approach. And technically, they're both fantastic options maybe for you. If you have a similar set of concerns, that's why I'm mentioning these, because they are truly fantastic world class options out there. But for us, it's just the way that we think about this in that we do want to unify our navigation and have one navigational stack across everything. And fundamentally, both of these aren't really solutions for us. But maybe these are solutions for you.

Now, fundamentally, what do we do though? Essentially, what works for us? Well, thankfully, I had the pleasure of sitting down with Evan Bacon from the Expo team to chat about this. You can see the recording of that following the link on the top left or just heading to my profile or just heading on Guild and searching Google as well. Overall, Evan is an amazing dude.

He's one of those brilliant minds out there and he has such unique insights on this space that it was such a blast sitting down and talking to him about the future of navigation and bundling from an every platform perspective within React Native.

About six months after this conversation, Evan came out with Expo Router. Conceptually, I believe this to be the most future-facing solution that works with the majority of how we build our app. It's quite literally been built with cross-platform navigation in mind and it was kind of spawned from that conversation I had with Evan so obviously I feel quite good about the solution.

However, it's just not quite there today. They don't have active server-side rendering or other web-specific features such as code splitting just yet. With Expo Router v2, you can render your React Native web apps to static files and serve static files if that works for your app. But for us, we do need active server-side rendering as we do have dynamic data that we do want to be rendered on the server.

Evan mentioned that this is coming and he envisions the Expo Router project to be about two quarters of its way to completion based on their current iteration today. So there's two more quarters left to really fulfill his vision and one of those active server-side rendering and code splitting and etc will be a part of it. And so we'll definitely keep an eye on that and maybe we'll look to migrate when that comes out.

I am a little skeptical however, because they are using React Navigation on the web platform. I have a feeling that because React Navigation ships UI as well as routing, it would result in a larger bundle. Every project I've ever worked on I've kind of overwritten React Navigation's default UI. So I'd prefer if those two were maybe decoupled. However again, the team there is smart, they're brilliant, they're good friends of mine and I know they're working hard on this stuff. They take it very seriously and they listen to feedback. And so that's kind of everything you could ever wish for in terms of a technology provider. And so these are all things that they know and I'm sure they'll execute well on this in time when they hit those other two milestones and get it to a four out of four in terms of completion. So we'll definitely keep an eye on this and maybe we'll look to move over in the future.

But fundamentally, what do we do today? Well, I guess, fundamentally, we'll just have to build it today. We'll just build it ourselves. And so we rolled up our sleeves and we built an entire server side rendering pipeline on top of Cloudflare workers to power Guilds Web Experience. It utilizes all of the latest React 18 concurrent rendering in terms of streaming responses over to the user. Cloudflare also informs us of the user's device type, which we then use to server side render into the breakpoint that that person is likely to get. So, for example, if it's a mobile device, we'll render into a mobile breakpoint. If it's a desktop device, we'll render into a desktop breakpoint and so on, directly from the server itself. And this is because React Native uses the Window Dimensions API and not media queries, unless you're using something like Tamagooie. But even rendering into a breakpoint on Tamagooie, you need something similar to kind of tell you what device type to render into. So it's great that Cloudflare provides all that.

And because we built it ourselves, we can actually make that optimization ourselves because we essentially know the pieces of the framework that we're working with. But if you were to do this on something like Next.js or Remix or something like that that doesn't support all of this and doesn't really know how to make that, like, essentially glue those bits together, you may not have such a good experience. And so we're able to do so because we know all those pieces together.

Additionally, because we're using a relay for our data fetching over GraphQL, we're able to embed all of that initial data over that initial payload to avoid refetching on initial load. So we just embed the relay store directly into the initial payload. So when you first load the page, everything's just there, no additional data calls, no loading spinners, and that's it. So feel free to give it a go. Load up gil.host yourself and just see what it loads like. No loading spinners, should load immediately and should work great.

And fundamentally, the reason why any of this even works is because it's native. React Native is native. It's not React Mobile. It's not React Web. It's React Native because it's truly able to address the native platform on any platform. On the web, it's really just like any other web application. Therefore, you can server side render a React Native web application the same way you can server side render any other React Web application. You can use Next, you can use Remix. You can use whatever you want. It's just like rendering any other React application. Because, fundamentally, you're just rendering the same thing all over again.

All of this got me thinking, though. If React Native is truly native, can I stitch React Native into any application, regardless of how it's built? I mean, Facebook's mobile app is technically just React Native stitched into other native views, right? That's kind of how the entire Facebook application works. It's just React Native next to native. If they can do that with this technology, I mean, surely it's possible for any of us to do as well, right? So, for me, I tried doing exactly that. I tried doing that for GIL's embeddable SDK, where we basically taken all of the building blocks of our UI, created using React Native on the web, and powered by Relay for declarative isolated data dependencies, and taken all of that and provided it as a JavaScript library for folks to natively embed into any page. It's not using iframes, because the challenge with iframes is you can't really operate outside of the frame, so you can't open a modal with more information, for example. As you can see in this public code sandbox, which you can check out for yourself by heading to the link up there at the very top of the page, the mxcfmh link, the HTML is rendering a list of div tags with IDs. That's what I specified in the HTML code sandbox. At the bottom, we're loading the GIL JavaScript SDK into the page, and providing it with all the different elements to render into with the various arguments from our SDK, and the GIL SDK is simply rendering the rest. With this approach, you can take the exact same components that we use to build GILD, and you can natively render that within your experience however which way you want.

You can embed our event component directly into your conference's website and do ticketing through GILD. You can embed our presentation component directly into your personal website, and have all the history of all the different presentations you've ever given with a link back to GILD for more on your profile. Fundamentally you can recreate our entire UI if you wanted to, giving you an easy path forward to deeply and easily integrate into any workflow that you have for your community.

And this is what I mean when I say communities are everywhere. They exist in all shapes and sizes, and we have to be there as well. With our React Native embeddable strategy, we can truly exist everywhere.

Now I know what you're thinking. Wait. But this is for the web, right? I mean, this isn't really truly everywhere if it's not really on other platforms as well. I mean, yeah, you'd actually technically be correct. Right now we are only developing for web platforms. However, this is not my first Rodeo embedding React Native on other platforms. And I'm actually not sure if I'm allowed to say this. Let me just message the organizers real quick. One sec. Sorry. Um, hey, am I allowed to say the F word on camera? Sorry, they're just typing back to me right now. No, I'm not allowed to say that on camera. That's a bit awkward. Well, I'm saying it anyway. Flutter. That's right, folks. In the past, I've embedded React Native directly into Flutter. I was consulting for a large Fortune 100 company where one team chose to use Flutter and another team chose to use React Native. However, the business wanted one consumer-facing application. So, either the Flutter team had to recreate everything the React Native team was doing, or vice versa, or we could seek to embed one inside the other. And I took that as a challenge. For me, I knew that if we could stitch React Native into Flutter, then I knew that truly anything is possible because the technical capability of embedding React Native into any application would be truly proven. Because, like me, I'm sure in even just saying this, I'm sure a bunch of you are skeptical. Because Flutter renders very differently than React Native.

Flutter essentially renders to a canvas, and so we can see that in the top screen shot, where it's just kind of rendering to one view. This is basically a hierarchy, a 3D hierarchy of the different views. And you can see in the top screen shot, it's a very thin hierarchy because it's basically just a single canvas, rendering an equivalent UI across both. React Native renders a full tree of native views, which we can see on the bottom. You can see that there's several views stacked on top of each other in terms of that 3D view hierarchy there.

So, to be clear here, I'm not criticizing one approach over the other. They're both just different ways of building applications with different benefits. But this is fundamentally how the two render. The both of them render quite differently. And for me, it just fundamentally got me thinking, can we actually embed React Native into Flutter? Can we take our same React Native components and truly put that on any platform regardless of how it's built? How native is React Native really? Well, it turns out, yeah. We can actually embed native views into Flutter. Under the hood, Flutter basically takes screenshots of that native view rendered on a separate thread and then composits that into the Flutter canvas. This does come with a performance hit inside Flutter, as you're no longer rendering inside Flutter's highly optimized canvas, but this method does technically exist. And it makes sense, because it's not really entirely feasible for Flutter to do everything within their system. Maps, for example. You want to be a native map that the user chooses, you wouldn't want to really recreate a whole Maps component inside Flutter. You want to bring in that native Maps component and you want that to be stitched inside Flutter. So taking that and combining that with the ability to stitch iOS views, or take iOS views out of React Native and kind of stitch that into any platform, pulling that into Flutter, we were able to embed React Native directly into Flutter itself. In the past, our example of this was able to integrate so deeply that it was actually indecipherable to both the user and the developer. For the developer, they were able to feed props directly into React from Flutter State Management System and were able to pass information back up through React handlers directly back into Flutter State Management System. It was so native, it was even native to developers. All of this is possible again because React Native is native. It respects the platform it's building on top of. I see it more as an orchestration layer that enables you to opt into the JavaScript ecosystem of tools and manage your native application more agnostically. By using React Native, I don't feel like we're losing out on anything that we didn't have before. Quite the opposite. I feel like we're gaining a super power of opting into the React Native ecosystem to enable all the things that we're doing.

Now, I spent a lot of time talking about the why and how of our process. Let me take a moment to show you what we've built. This is the Guild homepage built entirely using React Native on the web.

Our navigation system transforms around user input. That animation is done using React Native reanimated. This subtle effect is done using Expo GL, which is rendered to WebGL on the web platform. Again, it's fully cross-platform compatible. You can kind of see that wave moving in the background. That's all done via Expo GL. Let's just take a moment to watch it, then, shall we?

Okay, there we go. This animation is, again, done using reanimated. All these components are actual React Native components. We can interact with them and open a React Native modal here, for example. So that's just a modal in React Native. These avatars down here, oh, when we get up to them, I guess, all these avatars there, they're all created using mid journey AI, and we use mid journey to create the virtual avatars for each user as well. So it's mid journey on top of mid journey and the animation is, of course, done with React Native reanimated. These presentation cards are using the Satori library, which uses React Native's yoga layout system running on a web assembly inside a CloudFlare worker to render an SVG. So even these images, even these image cards are actually rendered using React Native. And then scrolling down a little bit, there we go. This network's animation over here is the only web-specific thing on the entire page. We could have used React Native Skia, but at the time that we built this, the bundle size for that was about six megabytes on the web, which was just too large for this. Since then, William Candillon, if I'm pronouncing his name properly, has reduced it to about 20 kilobytes. So we can actually reuse React Native Skia on there right now. And this again is a React Native modal, a native React Native modal. This entire page is built using React Native on the web platform with one little platform-specific override for that networks and guilds presentation. But again, we can now rewrite that using React Native as well because William's done such a great job on the Skia project to reduce the bundle size to about 20 kilobytes for that. So fantastic stuff by that team.

However, I need to ask you, looking at this, would you have been able to tell that any of that was React Native or would you just think that all of that was just some other web app built in a more traditional way? So, fundamentally, what does this mean? The way we think about it is that we have our UI and we have our API. Both exist as mechanisms of using Guild. Users can go to our UI on our platform and manage their community. Or they can register for our API, manage their secrets, figure out the queries they need, perform their mutations and build a whole UI themselves. And this may be fine if you want a custom experience and you have the resources to support all of that API development. But there's fundamentally a big gap there between using those two modes.

There's a big gap between using our first party UI and using our API to build everything yourself. What if we can bridge that gap with embeddable experiences where you can take any part of our UI and place that where the traffic exists regardless of platform? What if React Summit wanted to use Guild for registration and put that directly into their platform? They can take the attend button and put that directly on the React Summit website itself. By taking that experience and placing it where the traffic exists, they're able to leverage our UI and essentially get a fast path towards implementation wherever they need it.

This got me thinking, what if we took embeddable experiences seriously? What if we built our apps in a way that third-party UI was the same as first-party UI? What would that look like? Well, right now we have all the various parts of our app built inside our design system as individual components that compose together. I'm sure a lot of you do this as well, because fundamentally that's how React works. If you're using Storybook, you likely export all of these components already, right? So then, taking a look at those building blocks and exporting those as embeddable experiences, we can just render our UI out of that. And again, this is just how you'd use React right now. But the gap that we found is making that embeddable. We had to write custom logic to essentially contain all of these experiences to work inside other experiences. Let me turn that light off. That's the part that we need to work on improving, so that exposing these third party experiences becomes as easy as mounting a React component.

Furthermore, right now, we have to aggressively code split our SDK to only load the JavaScript required when you use it. But what if we can leverage Island-based hydration to only load the parts that are truly interactive, thus bringing down the web bundle even further? What would that look like in an embeddable world? And how can we make that easy for everyone? So for us at Guild, this is our next frontier. It's critical to our business to support communities everywhere in whatever shape and size they come in on every platform they're on. We need to exist where the traffic exists. And that's what I told Mark back in Australia. I look forward to coming back and telling you more about our journey as we work towards finalizing this and open sourcing our work to make it easy for anyone to use our infrastructure, because all of this has worked so well for us. And I can't wait for that. Until then, thank you, and I hope you enjoyed our journey.