The Age of Universal React: What’s the Catch?

Folks, thank you so much for coming here. We're both incredibly excited to be with you. We're going to be talking about the age of universal React, which we think is this next paradigm shift of React. And we're incredibly excited to talk about it. We're going to be looking at the good, the bad, the ugly, and hopefully a little bit into the future.

As Antonio mentioned, my name is Mo. I head the mobile team at Theodo. I've always loved building apps. I built my first app when I was 13. So I started with native iOS, transitioned into the web world with React, and then went back to native with React Native. So I think universal React kind of encapsulates all of the things that I've done in my journey and I'm super excited for it.

Yeah, so Mo and I actually met at the many conferences we've been to and spoken at over the last few years. And we realized we were both talking about, like, very adjacent topics. Mo was talking about sharing code between React and React Native. I was talking about building for multiple devices. And so we decided, let's just join efforts and talk about universal React. Unlike Mo, I don't know what I was doing when I was 13, probably playing, I don't know, Pokemon or something. But I did start as a web developer eight years ago and I was a React developer. And then I transitioned to React Native. And I'm currently a React Native developer advocate at Amazon App Store, which is the app store that runs on our devices. So the types of apps that I work with run on phones, tablets, auto, web, TV. And universal React helps me and our developers navigate that fragmented world of all the devices that we have to target.

So the first question on everyone's minds must be, what is universal React? So universal React are cross-platform React and React Native apps. In my opinion, what it means is a principle of learn once, write once, and run anywhere. And that's my answer. But a month ago at React Native London, Mo asked a panel of us that question. So I want to throw it back to you, Mo. What does it mean to you? Because to me, it's learn once, write once, run anywhere. But what about you?

I'm going to take a slightly different facet to this because I want to talk about what this gives us the potential to have. I think the power of universal apps is that it levels the playing field for small teams and indie developers to really take on the existing big behemoths that are there in the industry. A prime example of this is BlueSky. How many of you have heard of BlueSky recently? Exactly, right? So BlueSky is a small team of four or five developers who are taking on X, Twitter, whatever it's called these days, and they're taking on some of the richest people in the world to build their own social media, which I think is incredibly powerful. And really, the backbone of this is universal React, which is really cool. And so at its core, it starts with a single code base. You use one code base to target multiple platforms, be it web, mobile, TV, AR, VR. Really, the world is your oyster. And it uses React and the web principles that we're all familiar with and puts those into native technologies. But it does it in a way where it doesn't compromise the nativeness of each of those platforms. So these aren't some sort of shitty web view apps that you're used to that don't really feel like a native app. They're truly native experiences for each of the platforms that you're targeting. And what this means in principle is that you, as probably a group of mainly web developers, can use that familiar web technology, JavaScript, CSS styling, my favorite storybook, for app development, TV development, VR development, without picking up new technologies and languages. And the added benefit of this is it helps you target that complex fragmentation of the device landscape. You don't need a team per platform or per device. And this helps you save costs in rebuilding the same thing multiple times, which means more money for feature development, for improving the actual product, and really for keeping your PMs happy.

So, Mo, you said you developed apps since you were 13. Was that 10, 20, 30 years ago? Why don't you give us a bit of a history lesson? Look, I know I'm losing my hair and everything, but you don't have to make me feel like a grandpa hair. I thought you should color it. All right. Okay. That's my stuff. Unfortunately, the color doesn't apply to bald, but here we are. So history lesson.

In 2013, React comes out. And React can only target web at that point. And so over the next two years, it evolves, and it really becomes this new paradigm and this new way of building web applications. This component-based declarative approach just takes the entire UI world by storm.

And then in 2015, we have this moment where React and React DOM are split into separate packages. And this opens up a new door of possibilities where React becomes this agnostic way of defining UIs and layouts, but you can pair it with any renderer for any platform. And that's where React Native is born. It starts off as a way to build iOS apps in a declarative way, which was unheard of in the mobile world. We're dealing with imperative days in mobile. And then obviously you can also target Android very shortly afterwards. And so these ecosystems start to develop on their own. React has its own community, its own set of tools, its own ecosystem, and so does React Native. And these are running in parallel because they're both really React. But at its core, there's almost this disconnect. And so some people within this ecosystem had a realization that these things are actually not so separate from one another.

