Colocated styles, dynamic props, and automatic unique class names help large component teams. You spend JavaScript to generate rules, insert stylesheets or style tags at runtime, and sometimes fight specificity with duplicated selectors.
\n\nstyled-components and emotion peaked in design-system-heavy React apps. Build-time alternatives like vanilla-extract and Linaria moved cost to compile time for good reason.
\n\nCritical path CSS extraction tools for emotion exist but add build config. Teams skip and pay runtime cost. Stylelint on template literals exists but adoption is low; discipline stays manual.
\n\n/* Prefer tokens in vanilla CSS over runtime-injected rules */\n:root { --accent: 204 255 0; }\n.btn { background: rgb(var(--accent)); }Each render can regenerate class names and rules unless memoized carefully. SSR requires critical CSS extraction or flash of unstyled content. Multiple instances bloat memory on long sessions.
\n\nLighthouse sees larger JS and longer script evaluation. INP suffers when interaction triggers style recalculation across huge injected sheets.
\n\nMultiple theme providers nested in micro-frontends multiply injection cost. Single provider at shell root only. Fela and other libraries have different injection models; compare before blanket advice.
\n\nHydration must match server-generated class names. Theme changes via context re-render trees. I have debugged midnight production issues from missing StyleSheetManager on a portal route.
\n\nStatic CSS files cache across navigations; runtime CSS reinjects per route mount in SPA unless global cache layer exists.
\n\nSnapshot tests for styled components churn on class hash changes. Visual regression on real DOM is calmer. RSC might colocate CSS files without runtime injection; follow framework guidance when on Next 15+.
\n\nWhite-label SaaS with per-tenant theme objects mapped to props can justify runtime styling with strict budgets and tests. Open-source component libraries shipping to unknown hosts sometimes need isolation CSS-in-JS provides.
\n\nEven then I explore CSS variables for theme dimensions and reserve runtime generation for truly dynamic values only.
\n\nLinaria and similar zero-runtime options deserve evaluation before greenfield styled-components default. Storybook with CSS-in-JS needs same ThemeProvider wrapper as app or chromatic lies.
\n\nExtract tokens to :root, convert stable components to modules.css, delete unused prop interpolations. Measure bundle and INP weekly. Big-bang rewrite is rare; strangler on leaf components works.
\n\nCSS modules with typed scss modules give DX without runtime; TypeScript codegen bridges gap.
\n\nUnit tests snapshotting styles are brittle; assert computed style in jsdom for critical focus ring only.
\n\nbriancrabtree.me uses plain CSS files and custom properties. No style injection on journal read. Perf scores and maintainability improved versus the experimental CSS-in-JS pass years ago on a prototype.
\n\nRuntime CSS-in-JS on emails is impossible anyway; shared tokens in plain CSS help both web and mail.
\n\nMarketing one-pager in styled-components inside corporate React app is acceptable island if isolated.
\n\nIf your styles are mostly static and theming is two modes, global CSS wins. If styles are functions of dozens of runtime props per row in a grid, compile-time or scoped CSS modules plus variables likely beat full runtime CSS-in-JS. Send your styled-components profile; I will quantify JS cost and propose escape path.
\n\nI profile React commit phase before blaming CSS-in-JS alone. Often state shape is co-conspirator.
\n\nBuild time extraction to static CSS file is migration end state I recommend for content surfaces. For a related angle I keep coming back to, see Tailwind vs Vanilla CSS: Tradeoffs I Explain to Clients.
","tags":["css-in-js","performance","styled-components"],"views":58}