Tailwind CSS, é uma boa solução?

[vicainelli]

Fala galera.

Recentemente, foi lançado um framework (+1) para agilizar o desenvolvimento de interfaces.

https://tailwindcss.com/

Ele é todo baseado em classes, eu achei a ideia ótima, mas não sei se o html viraria uma bagunça com tantas classes para apenas um elemento.

O que vocês acham? Já usaram?

[kvnol]

Eu, sinceramente, não gosto. O HTML fica uma bagunça, prefiro muito mais utilizar 1 classe e aplicar os mesmo estilos com @extend.

[felipeuntill]

Eca, só de ver o HTML dos exemplos me deu arrepio! Jamais utilizaria...

[ninetails]

Pessoalmente também concordo com as respostas acima. Eu também não gosto de frameworks css pois gosto de ter controle e semântica nos elementos e a disposição dos mesmos (html mais semântico).

Porém não acho que seja algo para ser ignorado, pois ajuda em casos de desenvolvimento rápido (estilo quando a gente usava Bootstrap, ou quando se precisa de um projeto pra ontem sem se importar tanto com semântica no código). Outro ganho diria sobre minificação de css e exclusão de código não utilizado na hora do build. Vi esses dias citando este framework neste artigo, falando tanto dele quanto do PurgeCSS.

[vicainelli]

Concordo com você @ninetails.

Não é nada semântico, mas quando comecei a ver como funciona, na hora pensei nos projetos pra ontem e também pra protótipos, ajudaria muito.
Eu estava procurando algo assim para limpar as classes em desuso.

[bernardodiasc]

Tantas são as abordagens possíveis em CSS. No que se refere a composição de classes, a abordagem alternativa desse framework é esperta:

<!-- Using utilities: -->
<button class="bg-blue hover:bg-blue-dark text-white font-bold py-2 px-4 rounded">
  Button
</button>

<!-- Extracting component classes: -->
<button class="btn btn-blue">
  Button
</button>

<style>
  .btn {
    @apply .font-bold .py-2 .px-4 .rounded;
  }
  .btn-blue {
    @apply .bg-blue .text-white;
  }
  .btn-blue:hover {
    @apply .bg-blue-dark;
  }
</style>

Ao invés de compor as classes no HTML, dá pra compor no CSS. Assim como é feito com @extend do Sass ou composes do CSS Modules. Não olhei o framework todo, mas essa possibilidade em particular é muito interessante.

Pude ver várias outras coisas maneiras nesse framework, muito interessante. E sendo PostCSS, mais interessante ainda. Mas tem o fato de requerer bastante conhecimento exclusivo do framework pra poder tirar proveito, digo, CSS padrão não vai ser o suficiente, tem que estudar o framework todo pra poder fazer algo bem feito com ele... Embora isso seja também com a maioria dos frameworks de qualquer linguagem, eu acho.

[bernardodiasc]

E o detalhe que torna esse FW CSS mais legal que outros é que é um framework de utilidades, não de componentes. Então esse lance de semântica não afeta em nada, o markup é livre, vc compõe os estilos como quiser usando seu HTML personalizado.

[kvnol]

"porém não acho que seja algo para ser ignorado, pois ajuda em casos de desenvolvimento rápido" @ninetails

Ah, sim. Concordo também, landing pages de políticos que vão sair do ar em 1 semana são boas para isso. A galera que trampa em agência* consegue fazer um bom proveito.

* eu trampo em agência, mas tô conseguindo colocar na cabeça do pessoal que projetos escaláveis e duradouros são bem melhores, etc.

[vicainelli]

Justamente @kvnol, de cara eu pensei nas landing pages que ficam no ar por semanas (ou até dias), principalmente em épocas sazionais como essas do final de ano.

Mas além disso, eu gosto da ideia de FW de utilidades como o @bernardodiasc citou.
Já utilizava o funcssion que me ajudava muito, acho que da mais liberdade que um FW de componentes, igual o Bootstrap ou Bulma.

[wmartins]

Particularmente eu gosto bastante desse approach. Temos utilizado a mesma ideia do Tachyons em um projeto aqui, porém, com algumas classes específicas para os nossos guias de estilo (cores, fontes, espaçamentos e etc).

