Utility-first (Tailwind primer revisited)

Recap from B1 lesson 16 — now critique it

Utility-first CSS = a class per declaration:

<button class="bg-blue-500 text-white px-4 py-2 rounded-lg shadow hover:bg-blue-600">
  Click me
</button>

vs component-style:

<button class="btn btn-primary">Click me</button>
<!-- where .btn-primary CSS is elsewhere -->

Why utility-first wins (Tailwind's argument)

1. No naming. You don't invent .btn-primary-large-disabled — you compose bg-blue-500 px-6 py-3 opacity-50.
2. No file switching. All styling in the template you're looking at.
3. No unused CSS. Tailwind purges unused classes at build.
4. Constraint-driven. Tailwind's classes follow a 4/8/12/16/20 spacing scale — you can't accidentally pick "13px" for padding.

Why utility-first loses (the criticism)

1. HTML gets noisy — 20-character class strings.
2. Duplication on repeat — same string of classes copied 50 times.
3. Hard to refactor — "make all primary buttons blue" requires search-and-replace across templates.

The synthesis (2026 reality)

Most teams use BOTH:

• Utility classes for one-off layouts and prototyping.
• Component classes (.btn-primary) for reused widgets, often built FROM Tailwind utilities via @apply.

.btn-primary {
  @apply bg-blue-500 text-white px-4 py-2 rounded-lg shadow;
}
.btn-primary:hover {
  @apply bg-blue-600;
}

Best of both: short HTML, single source of truth.