So you have heard about the Tailwind CSS and want to incorporate into your new project. But those inline styles look so polluted - they look similar to the old "style="font-size: 12px; color: green; font-style: italics" stuff we are told to avoid. What is going on here? Are we going back??
The Problem with Plain CSS Classes
Before you run the other way, I think we have all encounter this problem maintaining a large codebase:
/* Developer A wrote this 2 years ago */
.card-variant-3 {
background-color: #f3f4f6;
padding: 1rem;
border-radius: 0.5rem;
}
After 2 years, the stylesheet is 5,000 lines long. And this class could be used anywhere in the codebase of millions of lines.
Developer B is too scared to modify .card-variant-3 because they don't know if it's used on some obscure marketing page... So they just append a new class to the bottom of the file.
.card-variant-3-updated {
background-color: #f3f4f6;
padding: 1.5rem; /* <--- Only changed the padding! */
border-radius: 0.5rem;
}
The Problem: Bundle sizes grow linearly with the app. You have to spend your time naming things (.main-content-inner, .card-body-flex) and jumping between HTML and CSS files.
What Tailwind Gives Us
Tailwind solves this problem by creating "utility classes" such as "bg-mint-500", "text-mint-500", and "border-mint-500" from CSS variables which one can use in the HTML like so
<h1 className="text-mint-500"> Introduction </h1>
This restructure gives us two advantages:
The Reduced CSS Bundle Size: Because you reuse bg-mint-500 or p-4 over and over, you stop writing new CSS lines. Whether you have 10 pages or 10,000 pages, your production CSS stays virtually the same size (often a fraction of traditional stylesheets).
Dramatically Lower Risk in Refactoring: Everything that makes this element look the way it does lives exclusively inside this component block. If you delete the component, the styles are deleted instantly alongside it. There is absolutely zero risk of breaking a sidebar on the other side of your application.
What about Readability??
The biggest reason this is okay is that you only have to look at it occasionally.
In modern web development, we rarely write raw, static HTML pages anymore. We use component-based architectures (React, Vue, Svelte, Blade, Astro, etc.).
When you style an elements block like this, you immediately encapsulate it inside a reusable component. E.g.,
<Card variant="premium">
Once that component is saved, the "ugly" implementation details disappear behind a clean, semantic custom tag. Your main layout code remains pristine, while the styling mess is safely quarantined inside a single file.
Conclusion
We traded pretty markup for bulletproof maintainability. We allowed our HTML to look messy in development so that our production architecture could remain perfectly clean, predictable, and isolated.
Next
I will discuss more about Tailwind CSS in real projects. Follow me for more such articles!
Please comment below - how do you manage your CSS and do you think utility classes is a good idea??
Top comments (3)
I used to dislike Tailwind for the same reason: it looked like we were putting styles back into markup.
But after working on larger component-based projects, I started seeing the trade-off differently. The real problem was not “ugly HTML”, it was CSS that nobody felt safe changing anymore.
Utility classes make the styling local, visible, and easier to delete with the component. That alone solves a huge maintenance problem.
I still think teams need discipline, though. Tailwind can become messy too if every component turns into a giant wall of classes. For me, the sweet spot is Tailwind for layout and spacing, design tokens for consistency, and reusable components for anything repeated often.
I agree! The utility classes still doesn’t give a centralised theme for all the components. So, things can be messy if not disciplined.
Thanks for sharing your experience about the increased in maintain ability 😀 it certainly is a relief from the old pure CSS way…