0
obrenoalvim
1 min de leitura ·

Tailwind CSS: produtividade real ou bagunça de classe disfarçada?

Não tem meio-termo: as pessoas amam ou odeiam Tailwind. Depois de 2 anos usando em produção, tenho uma opinião mais matizada.

O que Tailwind resolve de verdade

Velocidade inicial. Você não sai do arquivo para criar CSS. Para quem tem memória visual do design system, é incrivelmente rápido.

Consistência de escala. Com tokens definidos (cores, espaçamento, tipografia), é difícil "inventar" um valor fora do sistema. Isso é subestimado em times.

Sem naming de classes. Inventar nome para .container-wrapper-inner é um problema real. Tailwind elimina isso.

O que Tailwind não resolve

Legibilidade. Um div com 15 classes utilitárias é objetivamente mais difícil de ler do que um componente com nome semântico. Isso não muda com o tempo.

Componentes repetidos. Sem abstrações (componentes React, @apply com cuidado), você vai copiar as mesmas 10 classes por todo o projeto.

Colaboração com designers. Traduzir um Figma para Tailwind ainda é manual. O gap entre design e código não diminuiu.

O que me convenceu a ficar

Componentes. Se você está usando React, Vue ou Svelte, as classes ficam encapsuladas no componente. O problema de legibilidade some quando você abre <Button> e não vê as 12 classes utilitárias.

Sem Tailwind + sem componentização = caos. Com Tailwind + componentização = produtividade real.

A pergunta honesta

Você usa Tailwind porque é genuinamente mais produtivo, ou porque todo projeto novo usa e ficou a escolha padrão?

Carregando publicação patrocinada...
5

Style components resolve? Resolve sim, inclusive na componentização.

Muita gente torceu o nariz para o Tailwind, ele é produtivo, não é mágico, no css mais básico é da mesma forma, mas dá pra criar algo que parece mais fácil, sim, parece que deixou tudo misturado, mas funciona bem.
Outro dia vi vaga pra React Native usando Style Components. Não demora muito e o Angular vai se render, ja dá pra usar.
Claro, o que vamos estar usando daqui a pouco?

1

A pergunta 'o que vamos usar logo' é a que mais me paralisa. Cada ciclo parece que recomeça: BEM, SMACSS, CSS Modules, CSS-in-JS, Tailwind, e já tem gente falando de CSS nativo com container queries e layers como se fosse a solução final.

Styled Components ainda aparece bastante, mas noto que novos projetos estão indo direto pra Tailwind ou CSS Modules. A componentização que Styled Components resolve bem o Tailwind também resolve, só que de forma diferente.

Você sente que tem alguma abordagem tomando conta mais rápido ultimamente?

1

Queria ter essa resposta, mas acaba que Tailwind virou algo pra se tornar padrão. Quem sabe algo aproveitando pontos dele. No final, acabamos seguindo o projeto que passam.
E debaixo do capô lá está o CSS Nativo. Seria bom poder contar com ele.

1

Esse ponto de 'seguir o que o projeto usa' é a realidade de quase todo dev. A escolha individual raramente importa mais do que a consistência do time. O CSS nativo hoje está chegando em um ponto que antes exigia lib: container queries, cascade layers, nesting nativo. Mas ainda falta o design system embutido que o Tailwind dá. Quando as custom properties CSS ficarem mais ergonômicas para isso, a conversa muda. Você sente que os projetos que passam por você estão todos em Tailwind ou ainda aparece bastante CSS Modules?

1
1

Modinha é um diagnóstico justo para boa parte da adoção. O problema é que modinha e utilidade real não se excluem: React virou modinha e também resolveu problemas reais. Tailwind entrou no mesmo caminho. A questão é quando alguém usa sem entender o que está ganhando ou perdendo, aí vira cargo cult de verdade. O argumento que me convence é a consistência de tokens: sem disciplina manual, você inevitavelmente inventa valores fora do sistema. Mas concordo que esse argumento deveria aparecer mais nas discussões do que o simples 'todo mundo está usando'. Você prefere CSS Modules ou vai direto no CSS puro quando não usa Tailwind?

3
1

CSS Modules também é minha preferência quando estou num contexto de componente mais isolado. Tailwind ganha quando o ritmo de entrega importa mais do que a elegância da estrutura. No dia a dia acabo combinando os dois: Tailwind para layout e utilitários, SCSS ou CSS Modules para lógica visual mais específica. CSS puro puro raramente aparece, só em scripts pequenos sem framework. Você usa CSS Modules junto com algum pré-processador ou direto no CSS nativo mesmo?

3

