Why We Use Tailwind CSS

When Tailwind CSS first appeared, the reaction from much of the developer community was scepticism. Writing styles directly in your HTML felt like a step backwards - a return to the inline styles we had spent years moving away from. We were sceptical too. Then we used it on a project, and we have not looked back since.

Tailwind is now a default part of our stack. It ships with every new React and Next.js project we start, and it has found its way into our Laravel projects via Blade components and Livewire. This post explains why.

What Tailwind Actually Is

Tailwind is a utility-first CSS framework. Rather than providing pre-built components like a button or a card with their own class names and opinionated styles, it gives you a comprehensive set of single-purpose utility classes - flex, pt-4, text-gray-900, rounded-lg - that you compose directly in your markup to build whatever you need.

The contrast with something like Bootstrap is stark. In Bootstrap, you apply btn btn-primary and get a styled button. In Tailwind, you build the button yourself from utilities. The result looks like more work on paper. In practice, it is significantly less.

The Problem Tailwind Solves

The traditional approach to CSS - writing semantic class names and styling them in a separate stylesheet - sounds clean in theory. In practice, it creates a number of persistent problems that compound over time.

The first is naming. Coming up with meaningful, non-conflicting class names for every element in a growing application is genuinely difficult. BEM helps, but it adds significant verbosity and still requires discipline to maintain consistently across a team.

The second is dead code. CSS almost never gets deleted. Developers add styles confidently but remove them nervously, because it is rarely obvious whether a class is still in use. Stylesheets accumulate rules that no longer correspond to anything in the application, and the file grows without bound.

The third is specificity. As stylesheets grow, specificity conflicts become increasingly common. The fix is usually to add more specificity, which makes the problem worse. Anyone who has spent time debugging why a style is being overridden by something from three files away will recognise this immediately.

Tailwind sidesteps all three problems. There is no naming to agonise over. Styles live alongside the markup, so removing a component removes its styles. And specificity conflicts essentially disappear because you are not fighting a cascade - you are assembling styles from atomic pieces.

How It Works With React and Next.js

Tailwind was practically designed for component-based development. When your UI is built from discrete components, utility classes are not scattered across your codebase - they are encapsulated within the component that uses them. The styles for a button live in the button component. The styles for a card live in the card component. This is exactly the colocation that makes component architecture valuable.

In a Next.js application, this means your component files are entirely self-contained. You can look at a component and immediately understand its appearance without hunting through stylesheets. You can copy a component to another project and its styles come with it. You can delete a component and know with certainty that its styles are gone too.

The pairing of Tailwind with shadcn/ui has become particularly popular, and for good reason. shadcn/ui provides accessible, well-structured component primitives built on Tailwind that you copy directly into your project rather than installing as a dependency. You own the code, which means you can modify it freely. We use this combination regularly for admin interfaces and internal tools.

How It Works With Laravel

Tailwind integrates naturally with Laravel too. The official Laravel starter kits - including those for React, Vue, and Livewire - all ship with Tailwind configured out of the box. For projects using Blade for server-rendered views, Tailwind works just as well. The mental model is consistent regardless of which rendering approach you are using.

For Filament - the admin panel package we use regularly for Laravel applications - Tailwind is the underlying styling system. Understanding Tailwind makes it straightforward to extend and customise Filament components without fighting the framework.

Performance

One of the more counterintuitive aspects of Tailwind is that despite generating a large number of potential utility classes, production builds are extremely small. Tailwind scans your templates and includes only the classes you actually use. A typical production stylesheet is a few kilobytes.

This is a meaningful improvement over the alternative. A hand-crafted stylesheet in a mature application might contain tens of thousands of lines and include a significant proportion of rules that are never applied. With Tailwind, you get only what you use.

The Learning Curve

There is a learning curve. The class names are not always immediately obvious, and the first few days of using Tailwind involve a lot of documentation lookups. tracking-tight for letter-spacing, leading-snug for line-height, divide-y for borders between child elements - these are not necessarily intuitive if you are coming from writing CSS directly.

The payoff comes quickly though. Once the conventions become familiar, development speed increases noticeably. There is no context switching between HTML and CSS files, no naming decisions to make, and no stylesheet to maintain. Most developers on our team describe a similar experience: initial friction followed by a reluctance to go back.

When We Would Not Use It

Tailwind is not the right tool for every situation. If you are building a heavily design-system-driven product where your design team works primarily in a tool like Figma and hands off precise specifications, a more structured approach with design tokens and component libraries may serve you better. Tailwind's utility approach can also produce verbose markup in highly complex layouts, which some teams find harder to review in pull requests.

For the kind of work we do - Laravel APIs, React frontends, internal tools, and client-facing web applications - Tailwind hits the right balance of flexibility, speed, and maintainability. It is a practical choice rather than a fashionable one, and that is why it has stayed in our stack.

If you are starting a new project and wondering which direction to take for your frontend styling, get in touch - we are happy to talk through the options for your specific situation.