CSS-in-JS benchmarks

A module boundary switches off next-yak's compiler, unless what you export is styles rather than components

The Example multifile-shop shown below is the Example product-grid re-laid-out across separate modules, byte-identical in DOM and CSS and verified pixel-identical. next-yak falls from 185,000 to 105,000 renders/s and lands beside its own foldStatic: false lane at 103,000, because fold_jsx_usages rewrites a declaration and its use site only when both live in one module. The css prop is untouched, 231,000 against 223,000, since it folds where it is written and inlines an imported fragment at build time. The Example multifile-composition shows which boundary is free: move a component and its JSX together and folding still sees both.

Across the Examples compose-1, compose-3 and compose-6 shown below, next-yak costs 2.24M, 1.40M and 1.48M renders/s. Six levels of wrapping compile to one component carrying six class names in a single string, so everything after the first wrapper is free. Hand-written vanilla pays once per level, 1.92M to 1.37M to 919,000, and panda pays hardest, 1.12M to 310,000. The Example button-variants shows the ceiling of the same mechanism: three imported style values fold into className="yTV3SxX" and the wrapper component disappears from the output.

The two next-yak APIs are not interchangeable, and they fail in opposite places

The css prop folds across a module boundary and the styled API does not, worth 2.12× on the Example multifile-shop shown below. Under composition the ordering reverses: the styled API concatenates a chain into one component while the css prop merges at every level, so on the Example compose-6 the styled lane runs 1.48M renders/s against 600,000. On the Example button-variants-nested the css prop has no cell at all, because a style fragment cannot arrive as a component prop and the case does not compile for it. Choosing between the two is a bet on which pattern a codebase uses most.

On the Example product-grid shown below, styled-components spends 5.66 ms and goober 5.93 ms of server CPU serializing rules per instance, against 0.000 ms for the lanes that resolve at build time. The same work returns on the client, where both need around 240 ms to hydrate the page against 56 ms for the leaders, because the sheet must be rebuilt before React can attach. It arrives a third time on interaction: one wishlist toggle costs emotion 46.2 ms against 8.5 ms.

Dynamic values are a compiler feature in next-yak and a discipline everywhere else

The Example dyn-translate shown below measures the naive pattern, the value baked into the class name, which is what a codebase produces when nobody optimizes: goober renders at 166,000 renders/s and takes 1.27 s to hydrate. The Example dyn-fair gives every lane its own best practice, and for a library without native support that best practice is hand-written, splitting the static class from an inline style per component, for every dynamic value, indefinitely. It works, lifting goober to 945,000 and panda to 1.00M. next-yak ships that separation as a compiler feature and pays for it: the Example dyn-inline puts every lane on a plain inline style, where next-yak renders 1.51M against 724,000 through its CSS custom property.

On the Example tabs shown below, next-yak-css ships 2,707 gz B and cnfast 22.0 kB for the identical page. The split is not the stylesheet, which stays within a few hundred bytes across lanes; it is the JS and the markup. emotion and styled-components each carry about 13 kB of library, while the utility lanes write their class lists into the HTML. The Example product-grid holds the same ordering at 7,475 gz B against 27,718.