React Strict DOM: one styled component tree for web and native

The duplication problem RSD is aimed at

A team that ships a React product on both the web and React Native usually maintains two component layers. The web layer renders div and span with CSS. The native layer renders View and Text with StyleSheet objects. The two drift apart, and every design change is applied twice.

React Strict DOM, abbreviated RSD, is a set of packages that let a component be written once with a shared set of styled primitives and then compiled for each platform. The README frames the goal as improving the speed and efficiency of React development "without compromising on performance, reliability, or quality", and states that building with RSD is helping teams at Meta ship features faster, to more platforms, with fewer engineers. That is a claim from the project itself, not an independent measurement. There is no published user count or benchmark in the README or the repository files.

The audience is narrow on purpose. RSD assumes you already write React, already target React Native somewhere in your product, and are willing to adopt a style system that is not plain CSS and not plain StyleSheet. A web-only team gets nothing from it.

What is actually in the monorepo

The repository is a development monorepo, not a single library. The README lists four top-level directories: .github for workflows and issue templates, apps for example applications, packages for the published and internal packages, and tools for pre-commit tasks and similar.

The packages directory is where the substance lives. It contains react-strict-dom, the package most users would install; postcss-react-strict-dom, a PostCSS plugin; benchmarks; scripts; and website. The apps directory holds example-ui, expo-app, nextjs-app, vite-app, and platform-tests. Those five apps are the clearest signal of intended usage: an Expo build, a Next.js build, and a Vite build are all treated as first-class targets, and platform-tests exists to check behavior across them.

That layout also tells you what the project is not. There is no separate CLI package, no component library package, and no design system. RSD supplies primitives and a compilation step. Anything above that, you build or import from elsewhere.

The mechanism: styles compiled per platform

RSD's core idea is that a styled component declares styles in a JavaScript object, and the toolchain turns that declaration into whatever the target platform needs. On the web side, postcss-react-strict-dom is the piece that participates in the build: it is a PostCSS plugin, so it runs inside the CSS pipeline that Vite or Next.js already has. On the native side, the same declarations are consumed by the react-strict-dom package and resolved against native style rules.

The practical consequence is a constraint, not a feature. Because one style object has to be expressible on both sides, RSD cannot accept every CSS property. The docs site is the reference for what is supported, and the README does not reproduce that list. Anyone evaluating RSD should read the supported-properties documentation before designing components, because a property that exists in CSS but has no native equivalent is exactly the kind of thing that will fail at build or render time rather than degrade gracefully.

The second consequence is that RSD is not a runtime shim. It is a compilation and resolution layer, which is why the repository ships a PostCSS plugin and platform tests rather than a single runtime package.

Installing react-strict-dom and running a first example

The README does not give an install command. It points to the monorepo layout and to the docs site, and the published package is named react-strict-dom under packages/react-strict-dom. The most reliable starting point is therefore the example applications rather than a from-scratch install.

Clone the repository and install the workspace dependencies. The root package.json defines a postinstall script that runs patch-package, clears the Jest cache, and then builds every workspace, so a plain install does a lot of work:

npm install

The root scripts are the entry points for checking that the checkout is healthy. test runs Flow, ESLint in report mode, and Jest across the workspaces:

npm run test

If you want to see RSD in a real app rather than read about it, the Vite example is the lightest of the three framework apps. The README links it as apps/vite-app:

cd apps/vite-app
npm run dev

What you should see is a dev server for a React app whose styles come through the RSD pipeline rather than through hand-written CSS files. For a native target, the README links apps/expo-app, which is the Expo-based example, and apps/nextjs-app for the Next.js case. The repository also carries a benchmarks package, but the README does not publish its results, so treat it as a harness you can run yourself rather than as evidence of anything.

Where RSD is the wrong tool

The version numbers are the first limitation. The most recent releases listed are 0.0.54, 0.0.53, and 0.0.52, in October 2025. A 0.0.x line means the maintainers have made no stability promise. Any team that needs a frozen API for a multi-year product should read that as a warning rather than a formality.

The second limitation is the style surface. RSD's whole value depends on a shared subset of style properties that both web and native can express. If your design leans on CSS features outside that subset, you will either work around them or keep a platform-specific escape hatch, and once you have escape hatches the single-tree benefit shrinks. The README does not document what happens when an unsupported property is used, and the docs site is the only place that lists what is supported.

The third limitation is ecosystem. RSD does not ship a component library. A team that currently depends on a mature web component library, or on a large set of React Native community components, will find that RSD gives them primitives and a build step, not replacements. The repository's own apps are examples, not a kit to import.

Finally, the README is a monorepo README. It covers structure, contributing, the code of conduct, and the MIT license. It does not document rollback, migration from an existing StyleSheet codebase, or performance characteristics. If any of those matter to your decision, the README does not answer them.

RSD versus React Native Web

The obvious comparison is React Native Web, which people also search for alongside RSD. The two solve an adjacent problem from opposite directions.

React Native Web takes React Native components and style objects and renders them to the DOM. You write in the native idiom and the web is the output target. RSD instead defines its own styled primitives and compiles them for both targets, with a PostCSS plugin handling the web CSS side. The practical difference is where your existing code sits. If you already have a React Native codebase and want it on the web, React Native Web matches that direction. If you are starting from a web React codebase and want to reach native without rewriting the styling layer, RSD's direction is the one that fits.

Neither is a drop-in for the other, and the README and repository files say nothing about interoperation between them. That is worth confirming before committing either way.

Maintenance, licensing, and what an upgrade costs

The repository is not archived, and the last push was on 2026-08-31. Development is ongoing.

The release cadence visible in the release list is fast: 0.0.52, 0.0.53, and 0.0.54 landed within four days of each other in late September and early October 2025. A cadence like that in a 0.0.x line means upgrades are frequent and each one is a small risk. Pinning an exact version and reading the release notes before moving is the realistic posture, and the repository does not describe a deprecation policy or a support window for older releases.

Licensing is straightforward. RSD is MIT licensed, and the LICENSE file sits at the repository root. MIT permits commercial use and modification with the copyright notice retained. That is a factual description of the license text, not legal advice; if your organization has specific obligations around attribution or patent terms, have counsel read the file.

The contribution path is documented rather than implied. The README links a contributing guide on the docs site, and the repository expects participants to follow Meta's open source code of conduct.

Editorial conclusion

React Strict DOM is worth a look for teams already shipping React on both web and React Native, and who want one styled component tree instead of two. It is not the right choice for a web-only product, for a team that depends on a mature component library, or for anything that needs a stable API today, since the published versions are still in the 0.0.x range. Before adopting it, check the apps/example-ui and apps/expo-app directories in the repository, confirm which version of the react-strict-dom package you would pin, and read the docs site at react.github.io/react-strict-dom for the current list of supported style properties.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. react/react-strict-dom on GitHub
4. README
5. Releases