When it pays off, and when it costs you

You now have the whole way of writing. The last thing is deciding when to use it.

Tailwind isn’t universal. Where it fits, it’s very strong; where it doesn’t, it’s more work than plain CSS. Once you can tell the difference, you’re using it as a tool rather than following it.

There’s one axis that matters

Many comparisons are possible, but this is the question that does the most work.

Which makes the decision:

• Grown over time, changing hands, reused components → Tailwind pays off
• Built once, by you alone, a handful of pages → plain CSS is fine

Situation by situation

What to do when the classes get too long

The biggest complaint about Tailwind is long HTML. There’s an order to the fixes. Work down it.

1. Fix the order (start here)

<!-- sort as: no prefix → md: → lg: -->
<div class="grid grid-cols-1 gap-4 p-4 md:grid-cols-2 md:gap-6 lg:grid-cols-3">

This alone changes how readable it feels. It needs nothing installed, so start here.

2. Extract a component

If you’ve written the same class sequence three times, that’s the signal to make it a component. In React, Vue, or even a WordPress template part—wrap up the repeating HTML itself.

// the class list exists in one place; call sites stay short
function Button({ children }) {
  return (
    <button className="px-6 py-3 bg-orange-500 text-white font-bold rounded-full hover:bg-orange-600 transition">
      {children}
    </button>
  );
}

This is where Tailwind is at its best. The “classes are long” problem is designed to be solved by componentising.

3. Collapse with @apply (last resort)

@apply lets you fold utilities into one class inside your CSS.

.btn {
  @apply px-6 py-3 bg-orange-500 text-white font-bold rounded-full;
}

It looks pleasingly short, but doing this erases most of Tailwind’s benefit.

• You can no longer tell where .btn is used (so you can’t delete it)
• The HTML no longer shows the styling (you’re back to opening the stylesheet)
• Net result: plain CSS, with only the build step left over

If you use it at all, limit it to something like one button style genuinely used in dozens of places. Once you start “collapsing everything with @apply because the classes are long,” you’ve removed the reason to use Tailwind.

Where to draw the line when mixing

Mixing is fine—most projects do. What matters is deciding which one writes what.

A split that works well:

It’s simply Tailwind for what utilities express naturally, plain CSS for what they don’t. Rather than contorting something into an unreadable [&>*:nth-child(3)]:mt-[13px], a few lines of plain CSS is kinder.

What you keep even if you go back to plain CSS

Having come this far, there’s a return that stays with you regardless.

• Thinking in steps—not 13px but 16 or 24. You can do the same in plain CSS with variables
• The mobile-first habit—writing with min-width only becomes automatic
• Asking “can this be deleted?”—you start structuring plain CSS to be deletable too

So even if you decide not to use Tailwind, what you learned isn’t wasted. Taking the tool’s ideas and applying them in plain CSS is a perfectly good outcome.

Summary of this lesson

1. The axis that matters: “could someone delete this CSS six months from now?”
2. Grown over time, reused components, team work → Tailwind pays off
3. A one-pager, learning, editing an existing site → plain CSS is more natural
4. For long classes: fix the order → componentise. @apply is the last resort
5. Overusing @apply erases the benefits and leaves you at plain CSS
6. Mixing is fine, but never set the same property from both sides
7. Thinking in steps, mobile-first, deletable structure—these stay with you either way

A tool only becomes a tool once you can choose it. If you can now state both the reasons to use it and the reasons not to, this course has done its job.