DEV Community: Anton Evzhakov

The state of zero-runtime CSS-in-JS, mid-2026

Anton Evzhakov — Mon, 27 Jul 2026 05:57:41 +0000

Two disclosures before the map. I maintain Linaria, and I built dx-styles, one of the libraries below. You are reading a biased cartographer. The bias is labeled, the facts are linked, and corrections are welcome: file an issue and I will fix the map loudly.

How we got here

For most of a decade, CSS-in-JS meant a runtime: styled-components and Emotion computed styles during render and injected them into the document. It was a great authoring model, and it worked because React rendered synchronously on the client and nowhere else.

Then React changed shape underneath it. Concurrent rendering made render-time style injection a performance liability. Server Components made client-side style runtimes structurally awkward: there is no good place to inject styles from a component that never ships to the browser. The ecosystem read the signals. styled-components went into maintenance mode in March 2025. MUI started Pigment CSS as a compile-time successor for its own needs, then put it on hold in alpha. The default advice became "just use Tailwind," which is fine advice for many teams, though the surveys describe a complicated relationship: State of React 2025 calls it love/hate, and "excessive Tailwind usage" is the only framework entry in State of CSS 2025's general pain points.

What survived on the CSS-in-JS side is the branch that never needed a runtime in the first place.

Why compile-time is the branch that lived

The idea is old and simple: styles written in JS or TS are data, and data can be evaluated at build time. The compiler runs your style declarations during the build, writes real .css files, and leaves plain class-name strings in your JavaScript. Nothing injects anything at runtime, there is no provider, and nothing needs to cross the Server Component boundary, because by the time React runs, styling is just strings.

You keep the parts people actually liked about CSS-in-JS: styles colocated with components, typed values, tokens as code. You pay for it with a build step and with discipline about what can be statically evaluated. That trade is the whole category.

The map

vanilla-extract is the TypeScript answer to CSS Modules. Styles live in separate .css.ts files, themes are typed contracts, and the recipes package covers variant-driven components. It is mature, stable, and predictable. The main friction is the file split: styles do not live in the component file, and some teams never stop missing that.

Panda CSS is config-first and atomic: you describe tokens, recipes, and patterns in a config, a codegen step produces a styled-system folder, and output CSS is deduplicated utility classes. It has the richest ecosystem in the category and reads familiar to people coming from Chakra. The costs are the codegen artifact in your repo and the atomic model itself, which is a real trade-off rather than a free win: great dedup at app scale, opaque class soup in DevTools.

StyleX is Meta's production system: atomic output, strict constraints, deterministic merging, designed for codebases with thousands of contributors. The constraints are the feature. If your problem is "hundreds of teams keep overriding each other's styles," StyleX solves something almost nothing else solves. If your problem is smaller than that, the constraints mostly show up as friction.

next-yak takes the opposite entrance: keep the styled-components authoring model, compile it away. A Rust compiler turns styled syntax into static CSS, dynamic props become CSS custom properties, and the result is RSC-compatible with production numbers to back it at Digitec Galaxus scale. If you have a large styled-components codebase and want off the runtime without a rewrite, this is the newest of the two direct paths, and the fastest-building one.

Linaria is the original zero-runtime library and the reason half this category exists. It was built as a drop-in replacement for styled-components, and it still is one: the same styled syntax, no runtime. It is maintained and stable; new engine work happens in wyw-in-js, the compiler underneath it. That shared engine has a practical consequence: Linaria code and dx-styles code extract in one build, so the two can coexist and migrate file by file. For brand-new design-system work I would point you at the newer generation, and I say that as Linaria's maintainer.

dx-styles is my entry, so read this paragraph with the disclosure in mind. It is built on the same wyw-in-js engine as Linaria, but API-first for design systems: semantic deterministic class names, typed recipes and slot recipes, token contracts instead of theme conventions, opt-in compile-time RTL. It also answers the question every compiled pipeline eventually gets asked: the explain tooling traces any class in the emitted CSS back to the exact source declaration that produced it. If you are building a component library rather than an app, that is the niche it was made for. The launch post explains why it exists.

Honorable mention: Griffel, Microsoft's atomic engine under Fluent UI. It descends from an early Linaria fork and serves Fluent well, but it is its own ecosystem with little interop outside it.

And the honest exits: Tailwind and CSS Modules are not CSS-in-JS, and for plenty of teams they are the right answer. Leaving the category entirely is a legitimate migration target, not a failure state.

The same map as a table

	dx-styles	Linaria	next-yak	vanilla-extract	Panda CSS	StyleX