And naturally, as we have a lot of React developers in the room, just a show of hands, how many of you are just React web developers? Okay, so I'll just say for everyone, about 50% if you're remote, if not more. I think since we have a lot of React developers in the room, let me hand it over to Anisha to just give us a quick crash course as to the difference of React and React Native. And the reason we're doing this is because to understand how universal React works, we need to understand the differences that it's trying to bridge. So, first up, it's actually not that different. React Native uses the same JSX syntax as React, so it's really easy to transition. You have the same hooks, you have the same syntax. The main difference is in the built-in components. So React Native uses views, text, buttons, instead of HTML elements. And what's really cool is these come directly from React Native. They're imported from React Native, so you don't have to create those components yourself. And then there's a few other differences, like the methods. So React, you'll have your own click on your button, and React Native, you'll have your own press. With the styling, again, pretty similar. Both allow inline styling, both support creating the usable style objects. The differences are React uses CSS or CSS and JS, whereas React Native uses a subset of the CSS properties with camo case naming.

So when we say subset, we mean things like the grid are not supported because they don't actually map well to those native layouts. And React Native doesn't use class names. Those styles are directly applied to the components. I think the biggest fundamental difference between React and React Native is the architecture and rendering. So both have the exact same virtual DOM mechanism, where the old tree is diffed against the updated one to determine what needs to be changed. But the difference is that in React, after the diff is done, the changes are committed to the actual DOM to add what's new and change or remove what's been updated. React then uses the browser DOM APIs to manipulate the UI on the web browser. However, React Native has a layer in between called fabric, which handles the converting of those virtual DOM elements into components to render. So it will render the virtual DOM elements into the actual native elements. So for example, your tab will become your Android tab, your tab will become your iOS tab.

And then finally, libraries and tooling. So many things, again, the same, right? So when it comes to state management, when it comes to data fetching, libraries like MobX, Redux, Axios, Fetch, all work exactly the same. The difference is in navigation and in UI libraries and in unit testing. So for navigation, in React, we have React Router. In React Native, we have React Navigation. And this is because the way navigation works on web and mobile is quite different, right? In web, you'll have your URL-based navigation. When you have your phone, it's more of a stack-based navigation. You think about it like when you load a new screen, it stacks on top of the old screen, and that's how you kind of go with your navigation. With the UI libraries, it's different because we saw there's different elements, there's different stylings. So you'll have UI libraries like material in the web world. Equivalents are like React Native Paper in the React Native world. And same for unit testing. Because of those methods like onClick versus onPress, in React, we have React Testing Library. In React Native, we have React Native Testing Library, which is built on the same concepts as React Testing Library. And so that library piece is very interesting because as you see, a lot of those libraries are actually shared. And so the question becomes, for the ones that aren't shared at the moment, is there perhaps a way where we can start to bridge the gap and create so-called universal libraries? And so this vision of React Once, Run Anywhere was formed. And the community has wanted to share native and web since the very beginning. So I'll do my own history lesson now. In 2016, React Native Web was created by Nicholas Gallagher. And React Native Web is perhaps currently the most direct implementation of universal React principles.

So it implements React Native components and APIs in an interoperable way with React DOM. And this is actually ended up powering a large part of Twitter's web platform.

Then in 2017, we saw ReactXP, which was an early pioneer also in universal React. This platform-agnostic component library allowed you to share your view definitions, styles, animations across multiple targets. And this specifically was built by Microsoft for the purpose of sharing code on Skype.

And then last year, we saw XProBooter. And I feel like XProBooter really completed XPro's vision of universal React by providing this routing mechanism that works identically on web and native platforms and allowed us to navigate between screens on our app and web using the same components, which is really powerful, right? We saw that table. There was a big gap in navigation and UI. And I feel like XPro has filled this and really tried to complete that universal React story. And so these libraries have over the years powered different levels of code sharing. I'm going to go back to 2018. A colleague of mine, Ben Ellervy, did a talk at React Amsterdam.

