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??