Zero runtime	yes	yes ¹	yes ¹	yes	yes	mostly ²
Styles colocated in components	yes	yes	yes	no (`.css.ts`)	yes	yes
Recipes / slot recipes	yes / yes	no	no (styled API)	yes ³ / no	yes / yes	pattern, not API
Token contracts + themes	yes	manual CSS vars	manual CSS vars ⁴	yes	yes	yes
Compile-time RTL	yes	no	not documented	no	logical properties	logical properties
Status	active	maintained, stable	active	active	active	active

¹ Dynamic interpolations in the styled API compile to CSS custom properties.
² Ships a small runtime for style merging.
³ Via @vanilla-extract/recipes.
⁴ next-yak cells reflect its public docs as of 9.7; corrections welcome.

Pigment CSS is missing from the table on purpose: it remains in alpha and on hold, and recommending it today would not be a kindness. There are migration guides off it, mine included.

How to choose

Skip the feature grids and start from your situation.

You have a big styled-components codebase and the runtime hurts: two direct paths keep your syntax. next-yak compiles it away with a Rust toolchain and, credit where due, builds faster. Linaria is the veteran drop-in, and its shared engine with dx-styles makes it double as an on-ramp: land on Linaria first, then drift toward recipes and token contracts file by file in the same build, with no second migration event.

You are building an app and want typed styles with minimal ceremony: vanilla-extract if you accept the file split, Panda if you want atomic output and a batteries-included config.

You are building a component library or a design system: you want semantic stable class names, typed variants, and token contracts that survive being consumed by other people's builds. That is dx-styles' niche, and vanilla-extract is the other serious candidate.

You operate at hundreds-of-teams scale and your enemy is style collisions: StyleX, and take the constraints as the point.

You mostly want to stop thinking about this: Tailwind or CSS Modules, honestly.

Where the category is heading

Convergence, from every direction at once. Every surviving library compiles to some flavor of "plain element with class names." Even the styled authoring model now folds away at build time rather than executing at runtime. The differences that remain are real but narrower: atomic versus semantic output, config-first versus code-first authoring, and how much of the design-system layer (tokens, variants, slots) is first-class API versus your own convention.

Build cost is becoming the next battleground now that runtime cost is largely solved, and it is converging too. Independent numbers exist for part of the field: css-in-js-bench measures both runtime behavior and build overhead across seventeen techniques, though the wyw-in-js family is not in it yet. I am publishing a reproducible build-time harness covering that side as a follow-up post, with numbers you can rerun rather than take on faith.

The map will be wrong in six months, which is the healthiest thing I can say about this category. File corrections, I will keep it honest.

Anton Evzhakov maintains Linaria and is the author of wyw-in-js, the zero-runtime engine behind Linaria and MUI's Pigment CSS. He builds dx-styles.

I've maintained Linaria for six years. Here's why I built something new

Anton Evzhakov — Fri, 10 Jul 2026 21:16:16 +0000

Runtime CSS-in-JS is winding down. styled-components has been in maintenance mode since early 2025, Server Components made the runtime model a structural dead end, and the default advice is "just use Tailwind." That advice is fine — for many teams it's correct, though the surveys read like a complicated romance: State of React 2025 calls it a love/hate relationship, and "excessive Tailwind usage" is the only framework entry in State of CSS 2025's general pain points. But if what you actually want is typed styles, tokens, and variants living next to your components, the zero-runtime branch of CSS-in-JS is where that lives, and I've spent the last six years in it: I maintain Linaria, and I'm the author of wyw-in-js — the compile-time engine that powers Linaria and MUI's Pigment CSS.

dx-styles is what I built after all of that. This post is about why it exists.

What six years of zero-runtime CSS-in-JS taught me

Two problems I couldn't fix in Linaria

They came back over and over in the issue tracker, and neither is fixable without breaking what Linaria is.

First: styled(Component) is priced wrong. Wrapping a custom component looks like free composition — styled(ButtonWithIcons) and you're done. In practice the wrapped component drags its entire dependency graph — icons, hooks, half of your utils — into build-time evaluation. That's the single most common way extra code leaks into eval, and the most common reason static evaluation gives up and falls back to actually running your module. Every mitigation we shipped over the years — explicit HOC hints in plugin options, dedicated heuristics for shaking wrapped components — is a patch on a pattern the API itself encourages.

Second: composition. Linaria hands you css and cx and wishes you luck. People have asked for style fragments for years, and I've pushed back every time: fragments would add chaos and complexity without addressing the actual need. In a real design system, variants, slots, and themes aren't advanced tricks — they're the ground floor. They belong in the styling library as first-class citizens, not as conventions every team reinvents on top of it.

