I Don’t “Use Tailwind”

uriByuri CSS, Tailwind

A question that comes up a lot: “Do you use Tailwind?”

My answer disappoints anyone looking for a strong opinion: it depends.

I don’t hate Tailwind. I’ve used it. I’ll use it again. I’m just not converting my whole worldview to utility-first CSS.

Tooling isn’t an identity. It’s a decision.

Tools Are Tools, Not Identities

Somewhere along the way, our industry started treating framework choices like personality traits. “I’m a Tailwind developer” or “I’m anti-Tailwind” as if those are meaningful things to be. I’d rather be the kind of builder who picks tools when they’re the best fit and doesn’t feel the need to marry any of them.

Why Tailwind Isn’t My Default

After reflecting on how I actually work, a few patterns explain why Tailwind hasn’t become my go-to:

I value readability over efficiency. Tailwind is fast, but it pushes styling into long class strings. When I open a component and see 30 classes, I’m not thinking about design I’m parsing syntax. Months later, I want to see “this component has these styles” in one place.

I bias toward minimalism. A lot of what I build is small, clean, low-dependency, and easy to ship: CLI tools, plugins with minimal runtime behavior, systems that don’t overreach. Tailwind comes with a build step, config, and conventions. That’s not a dealbreaker — it’s just an ecosystem decision I don’t default to unless the payoff is obvious.

I design for maintenance, not just speed. Tailwind shines when you’re shipping UI fast and iterating hard. But when I’m thinking about what this code looks like in 18 months, I start worrying about class soup and how much styling logic ends up living in markup — a pattern I never fully loved.

I’m not building UI all day. Most of my work lives in backend systems, developer tools, and product infrastructure. Tailwind becomes a default when you’re living in UI constantly. That’s not my world.

When I Reach for Tailwind

None of this means Tailwind is bad. It’s genuinely great when:

  • Speed matters more than long-term structure
  • The project is UI-heavy with lots of iteration
  • There’s already Tailwind in the stack
  • I’m working from an existing component library or design system
  • The client or team requires it

In those situations, I’m not going to fight the tool. I’ll use it and appreciate what it does well.

When I Don’t

I skip Tailwind when:

  • Portability matters (shipping something that shouldn’t assume a styling pipeline)
  • I want minimal build tooling
  • Long-term readability is the priority
  • I’m building plugins or libraries that need to stay dependency-light

The Pragmatist’s Position

I’ve landed on what I’d call a CSS pragmatist stance: no tribal loyalty, no reflexive rejection. Just one question every time:

What’s the best tool for this specific job?

Sometimes that’s Tailwind. Sometimes it’s scoped CSS. Sometimes it’s design tokens and a thin abstraction layer. Sometimes it’s just writing normal CSS and moving on with my life.

So no I don’t “use Tailwind.” I use tools.

I use what works.