What Is Tailwind CSS?
Tailwind CSS is a utility-first CSS framework — instead of writing custom CSS classes, you compose styles directly in your HTML using small, single-purpose utility classes.
Tailwind CSS is a utility-first CSS framework: instead of writing custom CSS classes in a separate stylesheet, you compose styles directly in your markup using small, single-purpose utility classes like flex, mt-4, text-white, and bg-gray-900. You style elements where you use them, and a build step strips out every class you didn't actually use.
How it differs from component frameworks
Component frameworks like Bootstrap hand you pre-built, opinionated pieces — a .btn, a .card, a .navbar — with fixed styles you then override. Tailwind hands you the raw building blocks instead. There is no .card; there's rounded-lg, shadow-md, p-6, and bg-white, which you combine into whatever a card means in your design.
The practical result: with Bootstrap you fight the framework's defaults to make something look custom; with Tailwind there are no defaults to fight, because nothing is styled until you say so.
How it works
Tailwind ships thousands of utility classes generated from a config-driven design system — a spacing scale, a color palette, a typography scale, breakpoints. At build time, a compiler scans your source files for class names that actually appear and emits only those. Unused utilities never reach the browser, so the production CSS stays small (commonly 5–20 KB) no matter how large the framework's full vocabulary is.
State and responsiveness are handled with prefixes on the same class: hover:bg-gray-100, md:flex, dark:bg-black. The prefix encodes the condition, so a single line of markup can describe how an element looks across screen sizes, hover, focus, and dark mode.
A concrete example
<!-- Custom CSS approach: style lives in a separate file -->
<button class="primary-button">Submit</button>
<!-- Tailwind approach: style lives on the element -->
<button class="bg-white text-black font-bold uppercase tracking-widest px-8 py-4 rounded hover:bg-gray-100 transition-colors">
Submit
</button>
The Tailwind line looks verbose, and that's the honest trade. In exchange: you never switch files to read or change a style, there are no class names to invent, there are no specificity wars, and deleting the element deletes its styles with it — no orphaned CSS left rotting in a stylesheet.
Why it fits React and Next.js well
- Co-location. Component, markup, and styles live in one file, which matches how component frameworks already split a UI into self-contained pieces.
- No specificity conflicts. Utilities are flat and side-effect-free, so one component's styles can't leak into another's.
- Built-in design tokens. The spacing, color, and type scales enforce consistency without a separate design-system library.
- Small output. Only the classes you render ship to production.
Paired with a primitive library like shadcn/ui (accessible components built on Radix UI), Tailwind covers a full design foundation — keyboard-accessible components, dark mode, consistent spacing — without pulling in a heavy opinionated UI kit.
When Tailwind is not the right choice
| Use Tailwind when | Reconsider when |
|---|---|
| Small-to-mid product team shipping fast | Large org with dedicated designers wanting strict component contracts |
| You want one styling system, no naming overhead | Your team strongly prefers semantic class names and separation of concerns |
| Highly custom, frequently-changing UI | Heavy reuse of identical components better served by CSS Modules or styled-components |
Tailwind is not a silver bullet. For teams that want hard boundaries between design and markup, CSS Modules or styled-components can be a better fit. For most product teams iterating quickly, Tailwind is faster.
Common mistakes
- Repeating long class strings instead of extracting a component. When the same 12-class string appears five times, that's a sign to make a reusable component, not to copy-paste.
- Constructing class names dynamically by string concatenation. The compiler only keeps classes it can find as complete strings;
bg-${color}-500won't survive the build. Map to full class names instead. - Fighting the design scale. Reaching for arbitrary values like
mt-[13px]everywhere defeats the consistency the spacing scale provides. - Treating verbosity as a problem to hide. The class list is supposed to be visible — that's what makes a component's styling self-documenting.
Key takeaways
- Tailwind is utility-first: you compose tiny single-purpose classes in markup rather than writing custom stylesheets.
- It trades verbose markup for no naming, no specificity conflicts, co-located styles, and small purged output.
- It pairs naturally with React/Next.js and component primitives; it's less suited to teams that need strict design/markup separation.
This portfolio is built with Next.js and Tailwind CSS, and the same stack powers shipped client work — Callidus (clinic SaaS, React + Firebase) and Pizzeria Bestek (React + Supabase) among them. Need a Tailwind-based React or Next.js front end built? Contact for a quote.