Eric Downs

Why I Stopped Using CSS-in-JS (And What I Use Instead)

After years of styled-components and Emotion, I switched to Tailwind CSS. Here's the real reason — and it's not what you think.

CSSTailwindPerformanceDeveloper Experience

I was a CSS-in-JS evangelist for three years. Styled-components in every project, theme providers everywhere, runtime style injection that I swore was "fine for performance." Then I started measuring. And the numbers didn't lie.

The best CSS architecture is the one your whole team can read, write, and maintain without a decoder ring.

The runtime overhead was real — 12-18KB of JavaScript just to parse styles, plus the flash of unstyled content on slower connections. But honestly? That wasn't the dealbreaker. The dealbreaker was onboarding. Every new dev needed to learn our abstraction layer before they could center a div. Tailwind gave us a shared vocabulary that junior devs and seniors could both use on day one.

Sources

  1. Performance data measured across three production application migrations from styled-components to Tailwind CSS
  2. Bundle size and TTI metrics collected via Lighthouse and WebPageTest

Key Statistics

  • CSS bundle size: -34% after migration
  • Time-to-Interactive: -200ms average improvement
  • CSS-in-JS runtime overhead: 12-18KB JavaScript for style parsing
  • PR review time for style changes: reduced by 50%

Expertise

Three years of production CSS-in-JS experience before switchingMigrated three production applications from styled-components to TailwindTechnical Director managing teams through CSS architecture transitions

Related

Why I Stopped Using CSS-in-JS — Eric Downs | Eric Downs