In this talk, Ben talks about a case of sharing code between React and React Native. And he looks at what not to share. And so back then, universal React was really at the bleeding edge. And so they assessed and decided, actually, you know what? We're not going to share any of our view layer, any of our components, any of our navigation. We're going to share what is basic and really just JavaScript. We'll share things like our app configuration, our state management, maybe some API calls and services. But on each of the applications for web and mobile, what we're going to do is we're going to separate the components and navigations and implement them specifically for those platforms. So some basic levels of code sharing. In contrast to today's world, where you can really share almost everything. So all of the things that they shared maybe five years ago, plus UI components, navigation, and even your bundling and your build processes. And so if we start to look at a scale, you have on the left side basic code sharing, which was the mate.com example that Ben was going over. And on the right side, you've got a full universal stack. And what you can really start to see is that as you go from the left to the right, you maximize code sharing, you reduce duplication, and you're not reimplementing the same thing over and over again for each platform at the cost of being able to platform optimize for your web or your mobile applications.

In contrast to today's world, where you can really share almost everything. So all of the things that they shared maybe five years ago, plus UI components, navigation, and even your bundling and your build processes. And so if we start to look at a scale, you have on the left side basic code sharing, which was the mate.com example that Ben was going over. And on the right side, you've got a full universal stack. And what you can really start to see is that as you go from the left to the right, you maximize code sharing, you reduce duplication, and you're not reimplementing the same thing over and over again for each platform at the cost of being able to platform optimize for your web or your mobile applications.

And what we're trying to kind of say here is that universal apps are actually a spectrum. They're not a binary. It's not that you're universal or you're not universal. By starting to adopt code sharing and a code sharing mindset, you can start to make your app more and more universal. And so naturally, you're going to have to make the decision on what trade off makes sense to you, leading to the very important question of what should you share? Or to paraphrase Shakespeare, to share or not to share? That's the question. So let's have a look at a typical, what makes up a typical universal React app, right? So you'll have your business logic, API layers, conflict, custom hooks. These can all be reused. And in fact, I know currently a lot of people already put them in separate packages, but I really want to get on the moner versus multi repo war. So App State, again, we saw that the state management libraries, they're the same. So App State can easily be reused across your app. Navigation, we mentioned, is where you might have to start customizing things a little bit. And that's because those navigation routes might be different across form factors. When we come to the UI, it's broken down into, I think, three things. Design tokens, shareable, because they're just variables. Components are, again, where we might have to take it case by case. And we'll look at an example in the next slide. And then your layout. And this is probably the one thing you don't want to be sharing, because your layout is going to look very different on each form factor. So we mentioned components, right? So this is Zygo. It's a UI library for a context menu developed by Fernando Rojo. And this is what it on the left, on the right, I don't know, I can't really tell. But on one side, it's what it looks like on web. And on the other side is what it looks like for native. And as you can see, as a user, you'd expect it to look different on your web and on your mobile. And so that's an example of where, yeah, you can't have the same library.

And it's a universal library. But it's optimized per platform for that particular reason of components might have to be different. Same with layout. This is Amazon Prime on TV. On the left-hand side, you can see that there is this additional menu, right? So for search and your grid and for saving. Let's look at it on, you know, a desktop or web. So this is the same Amazon Prime app on web. And as you can see, there is, there is in that navigation bar. And that shows that navigation and layout are going to be slightly different.

