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.
design-system with variants/theming → Tamagui or Unistyles
Meta-style atomic CSS at scale → StyleX
web+native shared styling → React Strict DOM (RB-E-CROSSPLATFORM)
new web CSS-in-JS → avoid runtime libs on the per-render-cost axis (styled-components v7 is actively developed but still runtime); use zero-runtime/StyleX
RN needing Tailwind v4 parity with web today → NativeWind stable is TW3-era and its v5/TW4 line is preview-only; Uniwind (from the Unistyles authors, requires TW>=4) is the stable TW4 option
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 preview)
Tailwind for RN; most-adopted (~1.3M dl/wk) — but the stable line is Tailwind v3-era; the Tailwind-v4 line (v5) is preview-only
1.5M/wk
Unistyles
C++/Nitro styling engine; fast theming + variants
222k/wk
Uniwind
Tailwind w/ C++ styling engine + animated themes; Pro is paid (~$99/seat/yr)
286k/wk · ships in 1/34
@mgcrea/react-native-tailwind
Babel-plugin / zero-runtime Tailwind — no JS-side styling overhead; micro-adoption (<1k dl/wk). (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
1.4M/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 (2026-06, RN-parity features) but stays runtime; prefer zero-runtime/StyleX
9.4M/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
Web+native: react-native-web is in maintenance mode (2026); React Strict DOM is the emerging successor (see RB-E-CROSSPLATFORM). The Tailwind-for-RN field is crowded ("Tailwind fatigue" — NativeWind, Uniwind, react-native-tailwind, …); the durable selection axis is runtime cost — zero-runtime/compiler approaches avoid JS-side style work.
Canonical reading
Editorial annotations on why each piece matters — the articles themselves are the originals; read them there.
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-systems-governance 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-systems-governance 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.
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, 2026-06, adds 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-systems-governance, 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-systems-governance 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-systems-governance skill.
react-brain