Lançado o Tailwind CSS v4.0

 (tailwindcss.com)
1 pontos por GN⁺ 2025-01-24 | 1 comentários | Compartilhar no WhatsApp
  • O Tailwind CSS v4.0 é uma versão em que o framework foi reescrito do zero, aumentando muito a performance de build e mudando o fluxo de configuração e customização para um modelo centrado em CSS
  • No benchmark com o Catalyst, o build completo ficou 3,78 vezes mais rápido, de 378ms no v3.4 para 100ms no v4.0, e o build incremental sem novo CSS melhorou 182 vezes, de 35ms para 192µs
  • A instalação foi simplificada para uma única linha @import "tailwindcss" com padrão sem configuração, e quem usa Vite pode usar @tailwindcss/vite no lugar de PostCSS
  • O v4.0 aproveita recursos modernos de CSS como cascade layers, @property, color-mix() e logical properties, além de introduzir detecção automática de conteúdo e tratamento embutido de @import
  • Container queries, transformações 3D, API de gradientes expandida, @starting-style, not-*, field-sizing, color-scheme, inert e outros entram como recursos centrais, reduzindo a dependência de plugins separados

Motor de alto desempenho reescrito do zero

  • O Tailwind CSS v4.0 é uma versão reescrita do zero com base em anos de experiência de arquitetura do framework
  • Nos benchmarks internos do projeto, o rebuild completo ficou mais de 3,5 vezes mais rápido, e os builds incrementais ficaram mais de 8 vezes mais rápidos
  • Os tempos medianos de build com base no Catalyst são os seguintes
    • Build completo: v3.4 378ms → v4.0 100ms, melhoria de 3,78 vezes
    • Rebuild incremental com novo CSS: 44ms → 5ms, melhoria de 8,8 vezes
    • Rebuild incremental sem novo CSS: 35ms → 192µs, melhoria de 182 vezes
  • Builds incrementais que não precisam compilar novo CSS ficaram mais de 100 vezes mais rápidos, concluindo em microssegundos
    • Quanto mais tempo se trabalha em um projeto, mais comum é reutilizar classes já usadas, como flex, col-span-2 e font-bold, então esse tipo de build aparece com frequência

Aproveitando a plataforma moderna de CSS

  • O v4.0 aproveita ativamente os recursos da plataforma web que evoluíram desde o Tailwind CSS v3.0
  • Os principais recursos de CSS usados como base são os seguintes
    • Native cascade layers: permitem controlar com mais precisão como diferentes regras de estilo interagem
    • Registered custom properties: tornam possíveis animações de gradiente e melhoram bastante a performance em páginas grandes
    • color-mix(): permite ajustar a opacidade de qualquer valor de cor, incluindo variáveis CSS e currentColor
    • Logical properties: simplificam o suporte a RTL e reduzem o tamanho do CSS gerado
  • Esses recursos também simplificam a implementação interna do Tailwind, reduzindo a superfície de bugs e facilitando a manutenção

Instalação e integração de build simplificadas

  • O fluxo de instalação foi reorganizado para reduzir etapas e boilerplate
    • npm i tailwindcss @tailwindcss/postcss
    • Adicionar @tailwindcss/postcss ao plugin do PostCSS
    • Usar @import "tailwindcss" no arquivo CSS
  • No v4.0, é possível importar e usar o Tailwind com uma linha de CSS em vez da diretiva @tailwind
  • Ele oferece um fluxo sem configuração para começar sem nenhuma configuração, inclusive sem definir caminhos de arquivos de template
  • Sem plugin externo separado, ele faz o bundling das regras @import e usa internamente o Lightning CSS para vendor prefixing e conversão de sintaxe moderna
  • Usuários de Vite podem escolher @tailwindcss/vite em vez de PostCSS
    • O Tailwind CSS v4.0 já é rápido como plugin de PostCSS, mas com o plugin do Vite é possível obter performance ainda melhor