Now, this is Amazon Prime on mobile. So you know, same app, four different form factors. It's going to have to be optimized for the layout for that form factor. So we've spoken a lot about what you can do. Let's get into the how. So let's look at the present technologies that are allowing us to build universally today. As Aneesha mentioned, React Native for Web by Nicholas Gallagher is really the basic building block of all of this. It's the compatibility layer that sits between React Native and React Dom. And so this is a compatibility layer that you ship as part of your app. It's part of your bundle. And it basically handles the translations from views and texts to divs and P elements. It's really that compatibility layer that shims everything. And what you've got to think about here is that because React Native has such a large surface area, you can see in the diagram on the right-hand side, you have a really complex and complex compatibility layer to take React Native and make it supported on web. Now Aneesha talked about some of the differences that we have between web and native platforms. How does React Native web solve some of those challenges? Yeah. So let's think about what we talked about, those differences. So different components. Now React Native adds this component mapping. So components like your view, your text, your image in React Native are mapped to appropriate HTML and CSS equivalents. For example, your view will become your div. And then when we have our rendering layer, so there will be an API compatibility for web.

So web-specific implementations of those React Native APIs are provided. And this ensures things like gesture handling and other React Native-specific things work the same on web and mobile. And then for the styling, we have styling abstractions. So there is a cross-platform styling system similar to React Native's style sheet that converts inline styles and layer properties to that web-compatible CSS layer. And we're not saying you have to build in React Native. What we're trying to say is that this has allowed for these universal libraries that let you build cross-platform.

What we've seen is these universal libraries have developed. And that's because of React Native web. So in the navigation space, we saw Experuto. But there are other libraries like Seleto. In the UI library space, because of the component mapping, because of the styling abstractions, we've got these universal React libraries, like Tamagoyi, Gluestack, Unistyles, where you write components once, and then they render down into React and React Native specifically. One space that is still being explored, I think it's testing. So we'll see what happens. Like, let's see what the future is. But these are the tools. What about the frameworks? Because we don't want to be building our own framework. So Expo is actually the framework of choice right now for React Native. And this year, we've seen Expo Router V3, which I feel like, as I said, really completes this universal story.

So Expo is actually the framework of choice right now for React Native. And this year, we've seen Expo Router V3, which I feel like, as I said, really completes this universal story.

So last month, I attended React Native London Con. And there was a really cool workshop done by Keith. So this is just the demo of that workshop. So, yes, let me move here. So this is like what we built, which is an app that shares your routes, both on web and mobile. So that's just like you can see there's one app. And then when we run it on web, this is what it looks like. And then when we run that same app on mobile, that's what it looks like. So it's the same routes, the same layout, and everything. So let's make a change. Welcome React Berlin. No, it's called React Day Berlin. So sorry. Forgive me. But make the change immediately. It's reflected on the web. And the same thing, again, immediately is then reflected on mobile. So you can see, like, that's powerful. Like, one command means you can run your app with the same routes, the same layout, the same navigation on both web and mobile. And I think, like, that existed this year. And I think, I mean, I'm really excited.

Now, another thing that you see in the ecosystem that people do is they actually decide to create specific frameworks for each of the different platforms. So they use different frameworks for each of the different platforms. For example, you can use Next.js on the web, and you can use Expo for the native side. And typically people kind of bootstrap this with a monorepo. They'll create a core package or a number of packages, and this includes all of your application logic. So it includes app configuration, state management, API calls, your UI components as well. So you're sharing UI components.

We've gone ahead, and we're sharing more and more. And also a navigation abstraction that sits on top of the different platforms that you have, and allows you to make the same navigation calls from the same screens, effectively. And then those are imported into a separate Next app and a separate Expo app. And so those apps are in charge of handling the navigation calls, the implementation of those navigations, but also the build and bundle processes. And so this is powerful for a very important reason, which is if you're using Expo router, you're using Metro, it's a bundler that's optimized for native, so it doesn't come with things like SSR or good tree shaking support. Here you can really, on the website, optimize and make performance optimal, because you're using all of the stuff and features that come with Next.js, which I think is powerful. So this is something that we see in practice quite a lot today when building universally.

Now we've talked about the good, we've talked about the state of the present, we actually want to talk about the bad and the ugly, as we said.

So one of the challenges today is that out-of-tree platforms have a very difficult time of staying in parity with React Native Core.

Now just a quick explanation. Out-of-tree platforms are the non-main platforms in React Native. So typically React Native Core ships with iOS and Android. Any of the other platforms are referred to as out-of-tree platforms. They're not maintained by meta, the community maintains them.

