The Tailwind CSS Debate: 3 Years Later - Two Eleven Jay LLC

## What I Got Wrong Initially **I focused on aesthetics over productivity.** Yes, `class=”bg-blue-500 text-white px-4 py-2 rounded”` looks messier than `class=”button”`. But writing that semantic CSS class and maintaining it across a project is significantly more work. **I underestimated the consistency benefits.** With Tailwind, `text-lg` is always the same size. `space-y-4` always adds consistent spacing. Custom CSS leads to dozens of slightly different font sizes and spacing values across a project. … ## What Still Annoys Me Three years of use hasn’t eliminated all the pain points: **HTML verbosity:** Complex layouts still result in very long class lists that can be hard to scan. **Responsive design complexity:** `md:flex lg:block xl:grid` type combinations can get unwieldy quickly. **Learning curve:** New team members need time to memorize utility classes and understand the naming conventions. **Purging gotchas:** Dynamic class generation can break when CSS purging removes classes that are constructed at runtime. **Debugging challenges:** When something looks wrong, you need to scan through many utility classes to find the culprit. … ## When Not to Use Tailwind Tailwind isn’t universally applicable: **Existing projects with established CSS architecture:** Migration costs might outweigh benefits. **Teams resistant to change:** Tailwind requires buy-in from the entire team to be effective. **Highly custom designs:** Some designs require CSS techniques that don’t map well to utility classes. **Simple projects:** For basic brochure sites, vanilla CSS might be simpler than learning Tailwind.