Depois de um tempo, a questão do "HTML feio" já sai da conta, devido a produtividade e alta padronização que esse tipo de framework te proporciona. Como essas classes foram "acordadas" entre o time de design e de desenvolvimento, alguém que pega um layout pra fazer, não precisa perder tempo "medindo" os espaçamentos ou pegando a cor de algum elemento, ou então o tamanho de fonte. Isso tudo já está padronizado.

Além disso, usamos React com o pacote classnames, o que deixa bem "elegante" a composição dessas classes.

Sobre a questão da semântica com classes e etc, eu acho que o Nicolas Gallagher matou a pau nesse artigo aqui: http://nicolasgallagher.com/about-html-semantics-front-end-architecture/.

When you choose to author HTML and CSS in a way that seeks to reduce the amount of time you spend writing and editing CSS, it involves accepting that you must instead spend more time changing HTML classes on elements if you want to change their styles. This turns out to be fairly practical, both for front-end and back-end developers – anyone can rearrange pre-built “lego blocks”; it turns out that no one can perform CSS-alchemy.

[felipefialho]

Nada mais nada menos do que CSS inline.

Abordagens assim, funcionam bem com componentes ou CSS in JS, mas tenho pavor quando utilizam CSS puro. Só minha opinião.

@kvnol Evite extends, tente utilizar mixins

[mvtenorio]

Quando vi a primeira vez achei o HTML poluído demais, mas pesquisei sobre esse conceito de utility-first, experimentei o framework em um projeto pessoal e tenho gostado bastante.

Um artigo muito bom sobre esse approach é o Cooking with Design Systems . Recomendo muito a leitura.

@felipefialho O autor inclusive comenta sobre a comparação com CSS inline. Um dos benefícios que ele menciona é a consistência visual. Seu design nunca vai ter uma inconsistência como padding de 16 px em um lugar e 17 px em outro já que você vai usar as classes pré-definidas.

[tarciozemel]

Classes foram feitas para serem usadas. O número delas em elementos não tem nada a ver com "bagunça" do HTML, semântica etc. São coisas completamente diferentes.

Mas eu continuo preferindo nomes de classes dentro da convenção BEM.

PS: Essa dica do @kvnol é muito boa. Quem ainda não conhece, fica a sugestão de um minicurso grátis: https://www.udemy.com/sass-placeholders-o-jeito-certo/

[josercarmo]

A "bagunça" que tanto falam, não é do Tailwind css, isso se chama inline css e está ai desde que css nasceu lol, o que você vê é uma das formas de se trabalhar com ele, dada sua inteligente abordagem. Tailwind não é um Bootstrap, vc cria um Bootstrap com ele se quiser, ele define uma nova abordagem, utility-first, que pra mim é muito mais mnemônica e simples. E como foi dito acima ainda existe o @apply.

[vtmx]

Bagunçado porém o código final fica muito menor. Quantas vezes utilizamos o mesmo padding, color dentre outros seletores? O tempo perdido utilizando a mesma escrita sempre pode ser sanado com essa nova abordagem. Pode ser uma solução bem acessível para uma prototipação rápida e efetiva.

Quem já programou em Flutter ou está pensando em estudar, vai se lembrar do Tailwind.

Eu pessoalmente acho mais interessante criar uma biblioteca própria, eu gosto de criar classes semelhantes aos snippeds do Code, por exemplo:

.mt16 { margin-top: 16px; }

Podemos adaptar o melhor dos dois mundos e não encher de classes malucas o código final, do mesmo modo que isso pode ser verboso escrever class="btn btn-primary btn-large" também é super chato no final.

[DanubioLima]

Pessoalmente eu não gostei do framework. Deixa o código HTML muito bagunçado e mal organizado.
Cada elemento fica com muitas classes e isso dificulta a leitura de quem vai fazer manutenção no projeto.

Claro que em aplicações que precisam ser entregues com urgência o Tailwind pode vir a ajudar, mas o mesmo resultado rápido poderia ser alcançado com frameworks mais simples de se utilizar.

Outro ponto dele que observei foi que a documentação (ao menos no dia em que tô escrevendo esse comentário) não tem muito conteúdo para o desenvolvedor explorar.

Também acho que a integração dele com frameworks Javascript como React ou Vue também é um ponto negativo do projeto. Eu particularmente tentei usá-lo com React e Next.js e não gostei muito do resultado.

Enfim, são meus pontos pessoais sobre o Tailwind. Minha conclusão é que há coisas melhores no mercado para se utilizar.

[kvnol]

