Utility-First CSS with Tailwind
It looks ugly at first, but the speed of iteration is unmatched.Tailwind removes the context switch between HTML and CSS.You stop worrying about naming things(.wrapper - inner - container - left ) and start focusing on the UI.
The "Visceral Reaction"
Every developer goes through the same five stages of grief when they first see Tailwind:
- Denial: "This is just inline styles!"
- Anger: "You are polluting the HTML! What about Separation of Concerns?"
- Bargaining: "Okay, I'll use it for prototyping, but I'll write real CSS for production."
- Depression: "I can't believe I wasted years naming classes
.sidebar-left-inner-wrapper." - Acceptance: "I am never writing a CSS file again."
The reason for this reaction is decades of "Best Practices" dogma telling us to separate content(HTML) from presentation(CSS).But as Adam Wathan argues, we haven't been separating concerns; we've been separating files .
The Context Switch Tax
In traditional CSS(BEM or otherwise), the workflow looks like this:
- Write HTML structure.
- Think of a class name (hard).
- Create a CSS file.
- Write the class.
- Check the browser.
- Realize it's wrong.
- Go back to CSS file.
With Tailwind, you stay in the HTML.You apply flex items - center justify - between p - 4 and you're done. The feedback loop is immediate. This micro-optimization of workflow accumulates into massive velocity gains over a project's lifecycle.
Design consistency at Scale
Traditional CSS is full of "magic numbers." One developer uses margin: 15px , another uses margin: 1rem (16px), and a third uses margin: 18px . The UI becomes a jagged mess.
Tailwind enforces a design system.You can only use values from your config. p - 4 is always 1rem. text-lg is always 1.125rem.You are constrained to a harmonious scale.This makes "developer design" look significantly better because you can't easily break the grid.
The "Append-Only" Stylesheet Problem
How many times have you been afraid to delete a CSS class because you didn't know if it was used somewhere else? CSS is global and mutable. Over time, stylesheets grow monotonically. They never shrink.
With utility classes, you rarely write new CSS.You just reuse the existing utilities.Your CSS bundle size plateaus.Whether you have 10 pages or 1000 pages, the size of tailwind.css remains roughly the same (around 10kb compressed).
Component Abstraction: The Real Separation
Critics argue that Tailwind repeats code. "What if I have 50 buttons? Do I copy-paste bg-blue-500 text-white p-2 rounded 50 times?"
No.You extract a component.
In the React / Vue / Svelte era, the Component is the unit of reuse, not the CSS class. You build a <Button> component once, apply the utility classes there, and reuse the component.
When NOT to use Tailwind
Tailwind is not a silver bullet.It is terrible for:
- Dynamic content: If you are rendering a markdown blog post (like this one!), you don't want to add utility classes to every
<p>tag.Use the@tailwindcss / typographyplugin (prose class) instead. - Complex animations: While Tailwind has basic transitions, complex keyframe animations are often cleaner in a separate CSS/SCSS file or using a library like Framer Motion.
Conclusion
Tailwind is more than a CSS framework; it's a design tool for developers. It bridges the gap between the design file and the code. Once you get over the initial "ugly HTML" shock, you realize it's the most productive way to build modern web interfaces.