Tailwind CSS is a powerful utility-first framework, but its approach often clashes with traditional CSS methodologies, leading some developers to prefer alternatives due to concerns about HTML readability, maintenance, and the principle of separation of concerns.

Confessions of a Cloud Architect: Why My Devs Sometimes Hate Tailwind CSS

I remember it clear as day. It was a Tuesday, sprint review was in two hours, and I was doing a final once-over on a PR from a junior dev. It was a simple feature—just a new modal with a primary and secondary button. But when I opened the file, my screen was flooded. The component for a single button looked like a classified government document, a long, unreadable string of classes: <button class="py-2 px-4 bg-blue-500 text-white font-semibold rounded-lg shadow-md hover:bg-blue-700 focus:outline-none focus:ring-2 focus:ring-blue-400 focus:ring-opacity-75">. I audibly groaned. This wasn’t maintainable; it was a bug waiting to happen. The dev wasn’t wrong, but this was the exact moment I realized why the “Tailwind vs. The World” debate isn’t just noise—it’s a real friction point in teams.

The ‘Why’ Behind the Pushback: It’s Not Just About Style

I was scrolling through Reddit the other day and saw a thread titled “Are there developers who still don’t prefer Tailwind CSS as their first choice?”. The comments were a battlefield, but the core complaints were all things I’ve heard from my own team. It’s not that developers are Luddites; it’s that Tailwind challenges a core principle we were all taught: separation of concerns. For decades, the mantra was: HTML is for structure, CSS is for style, and JavaScript is for behavior. Tailwind purposefully blurs the line between HTML and CSS, and for many, that feels like a step backward.

The common grievances I see are:

• HTML Bloat & Readability: That button example says it all. Your markup becomes incredibly verbose, making it hard to discern the actual structure of the component from its styling.
• Loss of Semantics: Instead of a meaningful class like <button class="btn-primary-destructive">, you have a string of utilities that only describe appearance. This makes it harder to search the codebase for all instances of a specific component type.
• The “It’s Just Inline Styles” Argument: This is a bit reductive, but the feeling is understandable. It looks and feels like you’re just writing CSS properties directly in your HTML, which we’ve been told for years is a cardinal sin.

So, if you’re a manager or a lead seeing this friction, don’t dismiss it. Your developers have valid concerns rooted in good software design principles. The key is to find a middle ground. Here are the three paths we usually consider at TechResolve.

The Fixes: Three Paths to CSS Sanity

Solution 1: The Pragmatic Compromise (Component Classes with @apply)

This is my go-to for teams who love Tailwind’s utility system but hate the cluttered HTML. You get the best of both worlds. You keep the power and consistency of Tailwind’s design tokens but abstract the long class strings into semantic component classes.

Instead of writing the utilities in the HTML, you define a component class in your global CSS file using Tailwind’s @apply directive.

/* in your main CSS file, e.g., styles.css */
.btn-primary {
  @apply py-2 px-4 bg-blue-500 text-white font-semibold rounded-lg shadow-md;
}

.btn-primary:hover {
  @apply bg-blue-700;
}

.btn-primary:focus {
  @apply outline-none ring-2 ring-blue-400 ring-opacity-75;
}

Now, your HTML is back to being clean, semantic, and beautiful:

<button class="btn-primary">Save Changes</button>

Darian’s Take: This is the path of least resistance. It keeps everyone happy. The designers can think in terms of Tailwind’s spacing and color scale, and the developers get to write clean, reusable CSS classes. The main drawback is you’re now managing a CSS file again, which is what Tailwind tries to help you avoid.

Solution 2: The Purist’s Path (Go Back to Sass/BEM)

Sometimes, Tailwind is just the wrong tool for the job. If you’re working on a project with a highly rigid, established design system that rarely changes—think a large enterprise dashboard used internally—the flexibility of utility classes can be more of a liability than a benefit. It can lead to inconsistencies when devs go “off-script.”

In these cases, we fall back on the old reliable: a strict methodology like BEM (Block, Element, Modifier) with Sass. It’s predictable, scalable, and enforces a strict structure.

A BEM example looks like this:

<!-- The 'Block' -->
<div class="card">
  <!-- The 'Element' -->
  <h2 class="card__title">Card Title</h2>
  <!-- The 'Element' with a 'Modifier' -->
  <button class="card__button card__button--primary">Click Me</button>
</div>

This approach is incredibly explicit and makes it clear how components are structured and related. It’s not as fast for prototyping, but it’s rock-solid for long-term maintenance on large, stable systems.

Solution 3: The ‘Nuclear’ Option (Component-First Frameworks)

This is the “why are we even writing CSS?” option. For many modern web apps, especially internal tools or dashboards running on our `prod-app-cluster-01`, the UI is secondary to the functionality. We don’t need a pixel-perfect, bespoke design. We need functional, accessible, and consistent components—fast.

Here, we skip writing our own CSS almost entirely and lean on a component-first library like Chakra UI, Material-UI (MUI), or Ant Design. These libraries give you pre-built, themeable components that handle styling via props.

For example, here’s a button in Chakra UI (a popular choice as it uses a similar utility-prop philosophy to Tailwind):

import { Button, ButtonGroup } from '@chakra-ui/react'

function MyComponent() {
  return (
    <Button
      colorScheme='blue'
      px='6'
      py='3'
      fontWeight='semibold'
      boxShadow='md'
    >
      Save Changes
    </Button>
  )
}

The styling is right there with the component logic, which is a natural fit for the React/Vue component model. You trade fine-grained CSS control for development speed and consistency.

At a Glance: Choosing Your Path

My Final Take

Look, I’m a pragmatist. On my watch, I don’t care if we use Tailwind, BEM, or carrier pigeons, as long as we ship reliable code that’s easy to maintain. The “right” choice depends entirely on your project’s needs and your team’s comfort level. For most new projects at TechResolve, we start with pure Tailwind and pivot to the `@apply` method if the HTML starts to feel messy. It’s about finding the right tool for the job, not winning a flame war on the internet. Now, if you’ll excuse me, I’ve got a PR to review with a very long class list.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions