CSS-in-JS: A Different Authoring Model

CSS Modules and scoped CSS still involve writing actual .css files (or <style> blocks), processed by a build tool — the CSS itself is still fundamentally CSS text. CSS-in-JS libraries (styled-components, Emotion, and others) take a different approach: styles are authored as genuine JavaScript — a tagged template literal, an object, or a function call — living directly in the same .jsx/.tsx file as the component's logic, with full access to JavaScript's expressiveness at the point of style definition.

This is what makes dynamic, prop-driven styling so direct in CSS-in-JS: background: ${props => props.primary ? 'blue' : 'gray'} reads a component prop directly inline within the style definition itself, something a static CSS file fundamentally can't express without an external mechanism (like conditionally toggling a class name) bridging the gap.

Not all CSS-in-JS libraries work the same way under the hood, and this distinction has genuine, measurable performance consequences. 'Runtime' libraries — the traditional, original CSS-in-JS approach — generate the actual CSS text and inject it into the page's stylesheet dynamically, in the browser, as components render, which requires real JavaScript execution on every render that involves style computation, a genuine, non-trivial cost.

'Zero-runtime' libraries (a newer generation, including tools like vanilla-extract or Linaria) instead extract all styles at build time into genuine, static CSS files — identical in final output to what CSS Modules would produce — while still allowing developers to author styles using JavaScript syntax during development. The browser receives zero style-generation JavaScript at all; it's purely a build-time authoring convenience, with the actual runtime performance profile of plain, static CSS.

CSS-in-JS's genuine, real advantage is direct, inline dynamic styling from JavaScript values — no separate class-toggling logic needed to express 'this button's color depends on this prop'. Its genuine, real cost (specifically for runtime variants) is actual JavaScript execution overhead in the browser that a purely build-time solution like CSS Modules or scoped CSS simply doesn't incur, since those approaches resolve all scoping and static styling at build time with zero runtime JavaScript cost.

Neither approach is universally correct — the right choice depends on how much genuinely dynamic, prop-driven styling a project actually needs versus how much of its styling is fundamentally static (in which case CSS Modules or zero-runtime CSS-in-JS both avoid runtime cost equally well). This is exactly the kind of deliberate, informed trade-off evaluation this course has emphasized throughout: understanding the actual mechanism and its real cost, rather than choosing based on trend or habit.

Styles As JavaScript Values. CSS Modules and scoped CSS still involve writing actual CSS files, processed by a build tool. CSS-in-JS is a more fundamental shift: styles are authored as JavaScript itself — template literals, objects, or function calls — living directly alongside component logic, generated dynamically rather than written as static CSS text.

Styles As Colocated JavaScript. A CSS-in-JS library like styled-components lets you define a styled component with a tagged template literal containing CSS-like syntax, directly in the same file as the component's logic — the styles are genuinely JavaScript values (strings, ultimately), not separate CSS parsed by a build tool the same way a .css file is.

Styles As JavaScript Values. What's fundamentally different about how CSS-in-JS defines styles compared to CSS Modules?

• →There's no real difference — both are just different syntax for the same underlying static CSS file
• →CSS-in-JS styles are genuinely defined as JavaScript values directly in the component file, capable of referencing JavaScript variables and props dynamically, rather than being a separate, static CSS file
• →CSS-in-JS is always faster to render than CSS Modules

Runtime vs Zero-Runtime: A Critical Distinction. 'Runtime' CSS-in-JS libraries generate and inject actual CSS into the page dynamically, in the browser, as components render — genuinely flexible but with real JavaScript execution cost. 'Zero-runtime' libraries instead extract all the CSS at build time into a genuine static CSS file, shipping zero style-generation JavaScript to the browser at all.

Runtime vs Zero-Runtime. What's the key practical difference between a runtime and a zero-runtime CSS-in-JS library?

• →Purely a difference in authoring syntax, with identical actual browser behavior
• →A runtime library generates and injects CSS dynamically in the browser as components render, while a zero-runtime library extracts all CSS to a static file at build time, shipping no style-generation JavaScript
• →There's no meaningful practical difference between the two categories

The Real Trade-offs Versus CSS Modules. CSS-in-JS's genuine advantage is dynamic styling directly from JavaScript values (props, theme context) without any separate class-toggling logic — its genuine cost, for runtime variants specifically, is real JavaScript execution overhead the browser has to pay that a purely build-time solution like CSS Modules doesn't incur at all.

The Real Trade-off. What's the genuine advantage CSS-in-JS offers over CSS Modules, and what's its corresponding cost?

• →There's no real trade-off — CSS-in-JS is strictly better in every case
• →CSS-in-JS allows styles to reference JavaScript values (like props) directly without separate class-toggling logic, at the cost of real JavaScript execution overhead for runtime variants that CSS Modules doesn't incur
• →CSS-in-JS always produces a smaller final bundle than CSS Modules

CSS-in-JS Fundamentals Understood. You now understand CSS-in-JS as a genuinely different authoring model — styles as JavaScript values colocated with component logic — the critical runtime versus zero-runtime distinction and its real performance implications, and the honest trade-off between CSS-in-JS's dynamic styling convenience and CSS Modules' zero-runtime-cost simplicity.

Style A Generated Class Hash. CSS-in-JS libraries generate a unique class per component at build time — the rule still targets it like any class.