Tailwind CSS: vale a pena ou é só moda?

Tailwind divide opiniões como poucas ferramentas. Tem quem não larga mais e tem quem acha uma heresia encher o HTML de classe. Depois dos posts sobre Flexbox e sobre transições em CSS, vale falar dele sem torcida, olhando o problema que ele resolve e o que cobra em troca.

O problema que o CSS tradicional tem

No CSS tradicional, cada elemento ganha uma classe com nome, e o estilo mora em outro arquivo:

<button class="botao-primario">Salvar</button>

.botao-primario {
  background: #7c3aed;
  color: white;
  padding: 0.5rem 1rem;
  border-radius: 0.5rem;
}

Em projeto pequeno, funciona bem. À medida que cresce, aparecem três dores:

Nomear coisas é difícil. .botao-primario, .botao-principal, .btn-main: ninguém lembra qual já existe.
CSS só cresce. Tem medo de apagar uma regra porque ninguém sabe se alguma página ainda usa. Ela fica lá pra sempre.
Efeito cascata. Mudar uma classe pode quebrar uma tela que você nem lembrava que a usava.

A ideia do Tailwind

O Tailwind inverte a lógica. Em vez de criar classes com nome e escrever o estilo separado, você compõe o visual com classes utilitárias pequenas, cada uma fazendo uma coisa só, direto no HTML:

<button class="bg-violet-600 text-white px-4 py-2 rounded-lg hover:bg-violet-700">
  Salvar
</button>

Cada classe é uma declaração CSS: px-4 é padding horizontal, rounded-lg é borda arredondada, hover:bg-violet-700 aplica a cor só no hover. O Tailwind gera no build apenas o CSS das classes que você realmente usou, então o arquivo final fica pequeno.

O que ele resolve de verdade

Sem nomear classes. O estilo está no próprio elemento.
Apagar é seguro. Ao remover um componente, o estilo dele vai junto. Não sobra CSS órfão.
Sem efeito cascata. Mudar as classes de um elemento afeta só ele.
Design consistente. Os valores vêm de uma escala (espaçamentos, cores, tamanhos), o que evita aquele padding: 13px perdido no meio do projeto.

O preço que ele cobra

A crítica mais justa é a legibilidade. Um elemento mais elaborado vira uma linha longa de classes:

<div class="flex items-center justify-between gap-4 rounded-xl border border-zinc-200 bg-white p-6 shadow-sm dark:border-zinc-800 dark:bg-zinc-900">

Isso incomoda quem está começando e polui o HTML. A resposta do Tailwind é que você não repete isso: extrai o trecho num componente (um Card em React, por exemplo) e reaproveita. Ou seja, o Tailwind funciona melhor em projetos baseados em componentes. Em HTML puro com a mesma estrutura repetida em dez lugares, a repetição machuca de verdade.

Há também a curva de aprendizado: no começo você consulta a documentação a cada classe, até decorar o vocabulário. E ele não substitui o conhecimento de CSS. Quem não entende Flexbox ou o box model só vai escrever flex e p-4 sem saber por que o layout quebrou.

Quando faz sentido

Projeto com componentes reutilizáveis (React, Vue, Svelte) e um time que quer consistência visual.
Protótipo ou produto que muda muito, onde velocidade de iteração importa.
Quando você sofre com CSS acumulado e ninguém tem coragem de mexer nele.

Quando eu ficaria no CSS tradicional

Site pequeno e estático, com poucas páginas.
HTML sem componentização, com a mesma estrutura repetida.
Time que já tem um sistema de CSS organizado e funcionando bem.

Fechando

Tailwind não é moda nem solução universal. Ele troca o problema de manter CSS separado e nomeado pelo problema de ter HTML mais carregado de classe. Em projeto com componentes, a troca costuma compensar. Em outros contextos, pode ser peso sem retorno. A decisão certa vem de olhar a dor real do projeto, não do que está em alta.