I was curious about Tailwind CSS because it challenged a lot of the habits I had built up around writing CSS.
For years, my default approach had been to name components clearly, write styles in separate files and keep the markup fairly quiet. Tailwind pushed in a different direction. The utility classes made styling faster in some situations, but they also made the HTML look busy very quickly. I wanted to understand whether the speed was worth the trade-off.
Starting With A Small Interface
I did not start by rebuilding an entire website. That would have made it harder to judge the tool properly. Instead, I used Tailwind on a small interface pattern: a card grid with an image, heading, short description and link. That was enough to test spacing, typography, responsive layout and state styling without turning the experiment into a full project decision.
<article class="rounded-lg border border-gray-200 bg-white p-6 shadow-sm">
<h2 class="text-xl font-semibold text-gray-900">Project title</h2>
<p class="mt-3 text-base text-gray-600">A short description of the project.</p>
<a class="mt-5 inline-block font-medium text-blue-600" href="#">View project</a>
</article>The speed was obvious. I could adjust spacing and type without moving between files, and the design started to take shape quickly. The concern was also obvious. If every component grew like that, the markup could become difficult to scan.
Creating Boundaries
The way I made Tailwind more comfortable was by setting boundaries early. I avoided treating every utility class as a permanent decision. If a pattern repeated, I looked at whether it needed to become a component. If a set of classes appeared in several places, that was usually a sign that the design decision needed a name.
In a React or component-based environment, this felt more manageable because the repeated markup could live inside a component. In a traditional template, I had to be more careful because long class attributes spread across several files can become annoying to maintain.
Using The Configuration Properly
The other important part was the configuration. Tailwind works better when the design system is intentional. If the colours, spacing and type scale are left completely open, it becomes easy to create small inconsistencies everywhere. The tool gives you speed, but that speed needs constraints.
I found it useful to treat the config as the place where project-level decisions lived. The markup could then use those decisions instead of inventing slightly different values throughout the build.
What I Took From The Experiment
Retrospectively, Tailwind made the most sense when the project had reusable templates or components. It was less convincing when used as a scattered collection of utility classes across a traditional site with no clear component structure.
I did not come away thinking it should replace every way of writing CSS. I came away thinking it was useful when the project was organised enough to stop the markup becoming the only place design decisions existed. Used carefully, it made interface work faster. Used lazily, it could make the HTML harder to live with.