Skip to content
← All articles

Tailwind CSS: why I switched and haven't looked back

I resisted Tailwind CSS for a long time. Utility classes in HTML felt wrong. Then I actually used it on a real project.

Tailwind CSS: why I switched and haven't looked back

For years, I wrote CSS the "proper" way. SCSS files with BEM naming conventions, carefully structured partials, variables for everything, media query mixins. It was organised, it was maintainable, and I was proud of it. When Tailwind CSS came along with its approach of putting utility classes directly in HTML, my initial reaction was visceral: that's inline styles with extra steps.

I was wrong. Not about everything, there are legitimate trade-offs, but about the overall approach. After using Tailwind on several projects this year, I'm convinced it's a better way to write CSS for most websites, yours included.

What changed my mind

The turning point was a project where I needed to build a component library quickly. With traditional CSS, I'd have spent time thinking about class names, file organisation, and naming conventions before writing any actual styles. With Tailwind, I just started building.

Need a blue button with rounded corners and a hover state? `bg-blue-600 text-white px-4 py-2 rounded hover:bg-blue-700`. It's right there in the HTML. I can see exactly what it looks like without switching to a CSS file. Want to change it? Change the classes. No hunting through stylesheets, no specificity battles, no wondering whether changing `.btn-primary` will break something three pages away.

The speed improvement was significant. I was building UI components noticeably faster, and, this is the part I didn't expect, the results were more consistent. Tailwind's spacing scale (4, 8, 12, 16, 20, 24...) and colour palette enforce consistency without me having to think about it.

The objections I had (and why they didn't hold up)

Objection one: the HTML is ugly. Yes, a Tailwind component has more classes than a BEM component. But in a component-based framework like React or Vue, you write each component once. The "ugly" HTML lives in one file, and when you render the component, you just write `<Button variant="primary">`. The complexity is contained.

Objection two: it's just inline styles. It's not. Tailwind gives you responsive prefixes (`md:text-lg`), state variants (`hover:`, `focus:`, `active:`), dark mode (`dark:bg-gray-900`), and a design system with consistent values. Inline styles can't do any of that.

Objection three: you'll never remember all the class names. This was a genuine concern for the first week. Then muscle memory kicked in, and the Tailwind CSS IntelliSense plugin in the editor handles autocomplete. I rarely need to look at the docs now.

Objection four: you'll end up with massive CSS files. Tailwind uses PurgeCSS (now built into the JIT compiler) to remove unused classes at build time. The production CSS file is typically 5-15KB. That's smaller than most hand-written stylesheets.

Where Tailwind fits best

Tailwind is excellent for component-based projects, Next.js, React, Vue, anything where you're building reusable components. It's great for design systems and UI-heavy applications. It pairs particularly well with headless CMS projects where the front-end is custom-built.

For WordPress themes, it works but requires more discipline. Without components to contain the complexity, you end up repeating long strings of classes across template files. It's manageable with proper use of WordPress template parts, but it's not Tailwind's strongest use case.

What I still use SCSS for

Global styles, base typography, and CSS that targets elements rather than classes, these are still easier in traditional CSS. Tailwind has `@apply` for extracting utility classes into CSS rules, but overusing it defeats the purpose. I typically use Tailwind for components and layout, with a small global stylesheet for base styles and typography.

The setup

Tailwind's configuration file (`tailwind.config.js`) is where you define your design tokens, colours, spacing, fonts, breakpoints. This becomes the single source of truth for your design system. Combined with the IntelliSense plugin, it gives you a design system that's enforced in your editor as you type.

If you're building a new project and haven't tried Tailwind, give it an honest two weeks on a real project, not a tutorial. The first few days feel strange. By the end of the first week, it clicks. By the end of the second, you won't want to go back.

If you're curious about whether Tailwind or another CSS approach is right for your project, feel free to reach out at [email protected].

Chris Ryan

Chris Ryan

Managing Director

17+ years in full-stack web development, most of it leading teams agency-side across e-commerce, CMS platforms, and bespoke applications. Specialises in infrastructure, system integration, and data privacy, with hands-on experience as a Data Protection Officer. Founded Innatus Digital in 2020 to offer the kind of honest, technically-led partnership that he felt was missing from the agency world.