{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibm6kf4lipir2bnro47ey7sedooxdbbriv4hwl7lizylqzqx23qqu",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mos3ezml6bl2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreiceff44ab5rylwsdzo6sf4v3cfhojntktyvjv3eifopihwsz4kz3m"
    },
    "mimeType": "image/webp",
    "size": 67090
  },
  "path": "/enjoy_kumawat/the-real-reason-everyones-fighting-about-tailwind-css-v4-4o0g",
  "publishedAt": "2026-06-21T09:36:34.000Z",
  "site": "https://dev.to",
  "tags": [
    "css",
    "tailwindcss",
    "webdev",
    "frontend",
    "@apply",
    "@theme",
    "@import"
  ],
  "textContent": "The Tailwind CSS4 debate is everywhere right now. And honestly? Most people are arguing about the wrong thing.\n\nThe real question isn't \"inline styles vs. utility classes\" — it's about **where your styling decisions live and who pays the cognitive cost.**\n\nLet me break down what's actually happening, with real code, real trade-offs, and a clear take at the end.\n\n##  What Changed in Tailwind CSS v4\n\nTailwind CSS v4 introduced a major shift: CSS-first configuration. Instead of a `tailwind.config.js`, you define everything in your CSS file using `@theme`:\n\n\n\n    /* Before (v3) - tailwind.config.js */\n    module.exports = {\n      theme: {\n        extend: {\n          colors: {\n            brand: '#6366f1',\n          },\n          spacing: {\n            18: '4.5rem',\n          }\n        }\n      }\n    }\n\n\n\n    /* After (v4) - main.css */\n    @import \"tailwindcss\";\n\n    @theme {\n      --color-brand: #6366f1;\n      --spacing-18: 4.5rem;\n    }\n\n\nThis is cleaner for many workflows. But it's not what's causing the drama.\n\n##  The Real Flashpoint: Utility Density in JSX\n\nWhat's actually triggering the discourse is how v4 accelerates a pattern that was already polarizing — components that look like this:\n\n\n\n    // The \"inline styles but make it Tailwind\" pattern\n    function AlertBanner({ type, message }) {\n      return (\n        <div className={`\n          flex items-center gap-3 px-4 py-3 rounded-lg border\n          ${type === 'error'\n            ? 'bg-red-50 border-red-200 text-red-800'\n            : 'bg-blue-50 border-blue-200 text-blue-800'}\n        `}>\n          <span className=\"text-sm font-medium\">{message}</span>\n        </div>\n      );\n    }\n\n\nvs. the `@apply` approach many teams prefer:\n\n\n\n    /* alert.css */\n    .alert {\n      @apply flex items-center gap-3 px-4 py-3 rounded-lg border;\n    }\n    .alert--error {\n      @apply bg-red-50 border-red-200 text-red-800;\n    }\n    .alert--info {\n      @apply bg-blue-50 border-blue-200 text-blue-800;\n    }\n\n\n\n    // Cleaner component\n    function AlertBanner({ type, message }) {\n      return (\n        <div className={`alert alert--${type}`}>\n          <span className=\"text-sm font-medium\">{message}</span>\n        </div>\n      );\n    }\n\n\nBoth work. Neither is objectively wrong. But they encode very different philosophies.\n\n##  The Philosophical Split (This Is the Real Debate)\n\n**Camp A: Co-location is king.**\nStyling logic belongs next to component logic. When you read the JSX, you see exactly how it looks. No context switching between files. No dead CSS accumulating over time. Deleting a component deletes its styles. This is why Tailwind exists.\n\n**Camp B: Semantic names have value.**\n`alert--error` tells you _what something is_. `bg-red-50 border-red-200 text-red-800` tells you _how it looks right now_. When a designer changes your error color to orange, Camp A needs to hunt through JSX. Camp B changes one CSS rule.\n\nTailwind v4 doesn't resolve this tension — it sharpens it, because the new config system makes it even easier to stay in CSS-land, which makes `@apply` feel more natural, which reignites the debate.\n\n##  The Scalability Question\n\nHere's my honest take after working with both approaches on teams of different sizes:\n\n**Tailwind utility classes scale better on small-to-medium teams** where everyone touches everything. Co-location wins because there's no coordination cost — you're not hunting for the right CSS class name someone else wrote three months ago.\n\n**`@apply` / semantic classes scale better on larger teams** with clear design system ownership. When a dedicated design-systems team owns the CSS layer, semantic class names become a stable API. Components consume that API and don't care about the implementation.\n\nThe mistake is treating this as a universal answer. It's an organizational question dressed up as a technical one.\n\n##  What I'd Actually Recommend\n\n  1. **For solo projects or small teams** : Go full utility classes. Embrace the v4 improvements. The productivity gain is real.\n\n  2. **For component libraries you publish** : Use `@apply` or CSS custom properties. Your consumers shouldn't need to know your design tokens.\n\n  3. **For large apps with a design system team** : Hybrid. Design system owns semantic classes. Application layer uses utilities for one-off layouts.\n\n  4. **Don't`@apply` to avoid reading utility classes**. That's not a scalability pattern, it's avoidance. Learn the utilities; they're worth the initial friction.\n\n\n\n\n##  The Hot Take\n\nThe people most loudly against Tailwind utility classes are usually fighting their tooling, not Tailwind itself. If your editor doesn't have Tailwind IntelliSense, if your team hasn't agreed on line-length limits for className strings, if you're writing utilities without a design token system underneath — _of course_ it feels unscalable.\n\nFix your workflow before blaming the framework.\n\nTailwind v4 is a solid release. The CSS-first config is genuinely better. The debate around it is mostly teams realizing they need to make explicit decisions they've been avoiding.\n\nMake the decision. Document it. Move on.\n\n_What's your team's approach? Are you all-in on utility classes, leaning on @apply, or somewhere in the middle? Drop it in the comments — I'm genuinely curious where the dev.to crowd lands on this._",
  "title": "The Real Reason Everyone's Fighting About Tailwind CSS v4"
}