Tailwind Is Easy to Start, Easy to Abuse
Tailwind's superpower — styling directly in your markup — is also how teams get into trouble. Without discipline, you end up with the same forty-class string copy-pasted across thirty files, and changing the brand colour becomes a find-and-replace nightmare. The good news: a handful of habits keep a Tailwind codebase clean even at scale.
Theme First, Always
Before writing a single utility class, define your design system in the Tailwind config: colours, spacing scale, font sizes, border radii, and breakpoints. Then only ever use those tokens. The moment you write an arbitrary value like a raw hex colour inline, you have created an inconsistency that will multiply. A well-configured theme means changing your brand colour is a one-line edit.
Extract Components, Not Class Strings
The number one rule: if a cluster of classes appears more than twice, turn it into a component. A <Button> component that encapsulates its Tailwind classes is infinitely better than the same class string scattered everywhere. This keeps your markup readable and gives you one place to change a style. Reach for component extraction long before you reach for things like @apply.
Use @apply Sparingly
Tailwind lets you bundle utilities into a custom class with @apply. It is tempting but easy to overuse — lean on it too much and you have just reinvented traditional CSS while losing Tailwind's benefits. Reserve it for genuinely repeated, low-level patterns (a base input style, perhaps) and prefer real components for everything else.
Keeping Class Lists Readable
- Use a class-sorting plugin — the official Prettier plugin orders classes consistently so diffs stay clean and scanning is easier.
- Group logically — layout, then spacing, then typography, then colour, then state. Consistency beats any specific order.
- Use a merge helper for conditional classes — a small utility to combine and dedupe classes keeps conditional styling from turning into string spaghetti.
Performance Notes
Tailwind already strips unused classes at build time, so production CSS stays tiny — that part is handled for you. Your job is to avoid shipping huge inline class lists that bloat your HTML, which is another reason component extraction matters. Keep an eye on your rendered markup, not just your CSS bundle.
Dark Mode and Theming
Decide your theming strategy early. Tailwind's dark-mode support and CSS-variable-driven theming both work well, but retrofitting either onto a large codebase is painful. If there is any chance you will need theming, wire it in from the start using design tokens rather than hardcoded values.
How Dharmsy Builds with Tailwind
We start every Tailwind project with a strict token config, extract components early, and enforce class sorting so the codebase stays readable as it grows. If your Tailwind project has become a wall of duplicated class strings, we can help you refactor it into a clean component system.