Why I Still Use Tailwind

Brief thoughts on why Tailwind continues to be my default choice for styling, and the critiques I think are valid.

Every six months a fresh wave of "Tailwind is bad" posts hits the timeline. I read them, I steelman them, and I keep using Tailwind. Here is why, plus the critiques I think actually hold up.

What I want from a styling system

Before I defend any tool, let me say what I am optimizing for:

1. Consistency across a codebase without writing a design system from scratch.
2. Speed when prototyping and when iterating with a designer.
3. Maintainability when I come back to the code in six months.
4. Performance in the shipped output.
5. Compatibility with how I want to compose components.

Tailwind is not the only way to get these. It is the way that has cost me the least over the past few years across enough projects that I trust the verdict.

The case for utilities

The strongest argument for Tailwind is one Adam Wathan made years ago: separating concerns is good, but the boundary "HTML for structure, CSS for style" is the wrong boundary in component based UIs. The real unit of reuse is the component, not the class.

Once your unit of reuse is a component, the question becomes "how do I style this component cheaply and predictably." Utility classes are cheap. They do not require switching files. They are constrained to the design tokens you define. They make refactors local.

You do not have to invent a class name for every variation. flex items-center gap-3 is just what it is. There is no "is this called a card or a tile" debate to have.

The constraints are the feature

Tailwind's spacing scale, color palette, font sizes, and breakpoints push you toward a coherent design without you noticing. Pure CSS gives you infinite freedom, and that is exactly the problem. Without constraints, I will pick a slightly different padding in three places by accident.

The design tokens in tailwind.config.ts are the actual contract. The classes are how you spend that contract.

What I think the critics get right

• Long class strings can be hard to read. They can. The fix is component extraction, not switching tools. If you find yourself copying the same string in three places, that is a component, not a Tailwind problem.
• The HTML can feel busy. True, especially in raw form. Editor extensions and class sorting (via the official Prettier plugin) help a lot.
• Onboarding takes a beat. New engineers need a day or two to internalize the naming. After that, productivity goes up.
• Highly bespoke designs hit the limits. For one off marketing pages with very specific art direction, I sometimes drop into a CSS module. Tailwind plays well with that, which is part of why it works for me.

What I think the critics get wrong

• "It is just inline styles." It is not. Tailwind goes through a build step, has design tokens, supports media queries and pseudo classes, and produces a single deduplicated stylesheet. Inline styles do none of that.
• "It bloats your HTML." Maybe by a few kilobytes that compress beautifully. It also lets you skip shipping a 50KB component CSS file.
• "It locks you in." Every styling choice locks you in. Switching from CSS modules to BEM is also a rewrite. The migration cost from Tailwind is mostly mechanical.

When I do not use Tailwind

• When I am writing a tiny static page that will never grow.
• When I am inside a design system that has its own component library and I just compose those components.
• When the project already has a strong CSS in JS culture and I am the visitor.

In those cases, fighting the prevailing style is more expensive than going along with it.

The quiet reason

The honest, less defensible reason I still use Tailwind is muscle memory. I can lay out a UI faster in Tailwind than in any other system because I have done it thousands of times. That speed compounds. When I am working with a client on a tight timeline, the styling layer should not be where I burn budget.

If you are starting a project today and you do not have strong opinions, Tailwind plus shadcn/ui will get you to a clean, accessible, maintainable UI faster than anything else I have used. That is a hard combination to argue with.

References

• Tailwind CSS
• Adam Wathan: CSS Utility Classes and Separation of Concerns
• shadcn/ui