Categorias

Por que usar Tailwind CSS

Talvez alguns de vocês não lembrem, mas quando o CSS foi introduzido no desenvolvimento de páginas web, ele causou uma ruptura de paradigma, finalmente permitindo separar estrutura de apresentação. A cada nova versão do recurso, o CSS foi ganhando mais funcionalidades, incluindo animações e até variáveis.

Tailwind CSS é um framework desenvolvido para maximizar o potencial do bom e velho CSS e levá-lo ainda mais longe. De forma bastante simplificada e intuitiva, ele oferece responsividade, código enxuto, customização e integração com IDEs. Da mesma forma que frameworks de JavaScript mudaram nossa forma de interagir com o JavaScript, Tailwind pode ser o futuro do CSS.

Shawn Swyx Wang é um desenvolvedor / PM / investidor anjo, principalmente ativo na comunidade de desenvolvimento da web como blogueiro e palestrante frequente, evangelista do movimento Learn in Public. Em um artigo publicado na internet, ele explica que Tailwind CSS é mais fácil de aprender do que parece e desmistifica alguns preconceitos contra o framework.

Com sua autorização, traduzimos e reproduzimos o artigo na íntegra:

“Não sou um devoto do Tailwind. Eu sou um Guo Lai Ren – alguém que mudou de ideia recentemente e sou um usuário feliz, apesar dos sacrifícios reconhecidao. “Pessoas que mudaram de lado” muitas vezes podem ser mais persuasivas para os céticos do que os crentes nascidos e criados naquilo. Portanto, espero contribuir com minha perspectiva para a discussão, se você estiver aberto a isso.

Um tempo atrás, Adam Wathan perguntou: “Você achava que o Tailwind era uma ideia horrível até que realmente construiu algo com ele?”

Eu respondi:

Certa vez, reclamei com @samselikoff que o Tailwind causou uma sopa de nomes de classe ilegível e disse que o CSS-in-JS de tempo de execução zero poderia fazer mais com uma curva de aprendizado menor.

Eu estava errado em 2 pontos: o Tailwind é mais fácil de aprender do que eu pensava e a flexibilidade do CSSinJS pode ser negativa.

Depois de lançar alguns projetos (incluindo meu site pessoal e site de livros) com o Tailwind agora, acho que provavelmente devo escrever minhas ideias sobre o que gosto nele. Como o Tailwind é o framework CSS Utilitário predominante e o único que experimentei, não farei nenhum esforço para distinguir os pontos abaixo dos benefícios gerais do CSS Utilitário (mas aqui está uma lista de outros).

TL;DR

  • Os valores do “sistema” reduzem os números mágicos: diminui os valores marcados com hard code, aumenta a consistência.
  • Design responsivo no navegador: protótipo no navegador, copie e cole no código-base, usando valores de sistema consistentes.
  • Estilos embutidos otimizam para mudanças: torne o código fácil de excluir e mover, eliminando toda a dependência da cascata.
  • Colocar os estilos inline reduz a nomenclatura: entregue mais rápido resolvendo um dos problemas mais difíceis conhecidos da ciência da computação!
  • Zero JS e Escala Sublinear de CSS: escala em O (log N), não em O (N).
  • Utilitário em primeiro lugar, mas não exclusivamente Utilitário: respeite o princípio de menor poder, use CSS-in-JS somente quando garantido.

Também abordo objeções populares ao Tailwind no final, com links para seus argumentos, para que você possa decidir por si mesmo.

O Cânone do Utilitário em primeiro lugar

Antes de me ouvir, você pode querer verificar as peças mais influentes na revolução das “classes utilitárias” no CSS agora:

Sou fortemente influenciado por essas pessoas e outras, então se eu repetir alguns pontos mal abaixo, a culpa é minha. Pelo menos eu lhe dei as fontes canônicas primeiro.

Os valores do “sistema” reduzem os números mágicos

CSS é extremamente flexível, o que o torna poderoso, mas também oferece muitas chances do tiro sair pela culatra. Restrições são necessárias, ou então espalharemos “números mágicos” por toda a nossa base de código.

Números mágicos em CSS são uma coisa ruim, diz Chris Coyier. Ele os define como “valores que” funcionam “em algumas circunstâncias, mas são frágeis e propensos a quebrar quando essas circunstâncias mudam”, mas honestamente qualquer número fixo em hard code, como pixles nas margens e media-queries ou variantes de cor, é difícil de gerenciar bem em escala. A tentação de quebrar as regras apenas para enviar uma correção existe, e a dificuldade de refatoração quando os requisitos de design mudam é muito alta. Se você está trabalhando sozinho, não há nada que o obrigue a se limitar a um conjunto consistente de escalas numéricas bem projetadas, o que pode levar a um projeto de aparência ruim.