CSS puro é fácil, não entendo esse fetiche com abstração de classes. Tailwind é só mais uma documentação pra ler de algo que já existia, que é o CSS inline. O bootstrap ainda tem uma justificativa que é de fato um "boostrap", realmente aumenta a produtividade, mas p código não fica bom e a UI não é tão personalizada, logo é ótimo para amadores.

1

O paralelo com CSS inline é o que os críticos mais usam, e tem fundamento. A diferença prática é que Tailwind adiciona um design system por baixo: você não escreve margin: 14px arbitrário, escreve m-3.5 que respeita os tokens configurados. O resultado é consistência quase automática sem precisar de disciplina extra para seguir guia de estilos. Mas o argumento de que é só documentação extra é válido para quem já tem disciplina com CSS puro e trabalha com design system próprio. Bootstrap como boostrap faz sentido, mas os dois têm propósito diferente do Tailwind. Você usa algum sistema de tokens no CSS puro, ou vai no feeling mesmo?

3

So virou padraoy, mas ele comeca a focar difícil e bagunçado em projetos maiores com designs mais complexos. CSS puro nunca foi problema, p tailwind so abstrai classes de design, mas em algo mais objetivo e avançado vc termina empilhando classes qd poderia fazer uma só personalizada e resolver

1

Concordo que escala é onde o problema aparece. Em componentes complexos a lista de classes cresce rápido e fica difícil de ler. O que funcionou pra mim foi componentizar agressivamente: as classes ficam no componente, não espalhadas pelo template. Com isso você troca uma lista enorme por um nome semântico, que é exatamente o que o Tailwind puro não te dá. Em designs muito customizados você de fato acaba lutando contra o sistema em vez de trabalhar com ele, e aí CSS puro ou CSS Modules faz mais sentido. Qual tipo de projeto foi onde você sentiu mais esse problema: sistema interno ou produto com design muito específico?

3

Já trabalhei em projeto com Tailwind, hoje não trabalho mais. Peguei bastante a mesma classe duplicada/repetida no mesmo item. Funciona, é fácil de mexer, mas achava estranho e desorganizado aquele tanto de classe no mesmo lugar.

Trabalho em projeto (grande e legado) com Bootstrap usando tema personalizado. Tem consistência, tem personalidade. Não parece só um mais projeto Bootstrap.
O que o Bootstrap não resolve, resolvemos com o bom e velho CSS.

Não sei os demais casos, para o nosso caso resolve bem. Não temos dificuldade de manutenção por causa disso.

1

Classes duplicadas sem abstração é o maior problema do Tailwind na prática. O framework não te força a extrair nada. No Bootstrap você acaba criando uma classe .card-header naturalmente. No Tailwind você arrastra as mesmas 8 classes em cada lugar e nunca para para pensar que virou um componente.

O caso Bootstrap + CSS customizado funciona bem quando o tema está bem construído. A questão que me veio: quando alguém novo entra no projeto, consegue estender o tema sem quebrar consistência, ou sempre precisa chamar quem conhece a base do CSS personalizado?

0

Só usei ele em projetos pessoais, então não lidei com o problema de escala.

Considero-o um "css inline" gourmet (sem conotação negativa). Dito isso, eu gosto dele.

1

CSS inline gourmet é uma das melhores definições que já vi. Captura exatamente o que Tailwind é: inline com sistema por baixo. Em projetos pessoais a escala não aparece e você fica só com os benefícios de velocidade. O problema real começa quando você tem um designer com opiniões fortes ou um design system que diverge dos defaults do Tailwind. Aí o gourmet vira briga. Nos projetos pessoais que você usou, chegou a usar algum plugin para customizar os tokens, ou ficou só com o padrão?

1

Fiquei no padrão (com formulários), mas cheguei a usar o de aspect ratio uma vez.

E, como alguém da época das tabelas, confesso que acabo sempre tendo meus arquivos scss para quando fica muito chato escrever dentro do framework.

Mas voltando para o artigo, concordo demais com a máxima que a componentização resolve esse problema. Até porque componentização resolve quase qualquer problema, né haha

1

O escape para SCSS quando fica chato é honesto e provavelmente é o comportamento certo. Forçar tudo dentro do Tailwind vira custo maior do que o benefício. A combinação dos dois faz sentido: Tailwind para o sistema base, SCSS para os casos que fogem. Quem vem de tabelas tem uma perspectiva boa sobre o que CSS resolve de verdade versus o que é abstração em cima de abstração. Componentização resolve a maioria dos problemas sim, mas só se você componentiza na hora certa. Você tem algum critério pra decidir quando um trecho de Tailwind virou complexo o suficiente para extrair?