Tailwind CSS: adiciona complexidade; não faz nada

Se você trabalha com front-end, provavelmente já ouviu falar muito sobre Tailwind CSS, uma biblioteca CSS muito parecida com o Bootstrap. Mas, diferentemente de Bootstrap, Tailwind tem uma abordagem diferente: baseia-se inteiramente classes de utilitários (utility classes).

Para os que ainda não sabem o que é uma classe de utilitário (utility class), aqui vai uma explicaçãozinha rápida.

Digamos que você tenha muitos componentes, e muitos deles precisam ter display: flex. Em vez de escrever isso várias vezes em seu CSS, você cria uma classe chamada “flex”:

Então, para cada componente que precisa ser flex, você adiciona essa classe flex.

Perceba que isso não é uma coisa ruim, em si. É até bem comum usar classes de utilitários, seja usando CSS puro ou, mesmo, com pré-processadores tipo Sass.

O que o Tailwind faz é levar esse conceito ao extremo, com a ideia de que você quase nunca precisa escrever CSS; apenas escrever classes diferentes com base nos estilos que precisa aplicar.

Estilo inline com passos extras

É isso. Escrever <div class="flex">foo</div> tem o mesmo exato efeito de escrever <div style="display: flex">foo</div> — só é ligeiramente diferente porque os estilos inline têm Especificidade maior que classes, mas isso não é realmente relevante neste contexto.

Então, com isso em mente, com exceção da priorização de CSS, qualquer argumento que possa surgir contra o uso de estilos inline na sua base de código também é um argumento contra o uso do Tailwind — como esse, esse e esse, só para citar alguns.

Pode parecer um pouco batido repetir críticas de outros sobre estilos inline para explicar o que há de errado com o Tailwind CSS, mas, na verdade, é um mapeamento 1-para-1: é apenas estilo inline com passos extras.

Problemas que Tailwind compartilha com estilos inline

E, como é disso que se trata, evidentemente, Tailwind vai sofrer dos mesmos problemas de quando se usa estilos inline.

Repetição (not DRY)

Quando é preciso alterar estilos de um projeto de uma forma mais abrangente, se classes de utilitários desse tipo estão sendo usadas, é preciso passar por cada uso delas e determinar visualmente o que precisa ser atualizado.

Por exemplo, digamos que a cor primária usada seja azul. Haverá muitas coisas azuis no site, marcadas como: “text-blue-500” ou “bg-blue-300” para determinar diferentes tons de azul. E tudo bem, até que o cliente decida alterar a marca e todos os botões (mas apenas os botões) no site precisem ser vermelhos.

Agora, você tem que passar por cada componente e alterar manualmente “text-blue-500” para “text-red-500”. E com 1000 edições vêm 1000 oportunidades para introduzir bugs.

Com CSS normal, o que provavelmente teria sido feito é criar uma classe chamada “button” e, nessa troca, simplesmente alterar 1 linha de código nessa classe: background-color: red. Qualquer elemento que usa essa definição de classe agora ficará vermelho.

O que leva ao próximo problema que Tailwind compartilha com estilos inline.

HTML deve se preocupar apenas com a estrutura da página, não com seu estilo

Fala-se em seperation of concerns no desenvolvimento Web, que é a premissa de que as 3 principais tecnologias do front-end devem estar divididas em “camadas”, cada uma sendo o mais independente da outra.

CSS Modules (especialmente, arquivos .vue) fizeram muito para dissipar a noção de que é preciso separar o conteúdo (ou estrutura), a apresentação e o comportamento do mesmo bloco de construção básico do site: cada parte do seu código deve ser “fracamente acoplada e altamente coesa” (loosely coupled and highly cohesive).

Em outras palavras, HTML não deve conter informações sobre quais devem ser os estilos; deve conter apenas informações sobre a estrutura/conteúdo da página.

De fato, a principal razão para a invenção de CSS, o objetivo de todo o empreendimento do CSS foi… Separar o conteúdo da apresentação.

E o método para fazer isso é por meio do atributo class.

O ponto principal de class é informar o que é um elemento, ou seja, descrever o conteúdo de um elemento — não da mesma maneira que semântica HTML, mas você entendeu. Depois de definir o conteúdo, decide-se como é sua aparência.

Isso não significa apenas que é possível alterar a aparência de um elemento sem se preocupar com a estrutura subjacente da página, mas, também, significa que se pode usar essas classes para se descrever o que é um elemento.

Lembre-se de que, quando um código é escrito, destina-se a 2 públicos: o primeiro é o próprio computador, que não se importa com a aparência do código, desde que seja executado, e, o outro, são os colegas desenvolvedores. Quanto mais fácil for para eles identificarem rapidamente quais são as partes do código e como se relacionam, mais rapidamente poderão corrigir bugs, adicionar recursos e aprimoramentos etc.

O que leva ao próximo problema de Tailwind.

É difícil de ler