A solução, claro, é extrair apenas de um intervalo predefinido de valores numéricos, que chamo de “sistema” (observe que não chamo isso de “Sistema de Design”, um debate no qual não tenho interesse em entrar) . O Tailwind vem com um bom conjunto de fontes e sistemas de cores por padrão. Mais uma vez, você poderia tentar lançar seu próprio sistema com variáveis ​​CSS, mas a sintaxe para isso é prolixa e você ainda tem que criar nomes para classes e variáveis, e você acaba com um sistema personalizado que não se transfere entre projetos e provavelmente não está bem documentado. É melhor adotar um bom sistema padrão importando Steve Schoger para sua equipe.

Existem alternativas: Styled-System e Theme UI do jxnblk-verse são a base para isso na terra do CSS-in-JS.

Design Responsivo no navegador

Este ponto é mais relevante para desenvolvedores que fazem o design: o melhor fluxo de trabalho de desenvolvimento é visualizar seu site no host local, fazer ajustes no navegador até que você esteja satisfeito com isso e, em seguida, copiar e colar suas alterações diretamente em seu código. Vamos chamar isso de fluxo de trabalho Design in Browser.

Se quiser esse fluxo de trabalho, você exclui o uso do estilo embutido do React (que faz com que você use a sintaxe de objeto). Mas digamos que você use alguma forma de solução “Write Real CSS” ™, como Styled-Components ou Vue ou Svelte, onde o design no navegador é possível. O que mais o Tailwind oferece a você?

  1. Você pode obter diretamente dos valores predefinidos do “sistema” (elaborados acima) durante a prototipagem no navegador.
  2. Você também pode fazer um design responsivo e de pseudo-classe enquanto está no navegador – por exemplo, para aplicar estilos em diferentes pontos de interrupção, ou ao passar o mouse ou foco, você pode apenas prefixar inline, por exemplo, para um link, text-green-400 hover: text-green-300 md: text-blue-400.

Eu fiz uma demonstração disso em um vídeo recente:

Design in Browser não é exatamente o estilo de Bret-Victor Inventing on Principle, mas você está chegando pelo menos mais perto de ser capaz de “brincar” no contexto, reduzindo a distância cognitiva mais uma vez. Com o Tailwind, você pode até adicionar transições e animações inline enquanto brinca. Isso é extremamente subestimado – nós, desenvolvedores, poderíamos oferecer mais movimento em nossos aplicativos se fosse mais fácil criar um protótipo e adicioná-los.

Estilos embutidos otimizam para mudanças

Observação IMPORTANTE: as classes utilitárias NÃO são iguais aos estilos embutidos – estou usando esse conceito como uma abreviação, mas a realidade é mais sutil e MUITO a favor das classes utilitárioa.

Grande parte do CSS de produção é apenas anexado. Isso ocorre porque a distância cognitiva entre o CSS e a marcação que ele afeta costuma ser grande – às vezes em uma pasta diferente, em um arquivo diferente ou no mesmo arquivo, mas a dezenas de linhas de distância. Além disso, você tem que se lembrar da cascata CSS e executar cada elemento contra cada regra correspondente, em sua cabeça.

Em breve, você terá uma base de código que tem medo de abrir! A velocidade do desenvolvedor diminui e, eventualmente, você se encurrala em um canto onde nada menos do que uma reescrita completa será suficiente.

Por design, CSS é fácil de estender. Basta adicionar especificidade! Mas não é fácil deletar. Isso adiciona complexidade, no melhor sentido “Rich Hickey” da palavra  (porque a posição é importante no CSS, agora você precisa se lembrar de todas as posições). É fácil construir o castelo de cartas, mas tire uma coisa e todo o edifício pode desmoronar, e você NÃO SABERÁ até verificar se há regressões visuais ou emular o navegador em sua cabeça.

Você pode usar ferramentas (módulos CSS, CSS estático em JS, Vue ou estilos de escopo Svelte) ou convenções de nomenclatura (BEM, etc) para controlar a especificidade, mas isso reduz a distância cognitiva em vez de eliminá-la. A única opção com zero “ação assustadora à distância” é o estilo embutido. O estilo embutido otimiza para mudanças.

Momento “Cérebro Galático”: o Tailwind oferece aos desenvolvedores benefícios de velocidade de estilos embutidos sem suas desvantagens.

Existem alternativas: Outras soluções como o css prop da Emotion e styled-jsx oferecem benefícios semelhantes de estilos inline, mas encontram o CSS padrão nas desvantagens de JS.