Detecção automática de conteúdo e import embutido

  • A configuração do array content, necessária no v3, foi substituída pelas heurísticas de detecção automática do v4.0
  • Itens presentes no .gitignore são ignorados automaticamente, evitando escanear dependências ou arquivos gerados fora de controle de versão
    • Ex.: /node_modules, /coverage, /.next, /build
  • Extensões binárias como imagens, vídeos e .zip também são ignoradas automaticamente
  • Quando for preciso adicionar explicitamente fontes excluídas por padrão, é possível usar a diretiva @source dentro do arquivo CSS
    • @source "../node_modules/@my-company/ui-lib";
    • @source também usa as mesmas heurísticas, então tipos de arquivo binário continuam excluídos sem precisar indicar extensões separadamente
  • Antes do v4.0, para fazer inline de outros arquivos CSS com @import, era preciso um plugin separado como postcss-import, mas agora isso não é mais necessário graças ao suporte embutido a import
    • O sistema de import foi criado especificamente para o Tailwind CSS e é integrado de perto ao motor, funcionando com mais rapidez

Configuração CSS-first e variáveis de tema

  • Uma das grandes mudanças do v4.0 é permitir configurar o projeto diretamente em CSS, em vez de JavaScript
  • Em vez do arquivo tailwind.config.js, é possível customizar usando @theme no arquivo CSS que importa o Tailwind
    • Configuração de design tokens
    • Definição de utilitários personalizados
    • Definição de variants personalizadas
  • Os design tokens definidos em @theme são expostos como variáveis CSS por padrão
    • Ex.: --font-display, --breakpoint-3xl, --color-avocado-500, --ease-fluid
  • As variáveis CSS geradas assim podem ser referenciadas em CSS normal em tempo de execução
    • Reutilização em estilos inline
    • Envio para bibliotecas como Motion para tratar animações

Valores dinâmicos de utilitários e variants

  • O v4.0 simplifica vários utilitários e variants para aceitarem determinados valores arbitrários sem configuração
  • No grid, é possível usar o tamanho desejado sem configuração separada
    • Ex.: grid grid-cols-15
  • Também é possível mirar atributos data booleanos personalizados sem pré-defini-los
    • Ex.: data-current:opacity-100
  • Utilitários de espaçamento como px-*, mt-*, w-* e h-* passam a derivar dinamicamente de uma única variável de escala de spacing
    • Ex.: --spacing: 0.25rem
    • w-17 é gerado na forma calc(var(--spacing) * 17)
  • A ferramenta de upgrade lançada junto com o v4.0 detecta e simplifica automaticamente, na maioria dos casos, a sintaxe de valores arbitrários que não é mais necessária

Paleta de cores e container queries

  • Toda a paleta de cores padrão foi atualizada de rgb para oklch
    • Isso aproveita um gamut mais amplo além das limitações do espaço de cor sRGB, deixando as cores mais vivas
    • Como o equilíbrio entre as cores do v3 foi mantido, a atualização de projetos existentes não deve parecer uma breaking change
  • O suporte a container queries entrou no core no v4.0, eliminando a necessidade do plugin @tailwindcss/container-queries
  • O novo variant @max-* permite usar container queries com max-width
  • Assim como nos variants normais de breakpoint, é possível combinar @min-* e @max-* para definir intervalos de container query

Transformações 3D e expansão da API de gradientes

  • O v4.0 adiciona uma API para transformações 3D
    • rotate-x-*
    • rotate-y-*
    • scale-z-*
    • translate-z-*
  • Os recursos de gradiente também foram expandidos, permitindo criar efeitos mais variados sem CSS customizado
  • Gradientes lineares podem receber ângulo como valor
    • Ex.: bg-linear-45
    • O antigo bg-gradient-* foi renomeado para bg-linear-*
  • O modo de interpolação de cores do gradiente pode ser controlado por modifier
    • bg-linear-to-r/srgb
    • bg-linear-to-r/oklch
    • A interpolação padrão do v4.0 é OKLAB, e modifiers de outros espaços de cor também podem ser usados
  • Os novos utilitários bg-conic-* e bg-radial-* permitem criar gradientes cônicos e radiais
    • Funcionam junto com from-*, via-* e to-*
    • Incluem suporte a valores arbitrários para controle detalhado, como modo de interpolação de cores e posição do gradiente

