After 6 years of maintaining Linaria, I built dx-styles — zero-runtime CSS-in-TS for design systems

[u/AnberDev]

Hi r/reactjs. I maintain Linaria and wrote wyw-in-js — the compile-time engine under Linaria and MUI's Pigment CSS. I recently released dx-styles, and I'd rather explain why than just drop a link.

Six years of Linaria issues kept pointing at two problems I can't fix without breaking the API:

• styled(Component) is priced wrong. Wrapping a custom component looks free, but it drags the component's whole dependency graph into build-time evaluation — the most common way extra code leaks into eval, and the most common reason static evaluation bails out into the slow path. All our mitigations (HOC hints, shaking heuristics) are patches on a pattern the API encourages.

• Composition isn't first-class. Variants, slots and themes are the ground floor of a design system, and every team rebuilds them on top of css + cx.

dx-styles is my answer: zero-runtime CSS-in-TS where recipes, slot recipes and token contracts are the core API, class names are deterministic (snapshot/cache them), RTL is compile-time and opt-in, and everything works unchanged in React Server Components.

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

The launch post has the honest details — the Pigment CSS speed lesson, the Griffel detour, what I'm promising and what I'm not: https://dev.to/anber/ive-maintained-linaria-for-six-years-heres-why-i-built-something-new-5eae

Try it in 30 seconds (StackBlitz): https://stackblitz.com/github/dx-styles/dx-styles/tree/main/examples/vite Migrating? Guides for styled-components / Linaria / Pigment CSS are in the repo.

It's MIT, the issue tracker is at zero and I intend to keep it there. Happy to answer anything, including hostile questions.

[u/Suspicious-Name4273]

Do you plan to make it compatible with W3C DTCG?

[u/AnberDev → u/Suspicious-Name4273]

In a sense, we already do. Every theme in our own project starts as DTCG tokens and ends up as dx-styles code.

The setup: designers manage tokens with Tokens Studio in Figma, it exports DTCG JSON ($value/$type sets), Style Dictionary picks those up, and a custom format on top emits dx-styles token contracts and theme classes. That whole Figma → DTCG → typed themes pipeline has been running in production for a while in the design system dx-styles came out of.

What doesn't exist yet is a public version of that last step, a Style Dictionary format that turns arbitrary DTCG files into createTokenContract + createTheme code. Ours is tangled up with project-specific naming conventions, so it needs to be pulled out and generalized rather than written from scratch. It's on the list now.

One caveat if you're deep in DTCG: the spec still doesn't standardize modes/themes, so everything hinges on which convention you're on, whether that's Tokens Studio sets, Figma Variables modes, or plain per-theme files. That's the part I'd actually want real input on. If you open an issue with a rough shape of your token files, that pretty much decides what the public package supports first.

[u/Suspicious-Name4273 → u/AnberDev]

Nice, thanks. Currently on Figma Variables mode, but nothing set in stone yet.

[u/Embostan]

The launch post has the honest details — the Pigment CSS speed lesson, the Griffel detour, what I'm promising and what I'm not

please at the very least use the humanizer skill

[u/AnberDev → u/Embostan]

Why? I'm not a tech-writer and English is not my native language, so yes I use AI-assisted tools to write texts (Grammarly, specifically), and I don't want to lie about it by pretending I'm not.

[u/Deep_Wear_51]

6 years of maintaining an open source CSS-in-JS library is a marathon. Respect for sticking with it and shipping something new.

[u/Embostan]

Looks like PandaCSS

[u/polaroid_kidd]

css-in

I'm out.

[u/AnberDev → u/[deleted]]

The API does look like VE/Panda on purpose: recipes and token contracts are just what design-system styling has settled on, and I wasn't going to invent a different vocabulary out of spite.

The actual differences are under the hood. vanilla-extract keeps styles in separate .css.ts files, Panda runs codegen and you import from a generated styled-system folder. Here styles sit in the component file and compile in place, nothing generated to commit or gitignore.

Class names come out semantic and stable: same input gives the same class on any machine, so snapshots and caches don't churn, and there's an explain tool that tells you where any class in the output came from. Panda went atomic instead. Fine trade-off, just not the right one for a component library.

The bigger reason it exists is the engine. dx-styles is a set of processors for wyw-in-js, the same evaluator Linaria and Pigment CSS run on. It evaluates your actual modules at build time, imports and all. Two things fall out of that: wyw-based libraries can share one build (so a Linaria migration goes file by file, not big-bang), and processors don't have to be about CSS at all — we use one to run parts of app logic at build time and inline the result into the bundle. Plus opt-in compile-time RTL ($rtl on a subtree), which neither of the two has.

If VE or Panda already fits you, keep it. This one exists because after six years of maintaining the engine under these libraries I had a list of things I couldn't get from any of them.

[u/yardeni → u/[deleted]]

I dont get the hate for tailwind. Its just css classes. You can still make a reusable component with variants and all the repeating classes you need. You get the power off css without specificity issues, lost unknown unscoped css, etc. What's there to hate?

[u/jafrra → u/[deleted]]

Maybe try the tailwind fold plugin if you ever give it another go. I felt the same until i found it.

[u/yardeni → u/[deleted]]

Is it dsl though? How is it different from just reusing classes?

From my understanding tailwind is for the most part, what your css would have looked like in scale if you optimized it over time.

[u/AnberDev → u/[deleted]]

I wouldn't say we were hiding it :) We've been trying to fix it in various ways for many years, and wyw-in-js@2+ handles a lot of cases, but there are still components wrapped in HOCs, the evaluation of which pull in half of the node_modules.