O @diogomoretti levantou uma discussão polêmica hoje sobre o Tailwind: https://twitter.com/diogomoretti_/status/1270408468202127366

[DanubioLima]

O @diogomoretti levantou uma discussão polêmica hoje sobre o Tailwind: https://twitter.com/diogomoretti_/status/1270408468202127366

@kvnol Eu vi aqui a discussão rs. Concordo com o que ele disse, principalmente nos comentários: existem mais pontos contra do que à favor no uso do Tailwind. Acho que não vale a pena utilizar ele, tem soluções muito melhores.

[leandrocorso]

Particularmente eu não gosto, parece que voltei aos anos 90 colocando estilo inline. Embora não seja obrigatório escrever de forma inline como o @bernardodiasc descreveu acima. Eu vejo algumas vantagens no que diz respeito a padronização de espaçamentos, tamanhos, cores e você não fica preso aos componentes de um framework como o Bootstrap ou o Material UI, por exemplo. E isso pode ser bom ou ruim, pq se vc não tem os componentes definidos vc é quem precisa defini-los na sua aplicação e isso pode ser bem trabalhoso. A minha maior barreira neste tipo de abordagem de estilo geralmente é o time de design que as vezes quer pôr uma cor que não existe na paleta da biblioteca ou um espaçamento que não está previamente configurado. Embora dê pra personalizar tem que tomar cuidado pra não quebrar um estilo pra arrumar outro ou ficar criando mais exceções do que regras, pq isso vai "quebrar as suas pernas". Só que isso é um cuidado que devemos ter independente da abordagem de aplicação de estilos. Então se o tailwindcss é uma boa solução ou não, a resposta é o bom e velho "depende".

[PedroVicenteDinizCarvalho]

Tópico antigo, mas deixo meu relato aqui pois estou indignado. Esta semana realizei um teste para uma empresa, que pedia essa tecnologia. A documentação é complicada, para entender o básico das opções de grid já é difícil. Você olha os exemplos, tenta implementa-los identicamente como a documentação manda e as coisas não funcionam ????? kkkkk é uma piada. Fora o (require js). Se existe um comando NPM que é pra instalar a biblioteca, pq eles já não adicionam um javascript para funcionar 100% dos componentes? Ai quando você utiliza algo que precisa de javascript eles pedem para rodar um novo comando, que pode ser para instalar a opção com React, Vue ou outra biblioteca JS, você roda o comando, tenta implementar o component novamente e nada. Realmente muito ruim, não indico para ninguém. Um Bootstrap clássico e bem implementado continua sendo a melhor solução para montar um layout e organizar os grids.

[vtmx]

Em um projeto envolva muitos desenvolvedores e que seja de longo prazo talvez até seja bom devido a padronização de nomes etc.
Mas para algo pequeno ou que rodará por pouco tempo não vejo necessidade.

No fim eu acho mais sustentável talvez mesclar, usando só algumas partes criadas pela própria equipe, o grande problema de ter um framework desse tamanho são as atualizações que sempre quebram algo.

Eu gosto muito do IUKit, ele não é tão falado quanto os demais, mas gosto muito da forma como ele foi projetado. Muitas raras vezes precisei fugir muito do que tinha ali para protótipos e aplicações pequenas. Também gosto de como o estilo e os módulos JS podem ser adicionados. Dê uma olhada.

https://getuikit.com/docs/introduction

[PedroVicenteDinizCarvalho]

É, ainda não utilizei ele em equipe, então não consigo opinar sobre isso.
Mas sobre a padronização de nomes seria bacana se fossem resumidos. As vezes para um simples botão é preciso utilizar mais de 4 classes diferentes, para posicionar elementos dentro do grid então, são varias divs e muitas classes.
Mas deixo claro que é uma tecnologia que não estou familiarizado ainda, então qualquer um que leia isto, fique sabendo que não tenho conhecimento suficiente pra dizer se é uma boa escolha ou não.
Obrigado, vou dar uma olhada nesse documento :)

[reinaldonunes]

Usar trezentas classes para criar um objeto inline? Nem fudendo, html fica todo cagado, manutenção posterior se torna uma b****, fora que não segue nem um pouco a metodologia BEM
PORÉM, compor uma classe / componente, e atribuir todas as classes diretamente no css com o @apply ? Não pensaria duas vezes hehe

"Dai ao html o que é do html, e ao css o que é do css".. rsrsrs