Novos variants e utilitários

  • O novo variant starting oferece suporte ao CSS @starting-style
    • Permite criar transições de propriedades quando um elemento é exibido pela primeira vez
    • Dá para animar elementos que aparecem na página sem usar JavaScript
    • O suporte dos navegadores talvez ainda não seja suficiente para a maioria das equipes, mas está próximo disso
  • O novo variant not-* oferece suporte à pseudo-classe CSS :not()
    • Ex.: not-hover:opacity-75
    • Também é possível negar media queries e queries @supports
  • O v4.0 também adiciona os seguintes utilitários e variants
    • inset-shadow-*, inset-ring-*: permitem empilhar até 4 camadas de box shadow em um único elemento
    • field-sizing: oferece suporte a redimensionamento automático de textarea sem JavaScript
    • color-scheme: permite remover scrollbars claros no dark mode
    • font-stretch: ajusta variable fonts com suporte a larguras variadas
    • inert: estiliza elementos não interativos marcados com o atributo inert
    • nth-*: oferece suporte a estilos da família nth
    • in-*: funciona de forma parecida com group-* sem precisar da classe group
    • :popover-open: também mira popovers abertos com o variant open existente
    • descendant variant: estiliza todos os elementos descendentes

Início e caminho de upgrade

Leituras relacionadas

