Why I Still Don't Use Tailwind in 2025

Even as it evolves, my reasons for avoiding utility-first CSS remain.

Tailwind has matured, its ecosystem is strong and many good teams use it successfully. I still prefer styles that express intent outside the markup, which is less a declaration of war and more an acknowledgement that different trade-offs suit different teams.

The useful question behind “Why I Still Don't Use Tailwind in 2025” is what changes in the work afterwards. A sound idea should improve a real decision, not only give us a neat phrase for describing it.

The answer is rarely a universal rule. It is a way of looking at the decision clearly enough to choose on purpose.

Prefer the thing that survives contact

Front-end work has a habit of looking simple from a distance. The browser then introduces real content, small screens, old devices, keyboard navigation and somebody using the product in a way nobody drew in the design file.

That is why I favour choices that are easy to inspect. Start with semantic HTML, let CSS do the layout work it was designed for, and add JavaScript where it creates genuine value. Cleverness is occasionally useful; legibility is useful every day.

The best front-end code does not show off. It makes the interface feel obvious.

A practical way to start

Before changing anything, I try to answer three ordinary questions:

• What is the smallest useful step?
• Where will feedback arrive first?
• Which trade-off are we accepting deliberately?

None of those questions produces an automatic answer. They do make the trade-offs visible, which is usually the point where a team can stop arguing from instinct and start making a decision together.

The web is wonderfully forgiving, but users should not have to rely on that forgiveness. Build from sturdy foundations and the interesting parts become much easier to enjoy.

That is not a dramatic conclusion, but useful work is often built from undramatic conclusions applied consistently.