Web: Tailwind (pair with shadcn/ui — RB-E-COMPONENT-LIBS). React Native: NativeWind if you want Tailwind, else StyleSheet/Unistyles. Prefer zero-runtime/compiler approaches on both.
RN needing TW4 parity with web today → Uniwind (stable, requires Tailwind >=4; NativeWind's v5/TW4 line is still RC)
design-system with variants/theming shared across web + native → Tamagui
RN-only design-system with variants/theming → Unistyles (3.4+ needs RN 0.81+; hold 3.3.x on RN 0.76–0.80)
Meta-style atomic CSS for a large web codebase → StyleX
web+native shared styling → React Strict DOM (RB-E-CROSSPLATFORM)
new web CSS-in-JS → StyleX, else another zero-runtime library (runtime libs pay per render; styled-components v7 is actively developed but still runtime)
Options & tradeoffs
the field considered — and why each one isn’t the default here
option
tradeoff
evidence
StyleSheet (RN)
built-in; manual theming
NativeWind (v4 stable; v5/TW4 RC)
Tailwind for RN; most-adopted (~1.3M dl/wk, npm API 2026-09-24). Stable 4.2.7 (2026-09-14) is the Tailwind v3-era line; the Tailwind-v4 line is 5.0.0-rc.0 (2026-09-13) on the preview/rc tags, not yet latest (verified vs npm 2026-09-24). See note: TAILWIND V4 ON RN
2.2M/wk
Unistyles
C++/Nitro styling engine; fast theming + variants. 3.4.0 (2026-10-01) raised the floor to React Native 0.81 (it now relies on ShadowNode::getFamilyShared()) — RN 0.76–0.80 stay on 3.3.x; 3.5.1 latest (verified vs the v3.4.0 release + npm peers react-native >=0.81.0)
287k/wk
Uniwind
Tailwind w/ C++ styling engine + animated themes, from the Unistyles authors; the stable Tailwind-v4 option for RN — 1.12.0 (2026-09-04, verified vs npm 2026-09-24) peers tailwindcss >=4 and react-native >=0.81. Pro is paid (~$99/seat/yr)
843k/wk · ships in 1/34
@mgcrea/react-native-tailwind
Babel-plugin / zero-runtime Tailwind — no JS-side styling overhead; micro-adoption (~1.1k dl/wk, npm API 2026-09-24). (The unscoped npm name react-native-tailwind is a dead 2020 package — don't cite it)
atomic compile-time CSS; sx={} prop; strong web story, RN support emerging; 0.19.1 (2026-09-15, verified vs npm 2026-09-24). First marquee non-Meta production adopter on record: Linear migrated off styled-components across 1,000+ PRs (see reading)
2.5M/wk
styled-components
runtime CSS-in-JS — avoid for new web work on the per-render-cost axis, not abandonment: v7 is in active prerelease (builds through 2026-09-08; stable 6.5.3, verified vs npm 2026-09-24) with RN-parity features, but stays runtime; prefer zero-runtime/StyleX
13.2M/wk · ships in 6/34
CSS-in-JS (web)
runtime cost; prefer zero-runtime variants
React Strict DOM
strict HTML/CSS compiled to static CSS on web + RN styles on native; see RB-E-CROSSPLATFORM
The durable selection axis is WHEN style work happens: runtime CSS-in-JS (styled-components, Emotion) serializes styles during every render, while compile-time and zero-runtime approaches (Tailwind, StyleX, the zero-runtime RN engines) move that work to the build. That is why the web default is Tailwind with shadcn/ui (RB-E-COMPONENT-LIBS) and why runtime CSS-in-JS is avoided for new work on cost, not abandonment. On React Native the Tailwind field is crowded ("Tailwind fatigue" — NativeWind, Uniwind, react-native-tailwind, …); choose on runtime cost and on which Tailwind major you need, not on novelty.
TAILWIND V4 ON RN (2026-09-24, verified vs npm): NativeWind's latest is 4.2.7 (2026-09-14), the Tailwind v3-era line; its Tailwind-v4 line is 5.0.0-rc.0 (2026-09-13) on the preview/rc dist-tags. Uniwind 1.12.0 (2026-09-04) peers tailwindcss >=4 and react-native >=0.81 → an RN app that needs Tailwind v4 parity with its web build today goes to Uniwind; NativeWind stays the pick for Tailwind v3-era RN work.
TAILWIND STEWARDSHIP (2026-09-09, verified vs Adam Wathan's announcement on the Tailwind blog): Tailwind Labs joined Shopify. "Nothing changes with Tailwind CSS or any of our other open-source projects": everything stays MIT-licensed and the same team leads and maintains it, now with Shopify's backing, for a framework installed over 110 million times per week → the web default holds. The commercial side closed: existing Tailwind Plus and ui.sh customers keep access, but sign-ups are closed to new customers, so a reader planning to buy Tailwind Plus for a component set should go to shadcn/ui (RB-E-COMPONENT-LIBS). Shopify leaving React Native is a separate thread (RB-E-LISTS, RB-E-ANIMATION own it).
WEB+NATIVE: react-native-web is in maintenance mode (2026); React Strict DOM is the emerging successor — RB-E-CROSSPLATFORM owns that thread.
HISTORY: 2026-10-08 REOPENED: Unistyles 3.4 raised its floor to RN 0.81 (3.3.x for RN 0.76–0.80). 2026-09-24 CORRECTED: NativeWind's v5/TW4 line is at RC (5.0.0-rc.0), not preview-only; StyleX is on 0.19, not 0.18; @mgcrea/react-native-tailwind is ~1.1k dl/wk, not <1k.
Canonical reading
Editorial annotations on why each piece matters — the articles themselves are the originals; read them there.
The first detailed non-Meta production migration TO StyleX, and the most useful part is the selection criteria, not the endorsement. Linear's non-negotiables: generate styles at BUILD time, make styling-at-a-distance deliberately hard (not just discouraged by convention) while still letting components expose explicit styling contracts, predictable cross-file merge without specificity games, and — stated as a first-class criterion — agent ergonomics. vanilla-extract was the runner-up (static extraction, strong types) and lost on API fragmentation and the component/style file split; StyleX won on colocation, a small API, and deterministic resolution. The honest tradeoff is stated too: parent-dependent selectors, global selectors and restyling-through-wrappers all get harder, which is the point but is also the migration cost. What pushed them off styled-components was a performance regression after the React 18 concurrent-rendering upgrade plus styled-components entering maintenance mode. Measured payoff, isolated as best they could: removing runtime style injection cut main-thread CPU for style work ~20–35% on view-heavy pages (~30% faster on a mid-tier machine), and a navigation went from injecting hundreds of CSS rules to zero. Two process lessons that generalize past StyleX: a deterministic CODEMOD carried the bulk (styled-components is Turing-complete, so agents produced plausible-but-wrong output early on — model capability only made agents the better tool partway through the project), and the end state is held in place by tooling — Oxlint rules for the fast local checks plus a custom TYPE-AWARE repository checker that traces sx through wrappers and polymorphic components to catch conditional styles silently dropped across boundaries. They kept CSS Modules as an explicit escape hatch for genuinely CSS-shaped problems (global selectors, third-party DOM) and extended StyleX for runtime-generated theming rather than fighting it.
The canonical runtime-cost argument against runtime CSS-in-JS, from an Emotion maintainer: per-render style serialization is slow (a benchmark shows ~48% faster renders after dropping Emotion). Motivates the move to compile-time / zero-runtime styling.
Architecture explainer for the leading zero-runtime approach: a Babel compiler extracts styles into deterministic atomic CSS at build time (no runtime injection), resolving specificity/shorthands at compile time so CSS size stays flat at scale.
First-hand account of a large production CSS-in-JS to StyleX migration: build-time vs runtime styling, ~30% nav improvement, and agent-driven codemods at 100k-line scale. The migration companion to the runtime-cost argument above.
The Linaria maintainer's own verdict on the category: runtime CSS-in-JS is winding down, and two foundational Linaria issues can't be fixed without breaking its core design — so Linaria stays maintained but frozen (NOT deprecated), and his successor dx-styles (zero-runtime on wyw-in-js, RSC-compatible, typed recipe variants, token contracts) ships with a Linaria migration guide. Supersession-in-progress: watch dx-styles, no migrate rule yet.
The comparative map this entry's options list lacks: where every live zero-runtime option actually sits — Linaria (maintained, frozen), next-yak (Rust compiler over styled-syntax, RSC-compatible), vanilla-extract (the TypeScript answer to CSS Modules, typed themes), Panda CSS (config-first, atomic output), StyleX (Meta's, strict constraints + deterministic merging), Griffel (Microsoft/Fluent UI, limited ecosystem interop), and dx-styles itself. Routes by situation rather than ranking: big styled-components codebase → next-yak or Linaria; typed styles with little setup → vanilla-extract or Panda; design system → dx-styles or vanilla-extract; hundreds of teams → StyleX; pragmatic → Tailwind or CSS Modules. The category has CONVERGED on plain class-name output, so the live differences are atomicity, authoring style and design-system features — not runtime cost, which the readings above already settle. KEPT ON THE 2026-08-04 ADVOCATE PASS after three cap-skips: recurring in three sources at once, and it is the only piece here covering the field rather than one library.
Depth (in-domain rules) is owned by the design-system skill — this entry is selection breadth.
The full explanation
The reviewed long-form essay behind this entry — the why, not a how-to. Also on GitHub.
About styling & theming in React & React Native
Diataxis: Explanation. This page builds understanding of the styling decision — the
reasoning behind the pick. It is not a tutorial: the candidate list and one-line tradeoffs
live in the index entry RB-E-STYLING; design-token, theme-parity, and accessibility-
intrinsic depth is owned by the design-system skill. Read this for the why.
The one axis that organises everything: when styles are computed
The styling field looks crowded and fashion-driven, but one durable axis cuts through it:
when does style work happen — at build time or on every render?
Runtime CSS-in-JS (styled-components, Emotion) serialises styles during render. It's
ergonomic and dynamic, but the cost is real and per-render — the canonical write-up is an
Emotion maintainer's "why we're breaking up with CSS-in-JS," which measured ~48% faster
renders after dropping it (see sources).
Compile-time / zero-runtime (StyleX, Tailwind, zero-runtime RN engines) moves that work
to the build. Styles become static CSS (web) or precomputed style objects (native); the
render path just references classes/ids.
So the first question isn't "which library is trendy" — it's "am I paying for styling on
every render, and do I need to be?" For new work, the low-regret answer is no: prefer
compile-time/zero-runtime approaches. (The exception is genuinely dynamic, per-instance
styling, where some runtime cost is intrinsic — but that's a small fraction of most apps.)
The default, and why
Web: Tailwind (paired with shadcn/ui — RB-E-COMPONENT-LIBS). React Native:
NativeWind if you want Tailwind, else StyleSheet or Unistyles. Prefer zero-runtime /
compiler approaches on both.
On the web, Tailwind + shadcn/ui is the boring-but-correct product default: utility
classes are compile-time by nature, and shadcn gives you owned, Tailwind-styled components.
For atomic CSS at scale (large design systems, many engineers), StyleX — Meta's
build-time atomic-CSS compiler — is the heavier-duty choice, keeping total CSS flat as the
app grows. On React Native, StyleSheet is the zero-dependency baseline; NativeWind
brings Tailwind; Unistyles (a C++/Nitro styling engine) gives fast theming and variants.
The connecting thread is the runtime-cost axis above.
The landscape, and when each one wins
Tailwind (web) — utility-first, compile-time, enormous ecosystem; the default, especially
with shadcn/ui. Its critique ("class soup") is real but a readability tradeoff, not a runtime
one.
StyleX (Meta) — build-time atomic CSS with an sx={}-style API; deterministic, dedup-
ed classes so CSS size stays flat at scale. Strong web story, RN support emerging. Pick it
when you're Meta-shaped: large, design-system-driven, many contributors.
NativeWind / Unistyles / Uniwind / react-native-tailwind — the (crowded) RN field.
"Tailwind fatigue" is real here; the durable selection axis is again runtime cost.
NativeWind is the most-adopted Tailwind-for-RN; Unistyles moves styling into a C++/Nitro
engine for fast theming and variants; zero-runtime/Babel-plugin variants avoid JS-side style
work entirely.
Which Tailwind major (verified vs npm 2026-09-24). NativeWind's stable line (4.2.7) is Tailwind
v3-era; its Tailwind-v4 line (v5) is still a release candidate. Uniwind (from the Unistyles
authors) is the stable option that requires Tailwind >=4 — the pick when an RN app needs Tailwind
v4 parity with its web build today.
Stewardship (2026-09-09). Tailwind Labs joined Shopify; Tailwind CSS stays MIT-licensed under the
same team, so the web default holds. Tailwind Plus and ui.sh closed sign-ups to new customers —
reach for shadcn/ui (RB-E-COMPONENT-LIBS) for an owned component set instead.
Tamagui — a cross-platform design-system + optimizing compiler; a batteries-included route
when you want a component system with theming, not just primitives (also RB-E-CROSSPLATFORM).
styled-components / runtime CSS-in-JS — still runtime CSS-in-JS. It's actively
developed again (v7 prerelease builds through 2026-09-08, RN-parity features) — but v7 stays runtime, so
the advice is unchanged: don't place a new web bet on runtime CSS-in-JS — prefer zero-runtime
or StyleX.
React Strict DOM — strict HTML/CSS compiled to static CSS on web and RN styles on native;
it's simultaneously a styling strategy and a code-sharing one (RB-E-CROSSPLATFORM).
Tradeoffs and failure modes to name out loud
New runtime CSS-in-JS bets. Choosing styled-components/Emotion for a new web app in
2026 buys a known per-render cost — the objection is architectural (runtime style work),
not abandonment. Reserve runtime CSS-in-JS for genuinely dynamic styling that can't be
precomputed.
"Tailwind fatigue" as a decision driver. The RN field's churn (NativeWind vs Uniwind vs
…) tempts novelty-driven choices. Decide on the durable axis (runtime cost, theming model),
not the newest entrant.
Re-deriving the design system in CSS. Tokens, theme parity (light/dark, dynamic type),
and accessibility intrinsics (contrast, focus) are a systems concern — owned by
design-system, not by the styling library choice. Don't hand-roll them per
component.
Web+native styling as an afterthought. If you share UI across platforms, styling and
code-sharing are the same decision (React Strict DOM) — see RB-E-CROSSPLATFORM.
How it interacts with the rest of the stack
Component libraries (RB-E-COMPONENT-LIBS). On the web, styling + components is usually
one decision: Tailwind + shadcn/ui. This entry is "how styles are computed"; that entry is
"where the components come from."
Cross-platform (RB-E-CROSSPLATFORM). React Strict DOM is both a styling and a sharing
strategy; the two entries describe one tool from two angles. (react-native-web is
maintenance-only; don't place new shared-UI bets on it.)
React core (RB-E-REACT-CORE). The React Compiler weakens the old "a styling lib avoids
re-renders" argument for client concerns; choose styling on the runtime-cost and theming
axes, not as a memoisation workaround.
Ignore the fashion and watch one axis: when styles are computed. Runtime CSS-in-JS pays on
every render (even an actively-developed styled-components v7 stays runtime), so for new work prefer compile-time /
zero-runtime: Tailwind + shadcn/ui on the web (StyleX when you need atomic CSS at scale),
and NativeWind or StyleSheet/Unistyles on React Native. Share styling with code via React
Strict DOM when you go universal, and push tokens, theming, and accessibility down to
design-system rather than re-deriving them per component.
See also: RB-E-COMPONENT-LIBS (Tailwind + shadcn on the web), RB-E-CROSSPLATFORM (React
Strict DOM as a shared-styling strategy), RB-E-REACT-CORE (Compiler interaction). Tokens,
theme parity, a11y intrinsics: the design-system skill.
react-brain