1 comentários

 
GN⁺ 2025-01-24
Opiniões no Hacker News

  • Em certo momento critiquei fortemente várias falhas do Tailwind e sua incompatibilidade com uma forma web moderna e realmente “pura”, mas o grande avanço da v4 é muito bem-vindo
    Poder acessar temas do Tailwind como variáveis CSS nativas, e a documentação trazer até um exemplo de componente de botão escrito com variáveis nativas em uma folha de estilos externa, é uma mudança enorme
    Também é excelente poder configurar apenas com CSS, e agora o Tailwind parece menos um framework “viral” ao estilo JavaScript, que engole uma arquitetura razoável, e mais um utilitário que pode ser adicionado a qualquer projeto
    Quer as críticas dos últimos anos tenham surtido efeito, quer eles mesmos tenham chegado a uma boa conclusão, boa parte do debate pró/contra Tailwind agora parece menos relevante, e isso é muito bom. Agora dá para focar em criar produtos

    • Na prática, ainda sou crítico em relação ao uso, mas é surpreendente como o Tailwind combina bem com fluxos de trabalho gerados por IA
      Como qualquer coisa pode ser expressa de forma sistemática, ele funciona muito bem, e há algo extremamente útil nisso
    • É difícil concordar que o debate pró/contra Tailwind não seja mais relevante e, como designer/engenheiro de design, vejo dois problemas
      Primeiro, engenheiros de JavaScript/Tailwind dominaram as discussões de design. Em vez de “utility-first”, “remoção de código não usado” e “CSS type-safe”, o foco deveria estar mais em sistemas de design, por exemplo em questões como usar Perfect Fifth ou Perfect Fourth na tipografia
      Segundo, o Tailwind dificulta a participação no processo real de criação. Decisões de design ficam enterradas dentro de expressões obscuras em componentes React, como flex items-center shadow-lg p-6 hover:bg-gray-50 dark:bg-gray-800 py-[calc(theme(spacing[2.5])-1px)]
      Isso pode ser compreensível para engenheiros JavaScript, mas vira uma barreira para design sistemático. Em vez de expressar relações matemáticas precisas em CSS, acaba-se usando um estilo inline mais conveniente
    • Só queria a paleta de cores do Tailwind CSS

  • CSS ficou muito mais fácil de usar do que antes, e a maioria dos navegadores agora também se comporta de forma consistente
    Vale a pena aprender, já que não exige etapa de build e não polui o markup com código excessivo
    Também é possível escrever diretamente o atributo style no HTML, algo que antes era evitado por separação de responsabilidades. Mas me pergunto por que querem reintroduzir uma abordagem parecida. Parece ser só para economizar alguns caracteres
    O atributo style até parece mais intuitivo, já que não exige converter código mentalmente. Não entendo bem o apelo

    • Há bastante coisa que não dá para fazer com o atributo style. Por exemplo, pseudoclasses :hover, :focus, pseudoelementos ::before, ::after, media queries, keyframes e animações
      A experiência de desenvolvimento também não é boa em projetos grandes
      Por outro lado, o @scope, que em breve deve virar padrão, é um bom acréscimo para posicionar estilos perto do lugar em que são usados: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope
    • Hoje em dia, o Tailwind é frequentemente usado junto com um sistema de abstração de componentes que funciona como uma camada de abstração em vez de classes CSS
      A abstração de componentes separa significado e estilo de forma mais forte. Em ambos os casos é preciso encontrar a abstração “hero”, mas no mundo dos componentes abstrai-se não só o estilo, como também o nome das tags HTML
      De um jeito ou de outro, os “detalhes de estilo” ficam separados do “conteúdo”, que é o arquivo-fonte da página. Dá para aceitar uma etapa de build em nome da separação de responsabilidades, ou seja, de uma melhor separação entre conteúdo e apresentação
    • O apelo está em não precisar criar nomes de classes CSS, em ficar lado a lado com o HTML e ser fácil de ler, e em a convenção de nomes ser padronizada, usando as mesmas regras em todos os lugares
      Também reduz a necessidade de manter arquivos separados e remover componentes não usados
      Dá para usar media queries que não eram possíveis com a tag style, e não há o risco de alterar uma classe usada em outro lugar. O escopo global do CSS tem vantagens, mas também é perigoso
    • Isso é resultado de aceitar como natural um acoplamento forte com React
      O estilo passa a ser visto como pertencente ao componente, não ao sistema de design. O ecossistema de engenharia JavaScript-first precisa de mais empresas orientadas por design que conheçam a força do CSS moderno e do design sistemático
    • Quando se olha a quantidade de arquivos que precisa ser gerenciada em projetos grandes, o Tailwind parece bem atraente
      A abordagem comum com .css gera nomes estranhos, duplicação e possibilidade de conflitos. css modules também é uma opção, mas na prática dobra o número de arquivos por componente/página
      sass ou less parecem misturar os problemas de css modules e do .css comum
      Não gosto nem desgosto do Tailwind por princípio e, no começo, eu o detestava, mas em um projeto com mais de 200 arquivos compostos por componentes e páginas, dá para perceber seu valor

  • Minha primeira reação ao Tailwind foi “que saco”. Eu já sabia CSS, e agora parecia que precisava reaprender CSS
    Parece parecido com um pai tentando ajudar o filho na lição de matemática, mas o método ensinado na escola mudou completamente em relação ao de antes; a solução dele ainda está certa, mas não é aceita, e a criança fica irritada tentando conciliar os dois sistemas
    Entendo a vibe de que, se funciona bem na equipe e escala bem, então é só usar, e já passei por isso
    Mesmo assim, ainda prefiro stylesheets comuns voltadas a classes ou tags. Ainda mais agora que CSS já dá suporte a seletores aninhados
    Existe o problema de gerenciar stylesheets, e gosto da abordagem de definir e aplicar arquivos CSS no nível da rota, como no Remix/React Router. Se isso não bastar, ou se estilos dinâmicos ficarem complexos demais em arquivos .css, style={{...}} também está sempre disponível
    CSS é poderoso, flexível e escalável, então Tailwind me parece mais uma limitação do que uma melhoria. Não sei bem por que continua tão popular, mas acho que daqui a 3 ou 4 anos todo mundo já terá migrado para outra coisa

    • No começo era frustrante, parecia reaprender CSS, e antes eu dizia a mesma coisa
      Mas, ao contribuir para um projeto open source que usava Tailwind, fui me acostumando, e hoje vejo de outro jeito
      Tailwind é, essencialmente, mais próximo de uma abreviação de style={{…}}. Coisas que exigiriam várias linhas em um arquivo .css ou em um objeto de estilos acabam em uma utility de uns 15 caracteres
      O tempo gasto pesquisando coisas como “visual text replacement css”, consultando cheatsheets de CSS ou vasculhando posts de 8 anos atrás do CSS-Tricks caiu bastante. Em vez disso, estou sempre olhando a documentação do Tailwind e encontro rapidamente a classe utilitária que faz o que quero
      Uma quantidade surpreendente disso fica no cache mental, e parece muito melhor do que tentar decorar todo o CSS necessário para fazer layout
    • Acho que é porque agora o componente inteiro fica em um único arquivo
      Não é preciso mexer em CSS separado, e os estilos ficam exatamente junto do elemento ao qual se aplicam, então não é preciso ficar comparando uma coisa com a outra
      Dá para fazer isso só com a propriedade css, mas há o problema de que todo mundo aprendeu que esse é o jeito errado, e uma lista de strings com várias utilities também é mais fácil do que usar objetos CSS puros
    • Limitações reduzem a complexidade possível, e é por isso que Tailwind vence
      É um wrapper modular, padronizado e componível sobre um sistema enorme e complexo, então é um grande avanço
    • Estou aprendendo matemática com meu filho e não é diferente do que aprendi; ainda consigo resolver rápido
      Por outro lado, nas redes sociais há posts que misturam multiplicação e divisão e dizem que só existe uma resposta certa. Tailwind não é tão ruim assim, mas, do ponto de vista de alguém mais velho, parece mais próximo dessa direção

  • Gosto de Tailwind. Usei em 3 projetos nos últimos 4 anos, e ele foi intuitivo, bem documentado e simples
    Não sinto saudade da época de emotion e styled-components, em que era preciso dar nome a cada div estilizada do projeto
    No Tailwind, um contêiner é só uma div com algumas classes. Há menos discussão sobre nomes, e menos esforço mental e tempo de review gastos com nomenclatura

    • Vejo com frequência essa questão de ter que pensar em um nome para cada styled div, e acho um pouco estranho
      Quase nunca passei mais de 1 segundo pensando em como nomear algo. Para algumas pessoas isso realmente é um ponto de bloqueio? Fico curioso se isso chega mesmo a paralisar alguém
    • Se você diz “algumas classes”, então parece que trabalha com um product owner excelente
      As pessoas com quem lidei costumavam especificar, sem parar, todos os detalhes possíveis. Tratavam um formulário web como se fosse a reforma pessoal delas no HGTV
      Na única vez em que experimentei Tailwind, as classes ficaram uma ordem de grandeza mais numerosas do que o markup, e rapidamente ficou difícil de ler
    • Usei em vários projetos, mas não gostei. Em projetos grandes, fica bagunçado rapidamente e parece o novo Bootstrap
      Hoje estou satisfeito com um fluxo de CSS-in-JS. É um jeito de escrever CSS à moda antiga com ajuda de LLM. Mostro uma imagem para o LLM e peço um componente, e ele já sai com nomes apropriados
    • Se eu puder escolher, esse é um dos principais motivos para evitar React
      Styling em React é ruim, e mesmo usando Tailwind ele é apenas a opção menos pior
      Se for usar um framework de front-end e uma etapa de build, Svelte e Astro são boas opções dependendo do caso. Dá para estilizar com CSS comum e, mantendo os componentes pequenos, quase não é preciso usar nomes de classes
      Basta usar seletores de elementos e deixar o framework escopar os estilos em tempo de build

  • Usei Tailwind no meu site e gostei bastante, mas talvez por um motivo um pouco diferente do que normalmente se menciona
    O valor real do Tailwind é que você consegue ler todos os estilos que afetam um elemento em um só lugar
    Os nomes das classes podem ficar longos, mas é muito mais rápido ler uma linha comprida do que abrir as ferramentas de desenvolvedor do navegador toda hora ou ficar subindo e descendo por um ou mais stylesheets
    Quando volto àquele código depois, consigo modificá-lo com confiança sem me preocupar em acabar alterando outro elemento
    A natureza em cascata do CSS ainda é útil, mas normalmente quero limitar o estilo a um único elemento. Para o resto, volto ao CSS, mas o CSS que de fato escrevo é muito pouco. Na maioria das vezes, só quero acertar espaçamentos

    • Acho que é exatamente por isso que Tailwind é bom e confortável
      Também gosto do fato de que “como faço X?” vira uma busca rápida na documentação, e não uma investigação de 30 minutos
    • Também há ferramentas que mostram todos os estilos aplicados a um elemento no IDE. Por exemplo, o “Show Applied Styles for Tag” do Intellij ou as ferramentas de desenvolvedor do Chrome mostram isso de forma legível
      Em comparação, os trechos de Tailwind neste post do HN parecem bem assustadores
    • Concordo até certo ponto, mas o mesmo problema continua existindo
      Se você adiciona text-xl a uma div e dentro dela há uma div e um span aninhados, todos herdam text-xl; então, para ver o que está causando o text-xl nos elementos aninhados, no fim você ainda precisa subir pela hierarquia de elementos
      Ainda assim, no geral, é um pouco mais fácil

  • As expressões “tempo de build reduzido”, “não há mais diretivas @tailwind”, “sem configuração em JavaScript” e “projetado para a web moderna” soam assim
    O CSS agora consegue fazer tudo aquilo que fazíamos manualmente, mas ainda vamos continuar fingindo que somos necessários

    • Se é para odiar, pelo menos deveria tentar entender o que é e por que as pessoas usam
    • O ponto de venda do Tailwind, desde o começo, foi “é quase CSS inline, mas menos trabalhoso que o atributo style e muito mais fácil de otimizar”
    • Fico curioso sobre o que, antigamente, não dava para fazer com CSS comum e exigia Tailwind
      Tailwind não corresponde quase 1:1 ao CSS?
    • Será que foi mesmo assim que você interpretou?
      Entendo não gostar de Tailwind, mas acho melhor dizer do que exatamente você não gosta nele em vez de atacar um espantalho
      Também não é legal desmerecer o projeto open source de outra pessoa e quem o usa de forma útil

  • Quero perguntar a quem entende bem de CSS. Eu não entendo muito
    Estou atualizando um projeto Phoenix pessoal para a versão 1.7 e, como o Phoenix agora usa Tailwind por padrão, tentei usá-lo no lugar do Bootstrap
    Até agora, a versão com Bootstrap parecia “razoavelmente ok”, mas a versão com Tailwind parece uma bagunça
    Qual é a forma mais fácil de obter padrões visuais decentes sem tentar virar designer? Ou devo simplesmente reinstalar o Bootstrap e encerrar o assunto?

    • Nesse caso, eu reinstalaria o Bootstrap
      O Tailwind te dá ferramentas quando você quer controlar o design, mas, no fim, você precisa controlar o design por conta própria
      Se você só quer algo bonito e não se importa que tenha cara de Bootstrap, então Bootstrap é a escolha certa
      Em teoria, há projetos que reimplementam o Bootstrap sobre o Tailwind e poderiam dar um ponto de partida parecido com Bootstrap junto com o poder do Tailwind, mas, na prática, nunca vi algo que funcionasse melhor do que simplesmente usar Bootstrap
    • Para esse objetivo, uso DaisyUI. O site de demonstração de exemplo está aqui: https://nwk-landing-kit.netlify.app
      A documentação do DaisyUI está aqui: https://daisyui.com
    • Se estiver procurando componentes no estilo Bootstrap, vale experimentar gratuitamente o https://flowbite.com/
      O Tailwind também tem componentes pagos, que você pode simplesmente copiar e colar. O bom é que, quando você se acostuma, consegue ir ajustando os componentes do Flowbite aos poucos
    • Depende de quem está pagando
      Se você tem estabilidade no emprego e quer ficar mexendo nas coisas, pode brincar com Tailwind. Pessoas antenadas em tendências e bem vocais geralmente parecem gostar de Tailwind
      Mas, se é um projeto seu, financiado por você, ou se há prazo, é melhor usar o Bootstrap que você já conhece e focar em terminar o trabalho, em vez de entrar numa guerra de atrito com a UI
    • Comparar Tailwind e Bootstrap é mais como comparar maçãs com torta de maçã
      O Tailwind fornece as classes que você empilha para criar componentes
      Deve ficar mais fácil se você usar também uma fonte de componentes de UI. Usei TailwindUI no passado, mas era pago; imagino que também existam boas alternativas gratuitas

  • Há um padrão claro nas conversas de “Tailwind ou não Tailwind”. Ele se repete toda vez que Tailwind é mencionado
    Há pessoas que nunca o usaram de verdade por mais de 30 minutos, só fizeram uma tentativa rápida ou deram uma olhada na documentação. Elas não gostam de Tailwind e preferem coisas como “CSS puro”
    Por outro lado, há pessoas que o usaram em projetos reais, dentro de equipes com mais de uma pessoa. Elas entendem o valor, aceitam os trade-offs e gostam
    Vi muita gente passar do primeiro grupo para o segundo, mas quase nunca vi alguém voltar do segundo para o primeiro
    É por isso que o Tailwind fez sucesso. Pode não parecer bonito aos olhos de puristas, mas, para quem cria coisas e para pragmáticos, ele é realmente excelente

    • Acho que eu não me encaixo bem em nenhum desses dois grupos
      Não sou contra Tailwind, mas o motivo de ainda não ter usado é que não vejo claramente por que ele seria uma abordagem melhor que outras opções, como Web Components ou React Styled Components
      O maior problema é que o Tailwind polui o HTML com inúmeras classes utilitárias, tornando-o difícil de ler e manter
      Entendo que isso é melhor que um enorme arquivo CSS global e o CSS clássico baseado em nomes de tags, mas já existem formas de usar CSS com escopo no componente sem contaminar o namespace global. Web Components e Styled Components são exemplos disso
      Ambos vinculam os estilos diretamente ao componente ou, de forma mais geral, a um conjunto específico de tags HTML, então fica fácil ver quais estilos se aplicam onde
      Também não é preciso usar nomes de classes globais, e há menos preocupação com efeitos colaterais indesejados ou conflitos. Ao remover um componente, os estilos relacionados também são removidos, então não há preocupação com CSS não utilizado sobrando. Graças ao shadow DOM, também não há risco de o estilo de um componente afetar outro componente por acidente
      Dou importância a manter o HTML curto e legível, sem misturar estilos de apresentação diretamente na marcação. Quando todos os estilos ficam no atributo class, como no Tailwind, surgem longas listas de classes em uma única linha; se ainda for preciso incluir nomes de classes reais junto disso, o HTML fica bagunçado
      Fica difícil entender de relance quais estilos estão sendo aplicados e também é difícil indentar direito. Isso me lembra vários dos motivos pelos quais saímos do atributo style inline no HTML no passado
      Não odeio Tailwind, mas, em termos de legibilidade, manutenibilidade e separação de responsabilidades, não vejo uma vantagem clara sobre Web Components ou Styled Components, e ainda tenho preocupações grandes sem resposta
      Li a documentação, mas não usei, e é difícil entender por que escolher Tailwind em vez de outras opções. A enorme quantidade de classes no meio de HTML comum torna ambos difíceis de ler para mim

  • Reconheço que há pessoas produtivas que usam Tailwind de forma útil, mas agora que Tailwind está em todo lugar, dá para ver por aí uma aparência limpa, mas comum

    • Isso é confundir Tailwind com TailwindUI/shadcn etc.
      Em geral, Tailwind não influencia mais o estilo do que CSS comum. Há algumas exceções. Coisas como sombras são um pouco mais padronizadas, e a paleta de cores indigo acabou influenciando o mundo externo recentemente
    • Tailwind oferece padrões razoáveis, mas não influencia muito o design
      As pessoas apenas tendem a criar sites de uma determinada maneira. Especialmente quando usam com ShadCn
    • Na verdade, isso me parece algo bom. As opções do Tailwind são bem projetadas e funcionam bem
      Vejo isso como o uso da fonte Inter em sites, como uma nova Helvetica. Se muita gente usa e fica bonito, por que não usar?
    • Antigamente eu também ouvia isso sobre o Bootstrap, mas os sites em Bootstrap que criei não se pareciam entre si
      Muito antes do Tailwind, o Bootstrap já oferecia muitas classes utilitárias, economizava bastante tempo e não impunha uma aparência específica
      Bastava importar apenas as classes que você queria. Claro, se você não tivesse baixado os arquivos-fonte Sass, a história seria outra, mas isso teria sido uma escolha tola
    • Minha visão sobre esse problema é que bons frameworks de UI, ou seja, combinações de Tailwind e componentes, ainda são raros
      Por isso, a maioria dos projetos usa um número muito pequeno de frameworks. Se surgirem mais 4 ou 5 projetos de UI de alta qualidade, especialmente com direções de estilo mais diferentes, a diversidade vai aumentar
      Como em muitos trabalhos criativos, parece que o design também tem seu rumo definido por um número surpreendentemente pequeno de pessoas
      Gostaria que mais gente soubesse disso. Acho que há pessoas talentosas que não criam por pensarem: “mesmo que eu faça, ninguém vai ouvir”
      Mas acredito que, se algumas dessas pessoas tentarem, poderão abrir novas possibilidades de UI para uma grande parte da web

  • Tailwind é uma prova das vantagens dos estilos inline, ou seja, a forma de estilizar algo sem dar nomes, da universalidade das strings e também dos limites das strings
    Estou ansioso pelo que virá depois e, até lá, vou usar Tailwind a contragosto