CSS-in-JS: the case against (for a Python dev)

What is CSS-in-JS

Libraries like styled-components, Emotion, Stitches:

const Button = styled.button`
  background: ${props => props.primary ? "#3B82F6" : "#e5e7eb"};
  color: white;
  padding: 8px 16px;
`;

Styles live inside JS, generated at runtime, injected into a <style> tag.

Why this got popular (2016-2020)

• CSS modules + Sass were verbose.
• Themes were hard to wire up.
• Dynamic styles (based on props) needed JS anyway.
• Tooling was JS-heavy already.

Why it's losing in 2026

1. Runtime cost. Every render parses + serializes styles. Real perf hit.
2. Larger bundles. Library + your styles + theme tokens ship together.
3. Hydration cost. Styles initialize AFTER React boots — flicker.
4. Native CSS caught up. @scope + @layer + custom properties + nesting do everything styled-components did, natively.
5. Tailwind exists. For dynamic-style use cases, Tailwind's class composition + JS conditionals is faster.

The 2026 answer

For a backend dev who just wants a UI:

• Don't reach for styled-components.
• Do use plain CSS files OR Tailwind.

CSS in a .css file is faster, easier to debug, and produces smaller bundles. The "ergonomic" arguments for CSS-in-JS evaporated when native CSS shipped scoping, nesting, and custom properties.

When CSS-in-JS still makes sense

• Existing codebases (don't rewrite a working styled-components app).
• Component libraries that need to ship "themeable" components (Radix, Mantine).
• Pages with truly per-user, runtime-computed styles.

For 95% of "I just need a UI on my Python backend" — plain CSS or Tailwind wins.

This lesson is theory-only — no code task. Read, understand, move on.