Tailwind CSS v4: Why I Chose CSS-First Config Over Styled Components
Source: Dev.to
Introduction
I’ve been building React components for years, trying every styling solution: CSS Modules, Styled Components, Emotion, Sass, and Tailwind v3. When Tailwind CSS v4 alpha landed with its revolutionary Oxide engine and CSS‑first configuration, I knew something fundamental had shifted.
- Build times: 12 s → 1.2 s (10× faster)
- Hot module replacement: 500 ms → Fast, type‑safe, and maintainable styling.
Evaluation Criteria
| Criterion | Weight |
|---|---|
| Build Performance | 30 % |
| Runtime Performance | 25 % |
| Developer Experience | 20 % |
| Maintainability | 15 % |
| Ecosystem | 10 % |
Each tool is rated 1‑5 ★ per criterion, then weighted.
Tailwind CSS v4 (Oxide Engine)
What it is: A Rust‑based CSS framework with CSS‑first configuration using @source and @theme directives—no tailwind.config.js.
Innovation
- Oxide Engine: 10× faster than v3 (Rust vs JavaScript)
- CSS‑First: Configuration via
@themein CSS, not JS @source: Scans directories for classes directly in CSS- Native CSS: Full support for variables, container queries, etc.
Stats
- GitHub Stars: 82k+ ⭐
- NPM Downloads: 10 M+/week 📦
- Version: 4.0.0 (stable as of Dec 2024)
- Bundle Size: 8‑15 KB gzipped (tree‑shaken)
Key Features
@import 'tailwindcss'; /* single import, no config file */
@source './src'; /* scan directories for classes */
@theme {
--color-primary: blue;
}
- Lightning‑fast builds with Oxide
- Full PostCSS compatibility
Best for: New projects, performance‑critical apps, design systems wanting CSS‑native configuration.
Tailwind CSS v3 (Traditional Approach)
What it is: JavaScript‑configured utility‑first CSS framework with a JIT engine and extensive plugin ecosystem.
Stats
- GitHub Stars: 82k+ ⭐
- NPM Downloads: 10 M+/week 📦
- Version: 3.4.15 (stable, mature)
- Language: JavaScript + PostCSS
Pros & Cons
| Pros | Cons |
|---|---|
| ✅ Mature, battle‑tested | ❌ Slower than Oxide (≈10×) |
| ✅ Massive plugin ecosystem | ❌ JS config complexity (200+ lines) |
| ✅ Universal knowledge | ❌ HMR slower (≈500 ms) |
| ✅ JIT engine still fast | ❌ Missing native @theme |
Best for: Existing projects, teams needing stability and specific v3‑only plugins.
Styled Components (CSS‑in‑JS)
What it is: Library that writes CSS in JavaScript using tagged template literals.
import styled from 'styled-components';
const Button = styled.button`
background: ${props => (props.primary ? 'blue' : 'gray')};
padding: 1rem 2rem;
border-radius: 0.5rem;
`;
Stats
- GitHub Stars: 40k+ ⭐
- NPM Downloads: 3.5 M/week 📦
- Version: 6.1.13
- Bundle Size: ~16 KB runtime + styles
Pros & Cons
| Pros | Cons |
|---|---|
| ✅ True component scoping | ❌ Runtime overhead (styles computed at runtime) |
| ✅ Dynamic styling with JS logic | ❌ Larger bundle (~16 KB + styles) |
| ✅ TypeScript support | ❌ Performance impact (style injection) |
| ✅ Automatic vendor prefixing | ❌ SSR complexity (style extraction) |
| ✅ Theme provider | ❌ No build‑time optimization |
Best for: Apps needing heavy dynamic styling, component libraries where scoping is critical.
CSS Modules (Classic Approach)
What it is: Traditional CSS with scoped class names generated by bundlers.
/* Button.module.css */
.button {
background: blue;
padding: 1rem 2rem;
}
.primary {
background: darkblue;
}
import styles from './Button.module.css';
Click
Stats
- Bundle Size: Only your CSS (smallest possible)
- Performance: Zero runtime, pure CSS
Pros & Cons
| Pros | Cons |
|---|---|
| ✅ Zero runtime overhead | ❌ No type safety (class name strings) |
| ✅ Smallest bundle size | ❌ Manual design‑system tokens |
| ✅ Automatic scoping (unique class names) | ❌ Verbose (separate files) |
| ✅ Standard CSS syntax | ❌ No utility classes |
| ✅ Works everywhere (native Vite/Webpack) | ❌ Hard to maintain design consistency |
Best for: Small projects, teams comfortable with traditional CSS, need absolute smallest bundle.
Other CSS‑in‑JS Option (Performance‑Focused)
What it is: Framework‑agnostic CSS‑in‑JS library similar to Styled Components but lighter.
- GitHub Stars: 17k+ ⭐
- NPM Downloads: 2.5 M/week 📦
- Version: 11.11.0
- Bundle Size: ~7 KB runtime
Pros & Cons
| Pros | Cons |
|---|---|
| ✅ Smaller than Styled Components (~7 KB) | ❌ Still runtime CSS‑in‑JS (injection cost) |
| ✅ Better performance than Styled Components | ❌ Smaller community |
| ✅ Framework‑agnostic | ❌ SSR complexity |
Best for: Performance‑conscious CSS‑in‑JS users, multi‑framework projects.
Feature Comparison
| Feature | Tailwind v4 | Tailwind v3 | Styled Components | CSS Modules | Other CSS‑in‑JS |
|---|---|---|---|---|---|
| Build Speed | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Runtime Perf | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| HMR Speed | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| Type Safety | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ |
| DX (Ease of Use) | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Bundle Size | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Maintainability | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ |
| Config Simplicity | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Design System | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐ |
| Ecosystem | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Community | Growing | Massive | Large | Universal | Medium |
| Learning Curve | Lowest | Low | Medium | Low | Medium |
Test Setup
- Project: Portfolio app with 50+ components
- Files: 180 TypeScript/TSX files
- Styles: Design system with 15 color tokens, 8 spacing scales
- Machine: MacBook Pro M2, 16 GB RAM
- Date: December 2025
Benchmark Results
Build & HMR Performance
| Tool | Initial Build | Rebuild (HMR) | Production Build |
|---|---|---|---|
| Tailwind v4 | 1.2 s | 85 ms | 2.8 s |
| Tailwind v3 | 12.4 s | 520 ms | 8.1 s |
| Styled Components | 8.7 s | 380 ms | 12.3 s |
| CSS Modules | 2.1 s | 120 ms | 3.2 s |
| Emotion | 7.2 s | 320 ms | 10.5 s |
Winner: Tailwind v4 (10× faster than v3, 7× faster than Styled Components).
Bundle Size (gzipped)
| Tool | CSS Output | JS Runtime | Total |
|---|---|---|---|
| Tailwind v4 | 12.3 KB | 0 KB | 12.3 KB |
| Tailwind v3 | 14.1 KB | 0 KB | 14.1 KB |
| Styled Components | 18.7 KB | 16 KB | 34.7 KB |
| CSS Modules | 8.2 KB | 0 KB | 8.2 KB |
| Emotion | 15.3 KB | 7 KB | 22.3 KB |
Winner: CSS Modules (smallest), Tailwind v4 (best utility‑framework size).
Runtime Metrics
| Tool | First Paint | Total Blocking Time | Style Recalc |
|---|---|---|---|
| Tailwind v4 | 0.8 s | 0 ms | 12 ms |
| Tailwind v3 | 0.8 s | 0 ms | 14 ms |
| Styled Components | 1.2 s | 35 ms | 28 ms |
| CSS Modules | 0.7 s | 0 ms | 10 ms |
| Emotion | 1.0 s | 22 ms | 18 ms |
Winner: CSS Modules (pure CSS), Tailwind v4 (best utility‑framework performance).
Conclusion
Tailwind CSS v4 isn’t just “faster Tailwind”; it represents a fundamental rethinking of how CSS frameworks should work in 2025:
- Performance: Orders‑of‑magnitude faster builds and HMR.
- Configuration: Pure‑CSS, eliminating bulky JavaScript config.
- Maintainability: Simpler, type‑safe theming via
@theme. - Ecosystem: Growing community with Rust‑based tooling.
For new, performance‑critical applications—or any project that can adopt the CSS‑first paradigm—Tailwind v4 is the clear choice. Existing projects may still benefit from the stability of Tailwind v3, while CSS‑in‑JS and CSS Modules remain viable for niche use‑cases requiring dynamic styling or absolute minimal bundles.