My Tailwind CSS Journey: From "Never Again" to "I Get It Now"

I used to roll my eyes whenever someone mentioned Tailwind CSS. The class names looked like gibberish, the approach felt backwards, and I was convinced it was just another fad. Three years later, here I am writing this in a Tailwind-powered project. This is the story of how I went from vocal critic to... well, someone who gets it now.

The Eye-Rolling Phase

Let me paint you a picture of 2021 me encountering Tailwind for the first time:

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
  Click me
</button>

My immediate reaction? "This is everything wrong with modern web development." I'd spent years learning about separation of concerns and maintainable CSS architectures. This felt like going backwards to inline styles.

I distinctly remember complaining to a colleague: "Why would I want to put my entire stylesheet in my HTML?" I was so convinced I was right that I didn't even bother trying it properly.

What really sealed my rejection was Tailwind Plus. No dark mode support? Interactive components that didn't actually work without a JavaScript framework? I tried DaisyUI as an alternative, but the aesthetic never clicked.

I filed Tailwind away as "not for me" and moved on.

The Slow Realization

Fast forward to earlier this year. I was working on a side project and getting increasingly frustrated with my CSS setup. I had this elaborate system of CSS modules and design tokens that worked, but every small change felt like a production.

Want to adjust spacing? Edit the CSS file, make sure it doesn't break anything else, rebuild, test. Want dark mode? Hope you used CSS custom properties everywhere, because you're about to find out where you didn't.

Then I saw that Tailwind Plus had added full dark mode support and vanilla JavaScript for all components. My curiosity got the better of me.

The "Wait, This Actually Works" Moment

The first thing that caught my attention was the new vanilla JavaScript support. Every component was actually functional now, not just static HTML templates. Dropdowns worked. Modals worked. Command palettes worked. And they worked in my Rails projects without needing to add React or Vue.

But the real moment came when implementing a simple card component. In my old setup, this meant creating a new CSS module, defining styles, ensuring design system consistency, adding dark mode variants, and testing.

With Tailwind, I just... wrote the classes directly. The spacing was automatically consistent. Dark mode was just adding dark: prefixes. The component was self-contained and portable.

I remember thinking, "Huh. This is actually kind of elegant."

The Mindset Shift

What I hadn't understood was that Tailwind isn't about individual utility classes—it's about having a design system baked into your workflow.

When I see space-y-4, I'm using a consistent spacing scale across my entire application. When I use text-gray-600 dark:text-gray-300, I'm using a color system that someone smarter than me has already thought through.

The verbosity that used to annoy me became a feature. There's no mystery about what's happening. No hunting through CSS files. No wondering if it's safe to change a style without breaking something else.

The Long Class Names Problem (Spoiler: It's Not)

I know some of you are thinking, "But those class names are still ridiculous!" And yeah, sometimes they get long. But here's what I realized: in real applications, you're working with components anyway. for example, the tailwind official documentation has an great example of primary button extract.

That verbose button becomes:

@import "tailwindcss";
@layer components {
  .btn-primary {
    border-radius: calc(infinity * 1px);
    background-color: var(--color-violet-500);
    padding-inline: --spacing(5);
    padding-block: --spacing(2);
    font-weight: var(--font-weight-semibold);
    color: var(--color-white);
    box-shadow: var(--shadow-md);
    &:hover {
      @media (hover: hover) {
        background-color: var(--color-violet-700);
      }
    }
  }
}

The Tailwind classes live inside the Button component where they belong. You get the flexibility of utilities when building components, and clean APIs when using them.

What Actually Convinced Me

It wasn't the productivity claims—it was the maintenance experience.

I've been working on that side project for six months now, and I haven't once had to debug a CSS specificity issue. I haven't had to refactor my styling architecture because it got unwieldy. The codebase feels stable in a way my previous CSS setups never did.

The dark mode thing that I used to complain about? Now it's my favorite feature. I recently added dark mode to an entire application in about two hours. Two hours! For something that used to take me days.

I'm Still Not a Zealot

Don't get me wrong—Tailwind isn't the answer to all CSS problems. Complex animations, intricate layouts, truly custom designs—sometimes you need the full power of CSS.

But for the majority of interface development? Building forms, laying out components, creating consistent spacing? Tailwind just works. It works in a way that lets me focus on the problems I actually want to solve.

The Advice I'd Give My Past Self

Stop being so precious about "the right way" to write CSS. The right way is the way that lets your team ship features without constantly fighting the styling system.

Try it on a real project, not just a todo app. Build something complex enough that you'll run into the maintenance challenges Tailwind is designed to solve.

Don't worry about the class names. They'll feel natural faster than you think.

Where I Stand Now

Am I a Tailwind convert? I guess so, though I hate that term. I'm more of a Tailwind pragmatist.

It's become my default choice for new projects because it solves more problems than it creates. The development experience is smooth, the maintenance burden is low, and I can focus on building features instead of wrestling with CSS architecture.

The web development landscape changes fast. Sometimes the best thing you can do is admit when you were wrong and embrace something better.

Tailwind turned out to be one of those moments for me. Maybe it will be for you too.

---

What's your Tailwind story? Love it, hate it, still on the fence? I'm curious to hear about other developers' journeys with utility-first CSS.