React Strict Dom: Cross-Platform React Based on the Web

Today I'm going to talk about cross-platform React and specifically, a way of using React where web APIs describe not just web apps, but also native apps. The meta, the library behind this approach is called ReactStrict DOM. In the first part of this talk, I'm going to make the argument that although React for web and native has been an incredible success, it's also being held back in some ways. But by unifying the best of React on the web and native, we can unlock new value, new possibilities.

In the second half, I'm going to share the impact that cross-platform React is having at meta and how it fits into a future where cross-platform software engineering is rapidly changing. So I want to start out with a little bit of background so you can see where I'm coming from. React's declarative component model has changed how we build UIs. It's been 15 years since React's release and is probably the most popular UI library in the world. But the React technology stack remains remarkably fragmented, both within the web community and between web and native communities.

The first thing you have to do with React is choose which platform to target, and then learn a specific set of APIs for that platform. And this fragmentation leads to hidden inefficiencies and often forces us into tough trade-offs. On the web, React DOM gives developers a lot of freedom, but before you can write your first line of UI code, you're required to make several fundamental project-defining choices. Most notable for UI is the choice of how to style elements. You might use CSS modules, utility CSS, CSS and JS. There are many options, and every project is the potential for a new debate.

React on the web might be the only significant UI library left with no built-in component native styling system. And the result is significant inconsistencies between code bases and a lack of truly portable UI code. So, React's flexibility on the web has become a double-edged sword that has increased fragmentation and raised the barrier to entry for newcomers. And if your product succeeds, and you want to go native, you hit another fork in the road. React Native is a different API, and your web code and knowledge don't transfer that easily. You need to learn new elements, new styles, new paradigms, and more often than not, React Native apps are rebuilt from scratch.

And this isn't just a web-to-native problem, because many React developers start first with React Native and face similar challenges when moving to the web. And that's because there's no common way to describe and build React apps, even on a single platform. And this technical fragmentation has long been a tax on React developers and a source of community fragmentation. It's also clear that this fragmentation is becoming a significant drag on our ability to best leverage emerging technologies like LLMs in UI engineering. Doing similar work more than once, often with separate teams and code bases, is correlated with a slower time to market, greater product inconsistency, reduced engineering efficiency, and now excessive LLM token use and its corresponding compute costs.

So, this isn't simply a technical problem anymore, but also a product and business problem. But what if we could unify and standardize these different React worlds? Just one way of using React to build UI across all platforms. No more forks in the road, no more choosing between one platform and another, and no more duplication of common tasks that are universal to UI development. These were my motivations for creating React Strict DOM to unify the way we describe UI with React. It's not a replacement for React DOM or for React Native. Instead, it's built on top of them. And it lets us develop a consistent product vision across platforms, while still delivering platform native experiences.

But to understand how and why we're having success with React Strict DOM at Meta, I first want to talk about some other ideas we tried and why they fell short. There are several potential approaches to cross-platform React, and each one teaches us something important about what works and what doesn't. The first thing that we can consider is using React Native's components and APIs to build cross-platform apps, including for the web. React Native for web already exists, and it's been around nearly as long as React Native itself. It implements many of React's components and APIs for the web, and it's part of Expo, the default React Native framework. But it's not the right solution to this problem. Three things make it impractical. The first, running existing React Native code on the web doesn't produce the accessible and responsive experiences that we want. Not without substantial rework of the original Native code. Second, the majority of React code out there is already written for the web. So, adopting React Native for this task would mean asking React engineers to switch to a less familiar API. And the third is that React Native's component API hasn't evolved much over the past decade, and it never became a common choice among web developers.

But what works really well with React Native is its styling system. That's enabled an ecosystem of portable and composable components that just work together in a way that's never been true for React on the web. So, I think that that's something worth keeping. Another approach is to build new cross-platform UI components, different from both React DOM and React Native, where the implementation details for each platform are different. For example, we could start by replacing div with a new cross-platform flex box abstraction like VStack. And although this is an option for individual apps looking to use high-level abstractions, it doesn't really work as a foundational layer, and at Meta, it was too problematic for existing apps. Because we had to design, build, and introduce significantly different abstractions and make major changes to existing web code, both of which dramatically increased visual regressions.

So, how can we find a way to minimize the migration costs while still getting the value of code sharing? Instead of pursuing an approach that requires rewriting code, we can revisit an idea that's often discarded as being unrealistic. And that's using our existing web code to build native experiences. Because our web code already describes how we want an accessible and responsive multimodal interface to work. So, we must be able to render our web code on native as is with minimal changes. And we must be able to migrate existing components in a way that's safe, reliable, and fast, taking minutes rather than weeks. And although we want to write once and run everywhere, we must still deliver a top-tier experience on every platform.