So this is something that we see in practice quite a lot today when building universally.

And if you see at the top, they have 168 open issues for parity with React Native. Now this is in no way whatsoever an indictment of the Microsoft folks who work on this. They do a phenomenal job. I'd say this is one of the best ones. It just shows how difficult it is to stay in parity with React Native Core.

And I have a hypothesis as to why this is. If you go into the docs of React Native and you open any of the components, let's just choose pressable, which is your typical button interactable component, you can see that there are some props like Android underscore disable sound or Android underscore ripple. So these are part of core React Native, but they're very specific platform implementations. Let's take another example, text. There's text break strategy. There's also line break strategy iOS. These seem like they should be just one prop. And I think what really you'll start to see is that React Native is actually currently tightly coupled to iOS and Android APIs. Which goes against the fundamental philosophy of React and React Native, which is that it should have a platform agnostic API. So there's a lot of efforts being done to clean this up and make it more lightweight so that it's easier for out of tree platform maintainers to stay in parity.

I think the second challenge and an important one is performance on the web. So performance on the web currently we said we have to use React Native web. And if you look at the bundle size for the React Native web package, it's about 250 kilobytes minified and about 75 kilobytes gzip. That's huge. You're adding this as a compatibility layer. So that's because it handles everything from JS animations to styling at JS runtime. It contains a whole lot of stuff that you really don't want to use on the web.

So what this effectively means is that you as the app developers will need to spend some time figuring out what you want to use from React Native web. Maybe removing some of the dependencies. Maybe patching some of it. But you can get to a good state with the performance. It's just it will require work. So it's something to consider.

So we've looked at the past. We looked at the present. What about the future? I think the future of Universal React really is in React Strict DOM. So earlier this year, Meta announced React Strict DOM as an approach to cross-platform React development that aims at solving that problem of sharing components across web and native. And this was by Meta. It wasn't a community effort like React Native web. But the difference was that they wanted it to have good performance on the web. So what React Strict DOM does is it leverages APIs that you, as web developers, will be using to build Universal apps. So with React Native web, the burden of translating and supporting those APIs was on the web app. React Strict DOM takes an almost opposite approach. It puts that burden of compatibility and translation of APIs on the mobile side and utilizes those web APIs that we're familiar with to render components. So by providing a subset of DOM APIs, which is kind of that column you see in the middle, right, we have this layer that translates them into both web and native environments. And this means that you can write code once and run it everywhere with minimal platform-specific modifications. So it embraces those DOM elements and integrates it closely with StyleX for unified styling to give us this approach of writing once running anywhere. And I think what's awesome is that Meta has also been dogfooding it themselves. And it's being currently used in production on Instagram and Facebook. And really to emphasize this again, React Native web was native first and then web second.

React Strict DOM is really making web a first class priority. In a similar vein, the community has been working on an effort to take web APIs, so W3C spec compliant APIs and move them into React Native and give them support. And that's because a lot of the APIs that you can use to access device information and so on and so forth in React Native are community-led and they're not standardized. Whereas the web is very mature in this space. So the whole idea, and this is backed by the folks at Microsoft, is that we can bring some of those web APIs and it makes it easier for web developers to be able to access the same APIs but with native implementations on the native side.

And I think this is incredibly important. It's two parts of the same puzzle. And, of course, React Native just launched their new architecture that they've been working on for I think six years now. And part of that, which is underrated and not talked about as much, is this new event loop. So the event loop in React Native was unstandard. It didn't behave the same way as web. So if you used something like a use layout effect, it would actually behave quite differently on native as it would on web. And so this new event loop basically patches that and standardizes it and aligns it with web. And you see what this convergence is on the rendering side, on the API side, and even on the internals of React Native, it's becoming closer and closer with web. There's a convergence. Those parallel lines and those ecosystems are gathering together and converging. And so things are becoming more unified and, dare I say, they're becoming more universal.