Colocar os estilos inline reduz a nomenclatura

Nomear Coisas é um problema difícil conhecido. Perdemos muito tempo discutindo sobre nomes de classes. Com Styled-Components, você geralmente escreve um monte de componentes com estilo intermediário que você precisa nomear. Com o BEM, substituímos um problema de nomenclatura por três problemas de nomenclatura e meio (fiquei preso em reuniões de projeto s sobre se deveria ter usado – ou __ – que perda de tempo total). Quantos milhões em horas de desenvolvedor desperdiçamos todos os anos discutindo sobre nomes?

Com o CSS utilitário, reduzimos significativamente o número total de nomes em nossa base de código e, talvez mais importante, o número de nomes que temos que inventar e lembrar de forma independente. Isso parece pequeno até que você trabalhe em uma base de código onde isso não foi usado. Que preço você está disposto a pagar para eliminar um dos problemas mais difíceis conhecidos? Não estou brincando – vale a pena ter essa conversa. Os nomes não importam para as máquinas, mas importam para os humanos.

A desvantagem é que você precisa aprender os nomes da estrutura do CSS utilitário. -mb-5 e space-x-reverse não são identificáveis ​​sem documentação. A diferença é que a nomenclatura CSS tradicional é feita sob medida por projeto, enquanto você aprende o Tailwind uma vez e pode usá-los em todos os projetos. Sim, você pode tentar lançar seus próprios utilitários, mas a nomenclatura do Tailwind é provavelmente projetada de forma mais cuidadosa do que qualquer coisa que você venha a criar.

Existem alternativas: Emotion’s css prop e styled-jsx também permitem que você ignore a nomenclatura.

Zero JS e Escala Sublinear de CSS

Muita tinta foi derramada sobre as compensações de desempenho do uso de CSS em JS e seus fatores atenuantes. Você pode verificar minha palestra What’s New in React para mais informações, mas tenha certeza de que é um debate acalorado com pessoas apaixonadas e inteligentes de ambos os lados. Mas todos concordamos que quanto menos JS você enviar, melhor, e também concordamos que, byte a byte, enviar 1kb de JS tem um impacto de desempenho muito maior do que 1kb de CSS. Esses são bem compreendidos.

O ponto que estou interessado em explorar aqui é que muitas soluções de CSS e CSS em JS são escalonadas linearmente com o número de componentes em seu aplicativo. Como o CSS define o escopo de cada declaração para o seu identificador, você deve repeti-lo em todos os lugares em que deseja aplicá-lo. É assim que acabamos com mais de 50 declarações de font-weight: bold em um escritório em que trabalhei. Individualmente, isso não importa, mas em massa, eles se somam.

Em nosso site antigo, carregávamos mais de 400 KB de CSS compactado (2 MB descompactado) … Não começamos com tanto CSS; apenas crescia com o tempo e raramente diminuía. Isso aconteceu em parte porque todo novo recurso significa adicionar novo CSS.  – Engenheiro do Facebook

Você pode adiar esse problema com a divisão de código, mas, eventualmente, as pessoas enviam e implementam soluções alternativas até o ponto em que o CSS fica fora de controle novamente (especialmente se for somente acréscimo!).

A solução aqui é (indiscutivelmente!) publicar CSS “atômico”, de modo que seu CSS seja dimensionado em O (log N) em vez de O (N) (onde N é o seu número de componentes). A biblioteca stylex não lançada do Facebook permite que você escreva CSS em JS e gere CSS atômico para você, mas você também pode escolher escrever CSS atômico à mão, que é o que frameworks utilitários como o Tailwind o orientam a fazer.

Para ser justo, coloco esse ponto no final, porque é improvável que a maioria dos aplicativos chegue à escala em que isso realmente começa a importar, especialmente quando se leva o gzip em consideração. No entanto, como acontece com todas as otimizações, essas coisas são prematuras até que não sejam.

Utilitário em primeiro lugar, mas não exclusivamente Utilitário

Além de todos os benefícios acima, você AINDA pode usar aquelas outras soluções para os benefícios de que precisa. Por exemplo, nada é realmente tão poderoso quanto CSS em JS, onde você pode alterar dinamicamente os valores de media-query e conjuntos de regras inteiros com base em JavaScript arbitrário.

No entanto, os casos de uso da vida real em que você realmente precisa fazer isso são limitados e os custos (em peso JS, por exemplo) dominam quando você apenas o usa para estilização estática. Adotando em primeiro lugar o aspecto utilitário, respeita-se aqui o Principle of Least Power.