And although we want to write once and run everywhere, we must still deliver a top-tier experience on every platform. So, even if we're using web APIs, native apps must still look and feel native because the UI must truly be native. So, we want web developers who make up 90% of the React ecosystem to be able to build native apps and use the APIs they already know. So that people can rely on their existing knowledge of the most widespread and well-documented APIs of any platform, the web platform. This approach requires no major retraining, which is a huge win. Because we just unlocked the potential of people's existing knowledge and skills.

We also want to expand React Native's potential audience to include web developers by standardizing on web APIs. The new architecture of React Native makes this possible. And that was previously out of the question. So, we avoid the need to invent and maintain a separate set of native-specific components and props. And this, in turn, should allow React Native to focus on its unique strengths, like the rich native code integrations that only React Native can deliver. So, React Strict DOM ties these different strands together so that we can use existing web code on native today. It doesn't try to fake one platform and another. Instead, it creates a shared interface between them.

And it does this by exploiting two main modules, HTML and CSS, that connect React Native and React DOM. The HTML module is a cross-platform subset of the components you already know from React DOM. And the CSS module is an enhanced cross-platform version of the style sheet API from React Native. On the web, React Strict DOM intentionally does very little. The components look nearly identical to those in React DOM. And there's no runtime overhead. The differences from React DOM are small but deliberate. Props are strictly typed. And the style prop works like it does in React Native, providing encapsulated and predictable styling. On native, there's more work happening.

We map web APIs to native APIs. And even component instances have most of the properties and methods that you'd expect from HTML elements. Despite rendering to native use. The rendering stays true to each platform. Web still produces HTML. And native apps still produce native elements. The styling system preserves key features from React Native, like style encapsulation and predictable merging.

So, when you compose style components with React Strict DOM, you know what you'll get. That's been standard in React Native, but harder to achieve on the web. React Strict DOM combines the best of the web and native styles. The constraints from native that provide this encapsulation and reliable composition, and the broader CSS capabilities that you're used to from the web.

All of this work to create a shared interface based on the web means that we can now easily transform lots of our existing web code to make it work on native. We use AST transforms to automatically convert React DOM code to React Strict DOM, and AI-assisted code mods for more complicated conversions. While some manual refactoring is still required for edge cases, code migration has become relatively easy to automate. The difficulty of the work to transform styles will vary depending on the style library that you start with. But once that's handled, the rest of the journey is pretty easy.

And all of this lets us reproduce React web components on native more accurately than ever. React Native doesn't support everything we need just yet. React Strict DOM polyfills web capabilities, like CSS custom properties, inheritance, relative units, transitions, and more. About half of the available APIs are polyfilled in some way. This helps us bring the power and familiarity of the web to native platforms without waiting for every feature to be built natively.

All of this work to create a shared interface based on the web means that we can now easily transform lots of our existing web code to make it work on native. We use AST transforms to automatically convert React DOM code to React Strict DOM, and AI-assisted code mods for more complicated conversions. While some manual refactoring is still required for edge cases, code migration has become relatively easy to automate. The difficulty of the work to transform styles will vary depending on the style library that you start with.

The same approach also works for React Native components. Teams that want to migrate existing native components to the web can do so relatively easily because the styling model in React Strict DOM is so similar to the one in React Native. The goal for this code mod pipeline is for it to eventually be open source so that people who have invested in React Native and frameworks like Expo have a clear and viable path to adoption. Meta has been building cross platform apps this way for a couple of years now.

The goal for this code mod pipeline is for it to eventually be open source so that people who have invested in React Native and frameworks like Expo have a clear and viable path to adoption. Although our goal is to share as much code as possible, there are still cases where platform specific APIs or optimizations are needed. And for these, we just use platform specific file extensions to fork code and go fully native as necessary. If you've used React Native before, this is already a well established practice in that ecosystem. So, Meta has been building cross platform apps this way for a couple of years now.

The Facebook VR app shown at MetaConnect in 2024 was the first native app that we built from existing web code using React Strict DOM. And it made it possible for us to ship features faster with fewer engineers and to provide a more consistent Facebook experience across platforms. The app reused some of the most complex and robust features from Facebook.com, like NewsFeed and commenting system. By sharing code in this way, teams were able to spend less time on repetitive business logic and more time adding meta quest specific interactions and experiences. And what's notable isn't just that we reused web code, it's the resulting native app looks and feels almost indistinguishable from one built natively. And this proved to us that code sharing with the web doesn't have to mean a compromise on product quality of a native.

Facebook VR reuses about 60% of the files from the web. And even at this early stage, React Strict DOM is rendering 10% of dibs and 20% of spans on the Facebook.com home feed now. Meta is currently developing another major cross platform app that uses React Strict DOM. And that app makes extensive use of spring animations. So, we developed a cross platform solution for animations using React Strict DOM as well that we're also in the process of open sourcing. On the web, it's powered by the web animations API and on native, the core has been rewritten in C++. This allows us to design and engineer high quality performance animations that work across all platforms for the first time. This new app is also Meta's first cross platform React app built by engineers using AI coding assistance.

