CSS-in-JS Arena

Benchmark harness for compile-time CSS engines. Each engine gets its own React Router 8 app under apps/, all rendering the same six-page admin console: identical markup, design and data, verified pixel-identical before anything is measured.

Measured 2026-08-29 · macOS, Node 24.10, Vite 8.2.1

Axes are not equally weighted and two are unscored, so the tally is a scanning aid, not the judgement. The byte margin does not survive scale, and the build margin survives only against StyleX.

---

Full results

---

Where the main table doesn't generalise

One app, one configuration. Three things move the answer: style count, file count, theme count.

Style volume

The arena is 570 rule blocks. tools/scale.mjs generates N all-distinct style definitions and measures the emitted stylesheet.

Downloaded stylesheet, brotli, relative to Bamboo:

The ranking at the arena's size is not the ranking at production size. Panda's marginal cost equals Bamboo's to the byte; its whole penalty is a fixed 16,681 B of scaffolding, identical at 0 styles and at 800. StyleX is the reverse, almost pure slope: every rule carries :not(#\#) specificity padding that repeats per declaration and compresses badly.

Dev loop and app size

tools/dev-scale.mjs adds N generated source files and re-measures. Every module carries identical declarations, so they fold to the same classes and the stylesheet stays flat (Bamboo 37,326 → 37,494 B). Only file count grows.

Edit → HMR broadcast, ms:

Per-edit cost is flat in file count. None of the three re-reads the source inventory to answer an edit. StyleX and Panda hold to within 4 ms across 400 files. Bamboo's points span 95–127 ms, but each is a 7-run median drawn from a bimodal distribution, and seven runs cannot place a median reliably between two clusters. The COUNTS=0,400,800,1600 sweep puts the same sizes in different clusters — 128, 74, 125, 129 ms — which is what sampling looks like and what a slope does not. Bamboo's gap to the other two is a fixed ~2×. Whole-inventory work is not flat:

Per-added-file cost is a constant, and Bamboo's is level with StyleX's and about 2× Panda's. Read the milliseconds, not a percentage: the app is 13 source files, so 400 more is 32× the inventory and any per-file constant reads as a triple-digit percentage off that base.

Nothing here is quadratic, and the constant is what decides it. Carried out to 1,600 extra files (COUNTS=0,400,800,1600), every engine curves upward by the same small proportion of its own rise — second differences over equal 800-file steps are +191 ms for Bamboo, +98 for StyleX and +31 for Panda, or 11%, 6% and 4% of each total — so the curvature is a property of the harness, not of any one engine, and the per-file constant remains the right summary:

This is where the main table's build rows stop generalising — but only against Panda. Bamboo is the fastest build in this repo and stays ahead of StyleX at 1,600 files, where it is still 0.9 s faster; the two slopes differ by 11%, which puts their crossover near 9,700 files — six times beyond the measured range, and a gap that narrow between two noisy slopes is better read as no crossover in practice than as a figure. Against Panda the slope gap is real, 1.08 against 0.48 ms per file, and the 294 ms head start is spent by roughly 510 total source files — a size a real application passes early. The main table's build win over Panda is a property of a 13-file app; the win over StyleX is not.

About half of Bamboo's constant buys nothing. Run the same sweep with ORPHANED=1, which generates the same modules but leaves them unimported — inside include, outside the bundle graph:

The orphaned sweep runs at 0.59 ms per file over the full 0→1,600 range — so 55% of Bamboo's per-file cost is spent reading files it then discards for being outside the bundle graph, for zero emitted bytes. StyleX never opens them: its orphaned sweep drifts −59 ms across 1,600 files, which is measurement noise around zero. Panda reads them at 0.26 ms each and keeps the result. This is the same bundle-graph scoping that wins Bamboo the orphan-file row in the main table, seen from its cost side rather than its byte side: the file is scanned either way, and only the output is dropped. Panda is flattest in file count as it is in rule count.

Theming

The arena ships no brand themes. tools/theming.mjs injects N through each engine's own multi-theme API (Bamboo theme.variants, Panda themes, StyleX createTheme), each overriding the same 18 colours light and dark.

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 loaded 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 lazy two it is the light/dark encoding again, Bamboo writing base and _osDark and letting light-dark() resolve the rest against Panda's four values, 2.04× the bytes per theme. For a site with one fixed brand theme this reverses: a lazy artifact is 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 element for element, then pixel for pixel, so all match each other transitively.
• Shared source is byte-identical. data.ts, icons.tsx and chart-utils.ts are the same bytes in every app.
• Same baseline reset. Engines shipping one use theirs. Engines that do not vendor Bamboo's preflight verbatim, so nobody gets a typography head start.
• Default configuration only. Opt-in settings are reported separately, never folded into the main table.

Pages

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

---

Reproducing this

Every number comes from one contiguous session on one machine. Harness, parity gate and exact commands are in RUNNING.md.

---

FAQ

Why is CSS minification disabled?

build.cssMinify: false in all three apps. Vite's default runs Lightning CSS over the stylesheet and rewrites it, most visibly downlevelling light-dark() into a 54-variable polyfill under the baseline-widely-available target. That measures the downleveller, and penalises only engines emitting modern CSS. Off, every stylesheet here is what its engine wrote.

StyleX still shows Lightning CSS output because @stylexjs/unplugin depends on it directly. That is its product, not the harness.

What does the orphan-file row measure?

A module matching the engine's include glob that nothing imports: the file a deleted feature leaves behind. tools/orphan.mjs writes one carrying 50 style definitions, rebuilds, and diffs the stylesheet.

Panda extracts from source text, so it ships the CSS whether or not the bundle reaches the file. Bamboo and StyleX scope to the bundle graph and emit nothing. The 13,200 B is a property of the fixture; the finding is which engines are at zero.

Why is the HMR edit four rows instead of one?

Because one number measured the wrong event. The old probe polled getComputedStyle until it differed from the previous value. tools/hmr-trace.mjs shows two faults:

It fires on a flash. The first value seen is an inherited fallback, 15px. On the shared edit the written value arrives ~48 ms later for Bamboo and ~41 ms later for StyleX; Panda's lands in the same frame.

It is not the same event across engines. An edit produces two signals, the CSS going live and the JS module re-executing, and the poll catches whichever is first. On the shared edit Bamboo ends on its JS and the other two on their CSS; on the component edit Panda is the one ending on CSS.

Because that head start differs per engine — 48 ms for Bamboo, 41 ms for StyleX, none at all for Panda — the flash is not a stable proxy for the ranking. To correct paint the shared edit spans 76 ms across the three engines, Panda 131 ms to Bamboo 207 ms; the flash the old probe fired on compresses that to 29 ms, Panda 131 ms to Bamboo 160 ms. A spread that narrow is inside the run-to-run noise, so which engine reads fastest becomes a matter of which sweep you took.

Of the four rows only server reacts (write to HMR broadcast) is attributable to the engine alone. Everything later includes Vite's protocol, React Fast Refresh and the socket round trip. Correct paint is end to end.

Bamboo's server reaction is marked bimodal because it is: on the shared edit about a fifth of runs land near 25 ms and most of the rest near 125 ms, so the pooled median sits between two clusters rather than on either. StyleX's component edit is bimodal the same way, between ~10 ms and ~90 ms. Small samples invent trends here, which is why the main-table rows pool 28 runs.

HMR payload counts bytes, not milliseconds, and reproduces exactly.