Tailwind Isn't Just Utility Classes — It's a Different Way of Thinking About CSS

The argument against Tailwind is always the same: the HTML gets cluttered, the class strings are unreadable, it violates separation of concerns. I've heard it enough times to understand it, and I'll admit that when I first looked at a Tailwind component — a div with thirty classes crammed into it — my initial reaction wasn't positive either.

But here's the thing about that reaction: it assumes that the alternative is clean. And anyone who's spent real time maintaining a CSS codebase at scale knows that "clean" CSS tends to be a fiction we tell ourselves early in a project, before the accumulation of specificity overrides, dead selectors, and naming conventions that nobody quite agreed on starts to take its toll.

The co-location argument

The strongest case for Tailwind isn't about syntax. It's about information locality. When styles and markup live in the same file, you can understand what a component looks like without jumping between files. You can delete a component and know with certainty that you haven't left orphaned CSS somewhere. You can read a PR diff and see exactly what changed visually without cross-referencing a stylesheet.

This sounds trivial until you've spent an afternoon trying to figure out whether a CSS class is still used anywhere before deleting it. Or until you've onboarded an engineer who spent a week writing styles in a new naming convention before realizing the team had already settled on a different one. Co-location doesn't just affect code aesthetics — it affects the practical cost of maintaining and evolving a UI over time.

Constraints as a design tool

One of the most underappreciated things about Tailwind is what it doesn't let you do. You can't set padding: 13px without reaching for an arbitrary value. The spacing scale goes p-2, p-3, p-4. If you want something between them, you have to make a deliberate choice to step outside the system.

That friction is a feature. In traditional CSS, it's trivially easy for a UI to accumulate dozens of slightly different spacing values — 12px here, 14px there, 15px in that one component someone built on a Friday. The resulting inconsistency is subtle but cumulative. Tailwind's scale makes consistency the path of least resistance, and inconsistency the deliberate exception.

The component abstraction layer

The class-string readability problem is real, but it's largely solved by the same thing that solves it in any other approach: abstraction at the right level. In React with Tailwind, that means creating a component for any UI pattern you repeat more than twice. You don't write twenty classes on every button; you write them once in the Button component and use it everywhere.

This is the pattern that makes Tailwind scale. The class verbosity lives inside the component definition, which is the one place you expect verbosity. At the usage site, things stay clean. The difference between Tailwind working well and working poorly in a codebase is almost always whether this abstraction step happened.

Where I still reach for CSS

For all the productivity gains, there are cases where Tailwind gets in the way. Complex animations with multiple keyframe steps are much cleaner in a CSS file. Highly dynamic styles where the class names themselves are computed from data are better handled with CSS custom properties or inline styles. And for design systems that need to be consumed as a package by external teams, shipping raw Tailwind classes leaks implementation details in ways that CSS variables don't.

The honest position is that Tailwind and CSS aren't in opposition. In most production codebases I've worked on, there's a small amount of global CSS for things Tailwind genuinely doesn't handle well, and Tailwind for everything else. The goal isn't ideological purity — it's productive, maintainable UI code.

Conclusion

Three years in, the thing I value most about Tailwind isn't the speed of writing styles — though that's real. It's the way it makes the cost of inconsistency visible. When you're working within a constrained scale, deviations stand out. The arbitrary value syntax, the bracket notation, it's a small signal that you've stepped outside the system, and it prompts the right question: is this deviation intentional, or is it drift?

That's not something you get from a blank CSS file. And for a discipline that struggles chronically with accumulated visual inconsistency, having friction built into the tool is more valuable than it looks.