So what I think we're really moving to is this era of React One that's run everywhere. And this is because React is not just web. And React Native is not just mobile. Rather, React is a desktop framework. React can be used to build TVs. TV apps, not TVs. Maybe TVs. I don't know. React can be used to build AR and VR apps. And yes, React can also be used for web. And it can also be used for mobile. Ultimately... What we're trying to say is React is universal.

So if you're interested to read a bit more about this, there's a QR code there. Myself and a colleague of mine actually wrote a booklet about universal first apps, which is the way that you architect your app from the ground up to be universal. So this is just a PDF. You can scan it. And hopefully that's some reading. And I'm more than happy to chat with you about it later on.

Thank you, guys, so much. We really hope you guys start using universal React apps. And these are our socials. So if you want to follow us or ask any more questions, me and Mo are here. Thank you. Thank you so much. Thank you so much.

Before we do that, folks, how are you feeling? Good talk? Good talk? We're getting off bounced off of each other. And you were being a bit mean on the age thing there. Come on. It's really rude. Come on. Yeah. No ageism here. It's an inside joke. Let me clarify. It's an inside joke. We're joking. We're joking. But super excited to jump into these questions.

And I'm just gonna jump straight in with the most upvoted question, which is about React. It's rarely used just as React. But it's used in a framework, Next.js, Remix, and a thousand other flavors. So how do you make a Next app or a Remix app universal while not rewriting from scratch? So there's a few efforts here that can help you. First thing that I can mention is expodom. So Expo's been working on an effort where you can almost with web views take existing web code and start to bring them into the native. They're not gonna be native components. But it's almost a bridge and a path to migration from web to native. I think really your best friend here is the monorepo story, or finding a way to abstract and package a lot of these dependencies away. So React strict DOM is also coming into place, which means you can take a lot of those web codes that you have in Next.js or Remix and so on and so forth, and put them and adapt them with React strict DOM very soon, and then put those in packages that are imported by, let's say, your Next app, and then also by your native app. And so I think there's a lot of things on the horizon.

And the last one, dare I say, is the spooky world of generative AI. Like, I've done a few experiments. You can use genAI very well to convert HTML to React native code with views and text. It does phenomenally. Like, it gets 90% of the way there, and then it's just a manual work. So use LLMs where it makes sense, and I think this is one of the places where it does.

That makes sense. The next question is about the impact on performance. Sorry, I thought accessibility was here, but this one just jumped up. So what's the impact on performance of taking a universal React approach? How does it help performance, hurt performance, especially on each individual platform? Yeah, so I think we tried to touch on it a little bit. But yeah, with React native web, it is a big bundle, and that pressure is on the web to translate everything. But I think with React strict DOM, it is built with performance in mind. So it hasn't been built just to improve performance on web. It's been built to improve performance across the board. So if you look at the docs for React strict DOM, that is one of the principles, is we're building React strict DOM to improve performance, to improve the way that we build in React and React native works.

Just to add on that as well, part of what you will need to keep in mind is the dependencies that you use. Create different dependencies and implementations of components like Anisha showed with Ziggo that are optimized for web and don't load a bunch of crap that you don't need, and work well on native as well. And you have to choose the dependencies and sometimes create abstractions on top of dependencies. And that way you don't inflate your bundle size and don't hurt the web performance. On native, it doesn't have that much of an effect because those are the same React native libraries that you would be using anyway.

On native, it doesn't have that much of an effect because those are the same React native libraries that you would be using anyway. Okay. The next question is about accessibility. So making performance accessible apps on the web often requires using very, very specific APIs. And when you have this multiplatform abstraction, are you able to reach the same quality bar in terms of performance? We talked about performance already, but and accessibility. That was one of the primary focuses of React Native Web. So one of the things that they really wanted to achieve as a goal was covering the full surface area of web accessibility specs that you have. And so you get access when you're using React Native Web to all of the same sort of equivalent or the same accessibility tags that you would use with any React application. And I think it's the same with React Strict DOM, like, their principles was, yeah, performance accessibility and in the design, like, accessibility is the first thing they're trying to make sure is the same. Yeah. Totally.