Why Tailwind CSS

Tailwind gives you small classes that each apply one CSS decision.

For example:

<article class="max-w-sm rounded-lg border border-gray-200 p-6">
  <h2 class="text-lg font-semibold text-gray-950">Deploy complete</h2>
  <p class="mt-2 text-sm leading-6 text-gray-600">
    The new version is live.
  </p>
</article>

Each class is a small CSS decision: maximum width, border, padding, font size, weight, color, or margin. Tailwind generates CSS for the utilities it detects in your source. The browser still receives ordinary CSS.

The utility-first tradeoff is where composition happens. Instead of inventing .notification-card, moving to a stylesheet, and switching back to markup, you compose the visual rules where the element is created. That makes dependencies visible and makes deletion safer: removing the element removes its utility usage too.

Tailwind also constrains common decisions through a shared theme. Reusing p-6, text-sm, and rounded-lg is more consistent than choosing unrelated values for every component. Responsive and state variants keep related decisions together:

<button class="bg-blue-600 px-4 py-2 text-white hover:bg-blue-700 md:px-6">
  Continue
</button>

There are costs. Class lists can become dense, repeated patterns need component extraction, and a utility name is not a substitute for understanding layout, cascade, accessibility, or responsive design.

Do not learn Tailwind by memorizing a catalog. Start with the CSS decision—“this parent should be a grid,” “this text needs a readable line height”—then find the utility that expresses it. DevTools can always show the generated declaration.

Your action is to build a small alert with six utilities. For each class, write the CSS property it controls. Remove one class at a time and use the computed-style panel to verify your prediction.