Não recomendo o Tailwind CSS

Artigo original ↗ Discussão no Hacker News ↗

O Tailwind CSS polariza desenvolvedores de frontend: alguns veem suas classes utilitárias como uma forma elegante de domar folhas de estilo grandes e bagunçadas, além de tornar componentes autocontidos e fáceis de reutilizar em times grandes. Críticos argumentam que ele infla o markup, obscurece a semântica, enfraquece a separação entre estrutura e design e, no fim, apenas re-abstracta CSS enquanto ainda exige entender a linguagem subjacente. Muitos concluem que a escolha “certa” depende muito do contexto — tamanho do projeto, habilidades da equipe e ferramentas —, com alternativas como CSS moderno puro, CSS Modules, BEM ou bibliotecas de UI muitas vezes preferidas para manutenção de longo prazo.

Tom Geral

  • A discussão é altamente polarizada e repetitiva de debates antigos sobre Tailwind; muitos chamam isso de bikeshedding.
  • Vários apontam a popularidade contínua do Tailwind como prova de que ele resolve problemas reais; outros veem sua disseminação como sinal de liderança fraca em frontend ou “slop”.

Benefícios Percebidos do Tailwind

  • Acelera a implementação, especialmente para devs que não querem projetar uma arquitetura de CSS ou um esquema de nomes.
  • Classes utilitárias tornam componentes/páginas autocontidos; mudanças têm menos chance de causar regressões em cascata em outros lugares.
  • Um sistema de design consistente pode ser centralizado na configuração do Tailwind (cores, espaçamento, bordas arredondadas, modo escuro etc.) e depois reutilizado via utilitários.
  • Funciona bem em times grandes e codebases grandes, evitando convenções BEM divergentes e CSS “espaguete”.
  • É fácil copiar e colar elementos entre projetos e fazê-los parecer idênticos.
  • Autocomplete, ferramentas de IDE e assistência de IA tornam os nomes de classes fáceis de lembrar e aplicar.

Principais Críticas

  • O markup fica barulhento e difícil de ler; os atributos class codificam uma mini-linguagem em vez de usar classes semânticas.
  • Quebra ou confunde a separação entre “estrutura vs estilo”; parece voltar aos estilos inline.
  • Exige aprender o vocabulário do Tailwind além de CSS; devs experientes em CSS relatam que isso os deixa mais lentos.
  • Problemas de cascata/prioridade (por exemplo, utilitários conflitantes) enfraquecem o “raciocínio local”, levando a complementos como tailwind-merge.
  • O uso de @apply é controverso: alguns o veem como necessário para manter a sanidade, outros dizem que ele frustra o propósito do Tailwind.
  • Incentiva valores ad hoc e pontuais (p-[13px], escalas de cor misturadas), então a consistência ainda depende da disciplina do desenvolvedor.

CSS, Componentes e Alternativas

  • Vários argumentam que o próprio CSS (e o modelo do HTML) é o problema de raiz; Tailwind é uma entre várias formas pragmáticas de lidar com isso.
  • Outros preferem CSS moderno com variáveis, nesting, estilos escopados, CSS Modules ou BEM, muitas vezes combinado com frameworks de componentes.
  • Alguns dividem responsabilidades: CSS ou sistemas de design para tokens e semântica; utilitários no estilo Tailwind apenas para layout/tipografia.
  • Alguns observam que, com LLMs/agentes gerando CSS, a principal vantagem do Tailwind (autoria manual rápida) pode importar menos com o tempo.

Contexto e Visão de “Ferramenta Certa”

  • Muitos concluem que a adequação depende do contexto: bom para times grandes, protótipos e UIs pesadas em utilitários; menos convincente para codebases pequenas, bem desenhadas e com CSS escopado por componente.