The Tailwind CSS4 debate is everywhere right now. And honestly? Most people are arguing about the wrong thing.

The real question isn't "inline styles vs. utility classes" — it's about where your styling decisions live and who pays the cognitive cost.

Let me break down what's actually happening, with real code, real trade-offs, and a clear take at the end.

What Changed in Tailwind CSS v4

Tailwind CSS v4 introduced a major shift: CSS-first configuration. Instead of a tailwind.config.js, you define everything in your CSS file using @theme:

/* Before (v3) - tailwind.config.js */
module.exports = {
  theme: {
    extend: {
      colors: {
        brand: '#6366f1',
      },
      spacing: {
        18: '4.5rem',
      }
    }
  }
}

/* After (v4) - main.css */
@import "tailwindcss";

@theme {
  --color-brand: #6366f1;
  --spacing-18: 4.5rem;
}

This is cleaner for many workflows. But it's not what's causing the drama.

The Real Flashpoint: Utility Density in JSX

What's actually triggering the discourse is how v4 accelerates a pattern that was already polarizing — components that look like this:

// The "inline styles but make it Tailwind" pattern
function AlertBanner({ type, message }) {
  return (
    <div className={`
      flex items-center gap-3 px-4 py-3 rounded-lg border
      ${type === 'error' 
        ? 'bg-red-50 border-red-200 text-red-800' 
        : 'bg-blue-50 border-blue-200 text-blue-800'}
    `}>
      <span className="text-sm font-medium">{message}</span>
    </div>
  );
}

vs. the @apply approach many teams prefer:

/* alert.css */
.alert {
  @apply flex items-center gap-3 px-4 py-3 rounded-lg border;
}
.alert--error {
  @apply bg-red-50 border-red-200 text-red-800;
}
.alert--info {
  @apply bg-blue-50 border-blue-200 text-blue-800;
}

// Cleaner component
function AlertBanner({ type, message }) {
  return (
    <div className={`alert alert--${type}`}>
      <span className="text-sm font-medium">{message}</span>
    </div>
  );
}

Both work. Neither is objectively wrong. But they encode very different philosophies.

The Philosophical Split (This Is the Real Debate)

Camp A: Co-location is king.
Styling 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.

Camp B: Semantic names have value.
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.

Tailwind 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.

The Scalability Question

Here's my honest take after working with both approaches on teams of different sizes:

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.

@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.

The mistake is treating this as a universal answer. It's an organizational question dressed up as a technical one.

What I'd Actually Recommend

1. For solo projects or small teams: Go full utility classes. Embrace the v4 improvements. The productivity gain is real.

2. For component libraries you publish: Use @apply or CSS custom properties. Your consumers shouldn't need to know your design tokens.

3. For large apps with a design system team: Hybrid. Design system owns semantic classes. Application layer uses utilities for one-off layouts.

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.

The Hot Take

The 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.

Fix your workflow before blaming the framework.

Tailwind 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.

Make the decision. Document it. Move on.

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.