Se você olhar para algum HTML que usa Tailwind, pode dizer a si mesmo que o HTML parece “ocupado” ou mesmo “feio”. Isso é verdade, mas não somente isso.

Diga o que quiser sobre estilos inline, mas eles, pelo menos, fornecem contexto suficiente para que você saiba o que está acontecendo. O código do Tailwind está cheio de abreviações semanticamente obscuras; a maioria dos quais são apenas redefinições de propriedades CSS já conhecidas.

Pior ainda, quando não são redefinições, podem se tornar totalmente enigmáticas. O Tailwind prefere usar nomes de classe prefixados em vez de media queries.

Por exemplo:

É o equivalente a:

Evidentemente, o primeiro exemplo tem muito menos código e é mais rápido para escrever, mas veja como o segundo exemplo está definindo explicitamente a altura e a largura em breakpoints específicos.

Outra razão pela qual o último é mais fácil de ler do que o anterior: as classes do Tailwind são organizadas horizontalmente, enquanto o CSS é escrito verticalmente.

Quanto mais amplo for o texto, mais difícil será para os olhos do leitor pular para a próxima linha e mais difícil será encontrar a palavra específica que você está procurando em uma parede de texto horizontal.

Perda de muitos dos recursos nativos de CSS

Tailwind não permite que você use o poder de muitos dos recursos nativos/básicos de CSS.

Não é possível encadear seletores, como:

<update>Atualmente, é possível lidar com estados no Tailwind.</update>

Não é possível usar combinação de seletores CSS, como:

Tailwind resolve um problema que não existe

Uma das coisas mais malucas é que há uma limitação óbvia para o paradigma de classe de utilitários do Tailwind. O que acontece se você quiser agrupar estilos relacionados?

Por exemplo, raramente display: flex é usado sem alguma propriedade de distribuição de conteúdos, como justify-content. CSS permite agrupar esses estilos em… Classes.

Também existe uma ferramenta para agrupar classes relacionadas ao Tailwind, chamada @apply. É uma sintaxe especial não-padrão que vai em seu arquivo CSS (uma diretiva) e permite combinar uma coleção de classes do tailwind sob um nome de classe específico.

Ou seja: destrói completamente o propósito por trás do paradigma da classe de utilidade… 🤡

Se você acaba tendo que usar @apply, então por que não usa CSS normal, comum e convencional, que é mais fácil de ler, entender, modificar e não requer ferramentas especiais?!

A sintaxe de CSS pode ser relativamente complexa, mas tem estado bastante estável desde o final dos anos 90 e não vai mudar radicalmente tão cedo.

Imagine o seguinte…

Há um exercício de imaginação muito simples que você pode fazer.

Imagine um mundo em que CSS nunca foi desenvolvido, mas algo semelhante ao Tailwind foi. Ou seja, as páginas web só podem ser estilizadas repetindo esses nomes de classes individuais, presumivelmente, por meio do uso de tags de tabela para layout.

Se você pudesse ir das limitações do Tailwind para o CSS, não consideraria isso um verdadeiro salto quântico?

• Sintaxe expressiva;
• Nomenclatura semântica;
• Agrupamento de estilos;
• Seletores e combinadores;
• E muito, muito mais!

Seria como passar de Assembly para C pela primeira vez.

Então, por que diabos estamos considerando substituir o CSS por algo que faz menos, é mais complexo, cria bases de código de má qualidade e possivelmente termina com um enorme bloqueio-de-vendor no futuro?!

Já existem boas soluções para turbinar o CSS

Portanto, grande parte do hype em torno do Tailwind é que você pode se livrar do CSS. OK, todos sabemos que pode ser difícil trabalhar com CSS — especialmente se você tiver bases de código legadas em que o CSS não foi escrito muito bem.

Mas, na maior parte, há outras melhorias melhores no CSS que realmente tornam o estilo mais simples, como pré-processadores (Sass, Less, Stylus), linters como o Stylelint, métodos e práticas recomendadas como BEM, SMACSS e muitos outros e até várias soluções CSS-in-JS que permitem que você aproveite o poder do JavaScript para criar definições de classe dinâmicas.

Pode haver sobrecarga no aprendizado dessas tecnologias? Sim. Há ferramentas que precisam fazer parte da sua build chain? Sim. Mas, ao contrário do Tailwind, todas essas soluções fornecem ativamente um benefício tangível para o seu código — algo que Tailwind não pode reivindicar.

Conclusão

Quem acompanha nosso Instagram e Twitter sabe, há muito tempo, que o assim chamado “vento-no-rabo” não é nossa solução preferida…

Depois de muito tempo liberando aperitivos a respeito, eis um artigo completo para deixar claro, de uma vez por todas, porque Tailwind adiciona complexidade e não faz nada e como ele resolve um problema que não existe.

Colocamos o artigo no blog para evidenciar a abordagem equivocada de Tailwind e, apesar do hype (completamente injustificado), ajudar nas análises pró/contra comuns em muitos projetos Web.