CSS-in-JS — An Honest Look at a Declining Pattern

This chapter covers a fourth real pattern this course hasn't touched yet — and gives it the same honest, two-sided treatment applied throughout, rather than ignoring it or dismissing it.

What CSS-in-JS Actually Is

const Button = styled.button`
  background: blue;
  padding: 1rem;
`;

CSS-in-JS means writing actual CSS rules directly inside JavaScript or component files (styled-components, Emotion) — a component's own styling lives literally alongside its own logic in the same file, generated at runtime by a library that dynamically creates and injects real <style> rules into the page as components render. This looks like writing plain CSS, but it's actually a JavaScript template literal being processed by a library.

Why This Was Genuinely Popular — The Real Motivations

Worth being fair and honest here: CSS-in-JS wasn't a bad idea everyone was fooled by. It solved real problems when it became popular, in the mid-to-late 2010s alongside React's own rise. True component-scoped styles with no risk of global CSS collision at all — a genuinely stronger guarantee than BEM's own naming-convention-based scoping, since it's enforced by the tooling itself rather than developer discipline. And dynamic styling based on component props or state felt genuinely natural (background: ${props => props.primary ? 'blue' : 'gray'}), since styles and logic already lived in the same file and language. For a real period, this was considered a genuinely leading-edge, sophisticated approach — not a mistake.

The Real, Documented Reasons for Its Decline

The central, real technical reason is runtime cost. Classic CSS-in-JS libraries generate and inject styles at runtime, in the browser, as components render — a genuine, measurable JavaScript execution cost, and a genuine risk of a delay before styles are actually applied (a real, documented "flash of unstyled content" in some setups). This is a direct, structural contrast with every other paradigm this course has covered: Tailwind's own JIT (cssfw1-4) generates CSS at build time, Bootstrap ships precompiled CSS, headless libraries (cssfw1-6) ship zero styles at all. Classic CSS-in-JS is genuinely the only paradigm in this entire course that does real styling work in the browser, at runtime, rather than ahead of time.

"Zero-runtime" CSS-in-JS successor tools (vanilla-extract, some newer Emotion configurations) emerged specifically to fix this — extracting styles to real, static CSS at build time instead, closing the exact gap. Worth an honest, dated note: the CSS-in-JS story itself evolved once this problem became well understood, rather than the entire idea being abandoned outright.

The Shift Toward Utility-First / Zero-Runtime Approaches

Tailwind's own real rise (cssfw1-2 through cssfw1-4) is directly connected to this exact runtime-cost critique of classic CSS-in-JS. Tailwind offers component-scoped-feeling styling — via co-located utility classes in markup — with build-time, not runtime, CSS generation, genuinely addressing the same original motivation (avoiding global CSS collision, styles living near component logic) that CSS-in-JS was solving, without its real runtime cost. This is the actual, documented reason for the broader industry shift, not simply changing fashion.

Is CSS-in-JS "Dead"? An Honest, Precise Answer

No, not entirely. It's still genuinely used in real, existing production codebases — a real, ongoing migration-cost consideration for teams that adopted it early, not something to casually rip out. Newer, genuinely zero-runtime variants remain a real, legitimate option for teams that specifically want CSS-in-JS's own dynamic-styling ergonomics without its classic runtime cost. "Declining in new project adoption" is the precise, honest claim — not "nobody uses this anymore."

Hands-On Exercises