This new app is also Meta's first cross platform React app built by engineers using AI coding assistance. AI agents don't yet understand the specifics of React Strict DOM out of the box because it wasn't part of their training data. However, because React Strict DOM's API is intentionally very similar to React DOM, we only need to provide a small amount of extra steering to AI models in the form of instructions and dedicated skills. And this allows agents to adapt their existing knowledge of React DOM and CSS to generate cross platform code. Requiring only a single implementation has been a huge win when using AI coding assistance. Because cross platform code generation validation reduces the number of tokens needed in the input and the output, which in turn reduces compute costs and the time taken to complete a task.

So, unifying React code in this way has brought many benefits, especially for the web, but it also has a few tradeoffs at the moment. The most significant tradeoff is the runtime cost on native of polyfilling missing features in JavaScript. Adding these extra capabilities on native means that rendering a div is about half as fast as rendering a view. And although we found that this performance cost is generally acceptable, even on relatively low end hardware, we continue to find ways to do better. And in the last 18 months, we improved performance by about two and a half times. Over time, as more features are moved into native code and optimized, this gap will close, because we just won't be polyfilling so much in JavaScript.

So, that's the state of React Strict DOM today. And I'm gonna talk a little bit about what I think the future might look like. React Strict DOM is helping to figure out what parts of the web we want to bring to native. This kind of work has always required dedicated individuals who invest their time and creativity into problems like this. And today, people at Meta, Expo, Software Mansion, Callstack, and elsewhere are stakeholders in this vision. For us to get the most out of this technology, here's what I think needs to happen next. React Native needs to become a selective, high-performance web renderer for a subset of HTML, CSS, and the web. We currently support or emulate about 60% of the target API on native. But as we unify more features, we can close that gap between platforms and further increase the value of cross-platform React.

In the past, this seemed pretty implausible, but the people working on React Native have shown that now it's not only possible, but beneficial for us to do this. There's also more work to be done to deliver an integrated styling solution for React that works across platforms. We have a lot of feedback from Meta's internal teams, as well as interested parties like Vercel and Expo, that we want to incorporate into future iterations of this API. React's future styling solution needs to be as simple for people and AI agents to use as React Native's styling system has proven to be. And achieving things like this might even require changes to React itself. That's because our vision is not just about making another UI library. It's about consolidating our entire approach to building user interfaces with React. It's only possible now because of the accumulated progress across React, React Native, Hermes, Flow, Expo, and many other technologies. Because improvements to each part of this stack has multiplied the value of the others. So today, we can build things that would have been impractical just a few years ago.

From that foundation, we need to continue working towards a single canonical way to build UI with less fragmentation, less duplicate effort across platforms, and the kind of built-in styling system that React has always deserved. Because when there's one clear way to describe interactive interfaces, our tools, training, and investments can all compound in the same direction, and that's where the real value appears. We're also at a critical juncture in software development, where AI cogeneration is becoming a core part of UI engineering. For this to be successful at scale, I think generated UI must look and work the same across all contexts. Because inconsistent rendering or incompatible components severely undermine the promise of automation. The potential here for a library like React Strict DOM is enormous. We can unlock unified workflows for our teams and further efficiency wins by reducing the compute costs associated with generating cross-platform code. We're already seeing these benefits at Meta. Vibe coding platforms could also deliver more value at less cost, allowing these tools to expand their audience by generating apps that work on both the web and native platforms. By evolving our foundational UI libraries like this with clear universal APIs that LLMs can easily use, we can build user interfaces that better match the designer and developer intent, no matter the platform.

What I want you to take away from this talk is the following. The effort to create one React for both web and native is helping Meta build new cross-platform apps, and we think this is a key advantage for the future. Standardizing on the web lets us capitalize on the enormous existing adoption of React on the web and the API design work that's gone into the world's most ubiquitous application platform. When we constrain how we build, we can create trade-offs that work in our favor. Trading some flexibility to increase predictability is what lets us compose large systems with more confidence. React Native is a key part of this vision, and we need to build more capabilities if we want to deliver on this potential. And finally, the nature of generative AI should inspire us to make simpler and better frameworks that people using AI models can have more success with over the long term. So, if this is a future for React that inspires you, I encourage you to try a React strict DOM and help make this vision for React a reality. Thank you. Thank you so much for that great talk and this, you know, one React to rule them all.

