gajus/css-in-js-arena

Source: https://github.com/gajus/css-in-js-arena

CSS-in-JS Arena

A benchmark harness for compile-time CSS engines. Each engine gets its own React Router 8 app under apps/, and every app renders the same six-page admin console — identical markup, identical design, identical data. The apps are verified pixel-identical before anything is measured, so the numbers isolate the engine and nothing else.

Measured 2026-08-18 at the versions above · macOS, Node 24.10, Vite 8.2.1

Rows won per category, out of the scored rows in each. They are not equally weighted and two are unscored, so the tally is a scanning aid rather than the judgement — and the byte margins do not survive scale, as the next section shows.

Full results

Where the main table doesn’t generalise

Everything above is one app in one configuration. Two things move the answer: how many styles the app has, and whether it ships more than light and dark.

Style volume

The main table describes an app of 549 rule blocks. Real applications run an order of magnitude past that, where fixed overhead stops mattering and marginal cost per rule becomes everything.

tools/scale.mjs generates N style definitions with all-distinct values and measures the emitted stylesheet, isolating each engine’s true cost per rule.

Downloaded stylesheet, brotli, relative to Bamboo:

Both challengers move, in opposite directions. The ranking at the arena’s size is not the ranking at production size.

Panda’s marginal cost is identical to Bamboo’s, to the byte. Its whole penalty is a fixed 16,903 B of scaffolding — the same constant at 0 styles and at 800 — so “Panda ships 40% more CSS” is a statement about a small app, not about Panda. StyleX is the reverse: almost pure slope, growing 30× across the same range, because every rule carries :not(#\#) specificity padding that repeats per declaration and compresses poorly.

Theming

Brand themes are a different question from light/dark, and the arena app ships none — so this is measured separately. tools/theming.mjs injects N themes through each engine’s own multi-theme API (Bamboo theme.variants, Panda themes, StyleX createTheme), each overriding the same 18 colours with a light and a dark value.

Stylesheet the browser downloads, brotli:

Theme payload, fetched only when a theme is selected:

Two mechanisms, not three. Bamboo and Panda emit each theme as its own artifact, imported on demand, so first load is flat however many exist. StyleX’s createTheme compiles into the linked stylesheet, so every visitor pays for every theme — at eight, its CSS is 19% larger than at zero. Between the two lazy engines the gap is the same encoding difference as the light/dark row: Bamboo writes base and _osDark and lets light-dark() resolve the rest, Panda writes four values. That is 2.04× the bytes per theme.

This reverses for a site that ships one fixed brand theme and never switches: a lazy artifact is then a second request for bytes the stylesheet would have carried anyway.

What’s measured

Ground rules

• One reference app. apps/bamboo is the reference; every other is diffed against it, so all match each other transitively — element for element, then pixel for pixel.
• Shared source is byte-identical. data.ts, icons.tsx and chart-utils.ts are the same bytes in every app.
• Same baseline reset. Engines that ship one use theirs; engines that do not vendor Bamboo’s preflight verbatim, so nobody gets a typography head start.
• Default configuration only. Each engine is measured as it ships. Opt-in settings are reported separately, never folded into the main table.

Pages

Every app renders these six routes identically:

All six are responsive across three breakpoints and support system dark mode plus an explicit light/dark toggle.

Reproducing this

Every number here comes from one contiguous measurement session on one machine. The harness, the parity gate and the exact commands are in RUNNING.md.

FAQ