A developer pushes back against the industry's aggressive pivot to Tailwind CSS, arguing the migration costs outweigh the benefits. After reluctantly trying it on several Next.js projects, they question what problem utility classes actually solve. The author frames this as a deliberate choice for personal projects, not stubborn resistance, while acknowledging they'll use Tailwind if a team requires it.

The core frustration centers on rewriting existing knowledge into new syntax. Developers already mastered flexbox, grid, and the cascade; Tailwind simply repackages these concepts with verbose utility strings. Migration overhead is brutal—refactoring working components takes weeks. The author contrasts semantic class names like "btn-primary" with monolithic utility chains, noting that verbose markup makes HTML harder to read and maintain long-term.

Beyond syntax, Tailwind complicates routine changes. Swapping brand colors requires hunting through every component for specific values, rather than updating a single CSS variable. While config files can map semantic names, critics argue this recreates CSS custom properties with added complexity. The debate ultimately questions whether the community is chasing trends over substance, prioritizing workflow shifts over fundamental web standards.

The author concludes that classic CSS remains perfectly viable for shipping features and maintaining fast sites. Users don't care about tooling choices—they care about functionality. The piece urges developers to weigh tradeoffs honestly: Tailwind offers productivity for some, while traditional stylesheets preserve clarity for others. Pick based on project needs, not popularity, and ignore the pressure to refactor working code.