I love this this feel. So, we have a few different questions coming in here, some of which are related to things like our kind of existing workflows. So, some folks are wondering, for example, how would something like Tailwind fit into this picture? Is it possible to use that with React strict DOM? Yeah, I've seen some people have already created Babel transforms over the top of React strict DOM that allow you to write a Tailwind-like syntax and then that gets compiled down to the kind of code that I just showed. So, I think the way that I've been thinking about this is really we want to try and create a foundational layer that then other things can be built on top of. And as long as they sort of conform to the, you know, the semantics of what we're trying to do here, then they'll be able to be built on top.

Great. Great. Okay. And so, I guess in terms of kind of best practices for building UI libraries using React strict DOM, how would you best structure design system component libraries that have common components for both web and native? Well, the goal is that you would kind of just write your web components and they would work on native. So, hopefully, everything that you already know about building UI libraries for the web would translate. And as I mentioned, if you do need to have special implementations just for web or native, using the platform specific file extensions is how you would separate those two. Gotcha. Gotcha. Until the rest of the features are all baked in and then you don't even have to do that. Amazing.

I guess we have another question here that is sort of a compare and contrast. What do you see the relationship being between progressive web apps and React strict DOM? Are they competitors? Do they solve different problems? Are they complimentary? What are your thoughts there? Yeah, I think they're different parts of the stack. So, if you're deploying to the web, you might still want to produce a progressive web app, but the way that you write your React components is sort of separate from that. So, this is really like a library for just avoiding this separation between React DOM and React native. Having just one way that you write React code, one way that we have to teach people and machines, and trying to take the best from both. So, we think that the ubiquity of the web platform is its strength, but some of its downsides, like the lack of encapsulated styling, doesn't really align with React's component model. So, this is an attempt to bring encapsulation of styles in, just like you have encapsulation of props and everything else. And so, that's basically how I see it. And it's quite different from whether to make it a progressive web app or not. Gotcha. Well, the people want to know, will this become part of React Foundations? I don't know. I mean, I guess we'll see whether things like React native end up as part of the foundation. But I think it's good to have something like the React foundation so that projects like this and other projects from the community have a home and a source of funding.

I mean, I guess we'll see whether things like React Native end up as part of the foundation. But I think it's good to have something like the React foundation so that projects like this and other projects from the community have a home and a source of funding. So, never say never. Yeah. I love getting funding for sustainable open source, just in general.

All right. We have the questions keep coming. Wow, you've really gotten, you've really sparked folks' excitement. So, don't forget that if you don't get a chance to get your question answered here, there will be a Q&A spot with the speakers after the talk outside of our beautiful planetarium today. All right.

Moving right along, how about electron apps? Do you think that there is still a place for other technologies like electron apps in the context of React strict DOM? Will we all be building differently? Well, I think the goal is really just to allow people to separate how I build my components in my app from how it's deployed or where it's deployed. So, you shouldn't have to make a decision beforehand of like, am I going to make a web app? Am I going to make a native app? Am I going to use electron? Am I going to use like web views or whatever? We want that decision to be separate from the code that you write to describe your application in the first place, so that it becomes like a secondary concern afterwards.

The ideal scenario is to have the flexibility to output the same app in various forms without the need to rewrite React code. This approach aims to provide option value for users to compare performance and suitability of different technologies like electron apps and native apps. It allows for exploration and tailoring solutions to individual use cases, offering a seamless transition for development and deployment choices.

Regarding the readiness of using React strict DOM in production apps, there is room for experimentation at different scales. The discussion also touches on the potential evolution of HTML syntax in a new compiler, emphasizing the importance of clarity and maintainability in code. The current separation of styling and elements in React DOM serves practical purposes, ensuring ease of transitioning between different code modes and facilitating reversibility of decisions.

The considerations for maintaining the existing structure of React DOM involve ensuring a smooth transition for developers and avoiding irreversible choices. By keeping elements distinct and providing mechanisms for easy migration, the framework aims to support adaptability and prevent constraints on development. These factors contribute to the current design philosophy, prioritizing user-friendly experiences and flexibility in technology adoption.

All right. And so, I guess there, yeah, there are a couple of questions around kind of the readiness that we can, can we start building with it right now? Can I go to my laptop as we speak and start putting React strict DOM already in brand new production apps, even at sort of a mid-scale sort of scale? Yeah, I mean, you could try. And get back to you with any feedback. Yeah. Amazing.

And now we're, yeah, now we're getting into the juicy questions. Can we get rid of the HTML syntax in a new compiler? Yeah. I mean, I think the reason that we have that is, you know, it's very confusing if you come into a file and it looks like code that you're writing before, but it behaves differently. Especially with the way that we have merged styling and the elements together, more like React native. So, I mean, I'm not going to rule out that in the future...

...if something like this really took off and it just made sense that, you know, say everyone's writing code this way, then maybe this would be what React DOM would look like by default. But I think at this stage it makes sense for us to keep them separate... So whenever we're working on things like this, we're always thinking about how to avoid it being a door that you go through that closes behind you and you can't reverse your mind, your decision.