Soluções que não envolvam CSS em JS geralmente também são mais fáceis de depurar. “Fácil” aqui é obviamente subjetivo. Mas quando as coisas dão errado com soluções CSS em JS, muitas vezes me encontro chegando a um ponto em que tenho que procurar documentação, chamados no GitHub e mergulhar em node_modules, o que é um monte de aporrinhação, se distanciando do que eu realmente quero estar fazendo. Quando algo dá errado com o Tailwind, sei que estou gerando o nome de classe que esperava ou não. Existem muito menos pontos de variação. Mas é lógico que você deva usar a solução mais fácil de depurar na maioria das vezes, se puder.

As partes ruins

O Tailwind é perfeito? Não, claro que não. Mas o lado bom supera o lado mau:

  • Configurar o Tailwind significa mexer nas ferramentas de construção. Isso está ficando mais fácil e é comparável às ferramentas necessárias para desempenho semelhante a outras soluções, mas é inaceitável para alguns.
  • A área de superfície da API Tailwind é grande e está em constante crescimento. É compreensível (tem que mapear todo o CSS!), Mas também pode ser cansativo de aprender e acompanhar. O resultado final é que você paga algum custo inicial de aprendizado para um ganho de produtividade promissor a longo prazo. Legal, mas não é uma vitória pura.
  • Os nomes das classes ficam bastante prolixos. Seria bom ter atalhos como md: hover: (text-green-300 underline border-5), mas isso seria apenas adicionar a área de superfície da API. Isso agora é implementado no twind – a interpretação CSS em JS do Tailwind!) Talvez o uso de @apply seja garantido, ou apenas alguma tipografia inteligente. Mas, no geral, acho que a facilidade de editar as coisas em linha substitui as preocupações estéticas superficiais. Os usuários certamente não se importam.
  • Vazamento de abstração de CSS – o Tailwind permite que você use classes como estilos embutidos, mas eles NÃO são estilos embutidos em um aspecto crítico – o que acontece quando eles entram em conflito. Por exemplo, com ‘m-4 m-2’, o “m-4” tem precedência. A ordem das classes geradas pelo Tailwind é importante, embora seja invisível para você. Este é um vazamento de abstração. Se você está tentando construir componentes reutilizáveis ​​para um sistema de design interno, isso vai contra essa ideia. Você pode querer explorar a IU do Chakra.
  • A governança do projeto é de propriedade do Tailwind Labs – eles são, obviamente, os criadores do projeto e grandes administradores por enquanto, mas não é um processo igualitário com conduta estabelecida como o CSSWG. Como em todos os relacionamentos BDFL, tudo bem até o dia em que você discordar deles.
  • (menor) A extensão do VS Code ainda não é tão robusta quanto poderia – exigindo um espaço para iniciar e, muitas vezes, simplesmente não funciona. Mas Brad Cornes está trabalhando nisso!

Conclusão: A Solução de Estilo “Cachinhos Dourados”

Acima de tudo, acho que escolher o Tailwind é uma questão de preferência pessoal, em vez de ser a resposta certa e objetiva. Existe um amplo espectro de soluções de estilo desde super opinativo a não. É assim que eu coloquei recentemente:

  • Bibliotecas de componentes pré-fabricadas são muito restritivas, o CSS básico é muito permissivo.
  • CSS em JS é muito pesado, CSS inline é muito fraco.
  • Queremos as restrições do sistema de design, mas a maneira como exploramos os sistemas de design tem sido muito pesada (ligada à estrutura).
  • Ben Holmes: “um intermediário sólido para designers que desejam liberdade e desenvolvedores que desejam estrutura”.
  • Tailwind é para aqueles que desejam uma solução de estilo que seja “não muito quente, mas não muito fria”.

A solução “cachinhos dourados”.

Apêndice: Perspectivas Opostas

Lidando com objeções

  • Mas o HTML é muito feio: a estética do código deve ficar em segundo plano em relação à velocidade de desenvolvimento e à capacidade de fornecer UX melhor.
  • Mas existem variáveis CSS!: sim, mas você não obtém o fluxo de trabalho ininterrupto de estilos embutidos. margin-bottom: var (- spacing-8) não é equivalente a class = “mb-8”.
  • Mas os componentes da web existem!: claro que você pode usar os dois juntos, mas quanto do seu aplicativo é composto de componentes da web, realmente? O Tailwind é uma ótima opção de base para aqueles que estão trabalhando em aplicativos que não são, em sua maioria, WCs.
  • Eu não gosto de @apply: bom, você não deve usá-lo muito de qualquer maneira. Mas baixar o nível de @apply para seu CSS constituinte é uma tarefa trivial.”

Publicado originalmente como “Why Tailwind CSS” em 3 de outubro de 2020. Traduzido e republicado com autorização do autor.