Both fixes move the center of gravity of the API. Remove styled — or even demote it — and you've broken most of what's built on Linaria. So Linaria stays what it is, and stays maintained. The next thing had to be a new thing.

What Pigment CSS taught me

MUI built Pigment CSS on wyw-in-js, then put it on hold. My takeaway wasn't about MUI — it was about speed. On a greenfield project, build time is a habit you form early. But when you migrate an existing codebase and the styling step suddenly costs 10× the rest of the build, that's a dealbreaker — I watched it happen. And 10× isn't the ceiling: I've seen style builds take tens of minutes and tens of gigabytes of RAM.

That experience pushed wyw-in-js toward static evaluation: prove what can be proven at build time, skip the evaluation sandbox entirely. The results so far are honestly mixed — but codebases that evaluate fully statically build several times faster. And the pattern that most reliably ruins static evaluation is the one from problem #1: styled(Component).

dx-styles isn't perfect here either. A few of its processors still hit the JS fallback — creating a token contract does, in some shapes. That's a known, solvable problem, and the fix lands with wyw-in-js@3 and dx-styles@2.

Update (July 24): this shipped earlier than promised. The static-evaluation work landed in wyw-in-js 2.2 and 2.3, and as of dx-styles 1.3.0 the token-contract fallback is gone.

The trigger

My team started a component library from scratch, and Linaria turned out to be awkward in exactly the places a design system lives: tokens, variants, multipart components. We tried Griffel — itself a Linaria descendant, but through a fork that diverged around Linaria 3 and grew into a separate engine with no cross-compatibility with the wyw ecosystem: atomic classes didn't fit what we were building, and our custom processors would have meant maintaining two extraction pipelines side by side. At some point the conclusion was hard to avoid: we had more accumulated mileage with zero-runtime CSS-in-JS than anyone else, and we were spending it on working around our own tooling.

What dx-styles is

import { createTheme, createTokenContract, css, recipe } from "dx-styles";

const tokens = createTokenContract(
  { color: { accent: null, accentFg: null } },
  { prefix: "app" },
);

const dark = createTheme(tokens, {
  color: { accent: "#7c8cff", accentFg: "#080a12" },
});

const button = recipe({
  base: { display: "inline-flex", borderRadius: "999px" },
  variants: {
    appearance: {
      primary: { backgroundColor: tokens.color.accent, color: tokens.color.accentFg },
      ghost: { backgroundColor: "transparent", color: tokens.color.accent },
    },
  },
  defaultVariants: { appearance: "primary" },
});

// <button className={button({ appearance: "ghost" })} />

At build time this becomes a static CSS file and plain class-name strings. Deterministic semantic classes you can snapshot and cache on. Recipes and slot recipes with typed variants. Token contracts instead of theme conventions. Opt-in compile-time RTL. No style runtime, no providers — and the same components work unchanged in React Server Components.

The part I didn't expect to be the best part

dx-styles is implemented as a set of wyw-in-js processors — and processors aren't limited to styles. In a commercial product I work on, the same build step that extracts CSS also statically executes parts of application logic and inlines the results, dropping dead weight from the bundle at compile time. It's a macro mechanism you get for free with your styling pipeline. Writing your own processor next to dx-styles is a supported extension point, not a hack — and every wyw-based library interoperates in the same build.

What I'm promising — and what I'm not

dx-styles is MIT and stays MIT. The issue tracker runs at zero open issues — and I owe you honesty about how. If you've followed Linaria closely, you may have noticed maintenance slowing down through 2024–2025: boring triage was quietly eating the entire energy budget. Since last October, agents have taken over that layer — turning reports into reproductions, bisecting regressions — and maintainer time goes into the actual engineering; the fixes I still mostly write by hand. That's the economics that makes zero-open-issues sustainable, and dx-styles gets it from day one.

wyw-in-js@3 has a written plan — the high-level roadmap is public (stability page, tracking issue) and the detailed plan goes further. The honest constraint is volume: it's a lot of work, and its pace will scale with how much the community cares about this direction. No dates.

Try it without installing anything: the Vite starter on StackBlitz is a ready-made sandbox — a themed button demo you can poke, edit, and watch the extracted CSS change; the Next.js one runs the same components inside React Server Components. Prefer starting from scratch? npm install dx-styles and the getting started guide. Migrating? There are dedicated guides for styled-components, Linaria, and Pigment CSS. Issues — including hostile questions — welcome: github.com/dx-styles/dx-styles.

Anton Evzhakov — maintainer of Linaria; author of wyw-in-js, the zero-runtime engine behind Linaria and MUI's Pigment CSS.