1 min de leitura ·

Você utiliza Tailwind nos seus projetos? Se sim, gosta?

Olá, pessoal!
Me chamo Lucas e sou dev Frontend Junior, na empresa que trabalho temos 5 projetos e somente o mais novo deles utiliza o Tailwind. Meu primeiro contato com o Tailwind foi aqui (no trabalho) e não curto muito a maneira que ele é feito, me lembra muito inline styles e nunca gostei disso.

Atualmente estou trabalhando em um projeto pessoal e estou no dilema de utilizar ou não o Tailwind, portanto gostaria da opinião de vocês sobre o que vocês utilizam e o que acham de cada ferramenta.

Por se tratar de um projeto pessoal para "testar ferramentas" o meu objetivo é usar coisas que são realmente utilizadas por outras empresas, então mesmo que eu não goste do Tailwind eu ainda o usuaria em caso de ser um "padrão".

Eu particularmente gosto muito do Styled Components, acho legal porque se aproxima muito do CSS e com ele posso deixar completamente separado o HTML do style.

Pilati

2 meses atrás

Se sim, gosta?

Sinceramente, na minha opinião, não há nada pior que tailwind.

Me lembra os tempos antigos do PHP que o pessoal executava SQL na view.

O mundo da programação demorou décadas para separar cada coisa em seu lugar e a lib se propõe a juntar tudo.

Com tailwind não dá pra entender de forma rápida a estrutura, as propriedades de um componente e o estilo. Algo que foi facilmente resolvido em outras libs usando simplesmente uma classe

lizzyman04

2 meses atrás

Olá,

A analogia com SQL na view é forte. Mas no front-end moderno, a "separação de preocupações" virou separação de arquivos, não de responsabilidades.

O Tailwind troca a semântica das classes pela transparência visual: você vê exatamente o estilo sem sair do componente. E resolve dores reais em escala: CSS que não cresce indefinidamente, zero context switching e consistência forçada por design tokens.

Sem Tailwind: Você lê
e precisa mapear o que .user-profile faz. Pode estar em um arquivo, pode estar em 5 arquivos, pode ter @apply ou media queries aninhadas. Você ganha "entendimento rápido" da semântica, mas perde a transparência visual.
Com Tailwind: Você lê
. Você sabe exatamente como essa div se parece sem sair do arquivo. Você perde a semântica (user-profile), mas ganha transparência visual.

Não é necessariamente uma evolução, é troca de trade-offs. Pra quem preza arquitetura clássica, incomoda. Pra quem preza produtividade e manutenibilidade em times grandes, faz sentido.

E tá tudo bem odiar. Mas não é à toa que virou padrão.

Pilati

2 meses atrás

Você está me dizendo que isso aqui tem transparência visual, é fácil de ler e é fácil de dar manutenção?

<form class="w-full max-w-xs space-y-3">
    <input type="email" placeholder="Email" class="h-11 w-full rounded-lg border border-border bg-secondary px-4 text-sm text-foreground placeholder:text-muted-foreground focus:outline-none focus:ring-1 focus:ring-primary" value="">
    <input type="password" placeholder="Password" class="h-11 w-full rounded-lg border border-border bg-secondary px-4 text-sm text-foreground placeholder:text-muted-foreground focus:outline-none focus:ring-1 focus:ring-primary" value="">
    <button type="submit" class="flex h-11 w-full items-center justify-center rounded-lg bg-primary text-sm font-normal text-primary-foreground transition-colors hover:bg-primary/90 active:scale-[0.98] disabled:opacity-60">Continue</button>
</form>

e que inclusive esse código é melhor que um componente como o abaixo?

<template>
  <form class="form">
    <input
      type="email"
      placeholder="Email"
      class="input"
      v-model="email"
    />

    <input
      type="password"
      placeholder="Password"
      class="input"
      v-model="password"
    />

    <button type="submit" class="button">
      Continue
    </button>
  </form>
</template>

<script setup>
import { ref } from 'vue'

const email = ref('')
const password = ref('')
</script>

<style scoped>
.form {
  display: flex;
  flex-direction: column;
  gap: 12px;
}

.input {
  height: 44px;
  width: 100%;
  border-radius: 10px;
  border: 1px solid var(--border);
  background: var(--secondary);
  padding: 0 16px;
  font-size: 14px;
  color: var(--foreground);
  outline: none;
  transition: box-shadow 0.2s;
}

.input::placeholder {
  color: var(--muted-foreground);
}

.input:focus {
  box-shadow: 0 0 0 1px var(--primary);
}

.button {
  display: flex;
  height: 44px;
  width: 100%;
  align-items: center;
  justify-content: center;
  border-radius: 10px;
  background: var(--primary);
  font-size: 14px;
  font-weight: 400;
  color: var(--primary-foreground);
  border: none;
  cursor: pointer;
  transition: background 0.2s, transform 0.1s, opacity 0.2s;
}

.button:hover {
  background: color-mix(in srgb, var(--primary) 90%, black);
}

.button:active {
  transform: scale(0.98);
}

.button:disabled {
  opacity: 0.6;
  cursor: not-allowed;
}
</style>

Qual dos dois você tem mais clareza?

Quando é uma mistureba com tudo no mesmo lugar, ou tudo separadinho?

lizzyman04

2 meses atrás

O exemplo que você trouxe mostra o pior cenário possível: um bloco gigante de utilitários sem qualquer abstração. Ninguém defende isso como ideal.

A questão é que, na prática, esse formulário viraria um componente <AuthForm />. Dentro dele, você teria essas classes, mas quem consome o componente vê apenas:

<AuthForm />

A transparência visual está no momento da criação/manutenção do componente, não na leitura da estrutura principal. E a "mistureba" que você aponta no Tailwind é explícita e local. No CSS separado, a mistureba está espalhada em arquivos, com efeitos colaterais implícitos (herança, especificidade, classes que afetam elementos que você nem lembra que existem).

São trade-offs diferentes. Um prioriza isolamento e contexto local. O outro prioriza semântica e camadas arquiteturais. Nenhum é objetivamente "mais claro" em todo cenário.

Pilati

2 meses atrás

Pessoa, são duas implementações diferentes para <AuthForm />

Vue é inteiro focado na separação de componentes e cada componente tem estilo, js e html separados dentro dele, isso facilita muito a manutenção futura.

Que manutenção o tailwind facilita? esse é o meu ponto geral.

Não existe um sistema que o componente é "criado e esquecido", Você vai ter que voltar a dar manutenção nos componentes, seja pra incluir mais coisas, arrumar algo que está quebrado

Tailwind ofereçe uma sobrecarga cognitiva insana para a manutenção.

lizzyman04

2 meses atrás

Entendo seu ponto e concordo com ele. Mas a questão não é que uma seja "melhor" que a outra! são filosofias diferentes sobre onde a complexidade deve ficar.

Você diz que Tailwind tem sobrecarga cognitiva. Eu concordo que tem na escrita. CSS tradicional tem na manutenção:

Alternar entre template e style a cada ajuste
Rastrear herança e especificidade implícitas
Classes reutilizadas em vários lugares com comportamentos distintos

Com Tailwind, o estilo está no elemento. Alterar padding é ir direto no elemento, não caçar qual classe controla o quê.

CSS tradicional otimiza leitura semântica. Tailwind otimiza edição local.

São trade-offs. Nenhum é objetivamente menos custoso! Cada um transfere o custo para um lugar diferente.

lucaspaniago

Autor

2 meses atrás

Uma dúvida, quando você aborda o tema de "manutenibilidade", porque você acredita que isso seja uma parte boa do Tailwind? Digo isso porque na minha opinião, acho mais simples ir na class ou no componente.styled e ver de fato o que ele faz ao invés de ter todas as informações centralizadas, me parece ser mais fácil de dar manutenção.

Além disso, nos seus projetos o Tailwind é aplicado diretamente no componente ou há uma abstração para que ele não polua os arquivos principais?

lizzyman04

2 meses atrás

Primeiro:

O ponto não é que Tailwind seja inerentemente mais fácil de dar manutenção, mas que ele resolve dois problemas recorrentes em times grandes:

CSS morto — com purge, o que não é usado simplesmente não vai parar na build. No CSS tradicional, ninguém tem coragem de deletar classes por medo de quebrar páginas que você não sabe que existem.
Consistência — times grandes tendem a criar variações ad-hoc ("preciso de um padding de 13px aqui"). Tailwind força o uso de um sistema de design predefinido, reduzindo a entropia visual.

Segundo:

Nos projetos que uso, a regra é simples — componentes de UI (botões, inputs, cards) usam Tailwind diretamente. Páginas e seções compostas usam esses componentes. Nunca abstraio utilitários com @apply porque isso recria o problema do CSS tradicional só que com sintaxe pior. O "poluição" fica contida dentro do arquivo do componente, que é o único lugar onde aquele estilo importa.

Pilati

2 meses atrás

No CSS tradicional, ninguém tem coragem de deletar classes por medo de quebrar páginas que você não sabe que existem.

Isso facilmente se resolve com Css Modules ou Scoped Style

lizzyman04

2 meses atrás

Sim, CSS Modules e scoped style resolvem o problema de CSS morto e vazamento de escopo. Mas, não foi isso que eu quis dizer.

O ponto do "medo de deletar" não é sobre escopo, é sobre acoplamento implícito. Mesmo com scoped, quando você precisa alterar o padding do .input, vai lá no <style>, mexe, volta. Se esqueceu como o hover do botão se comporta, volta no <style>. Tailwind elimina esse vai-e-volta.

No fim, como disse CSS otimiza a leitura semântica. Tailwind otimiza a edição local.

Programmer404

2 meses atrás

Quando eu era do Front-end, eu usava bastante tailwind. Na verdade eu sempre usava, pois escrever CSS na mão é coisa de maluco. No entanto, antes do tailwind, eu já tinha uma base CSS forte, então eu entendia muito bem o que cada coisa fazia.

Código de Front-end no geral sempre vai ser uma bagunça pois componentes e tags html são extensos mesmo. Piora ainda mais com os estilos tailwind.

Talwindcss sem dúvida é o padrão para produtividade no Front-end. Muitas library de componentes usam tailwindcss também. Da para amenizar a quantidade de estilos em um componente usando técnicas que eles mesmos provem na documentação deles.

Pilati

2 meses atrás

Código de Front-end no geral sempre vai ser uma bagunça pois componentes e tags html são extensos mesmo

Se você defende isso:

<form class="w-full max-w-xs space-y-3">
    <input type="email" placeholder="Email" class="h-11 w-full rounded-lg border border-border bg-secondary px-4 text-sm text-foreground placeholder:text-muted-foreground focus:outline-none focus:ring-1 focus:ring-primary" value="">
    <input type="password" placeholder="Password" class="h-11 w-full rounded-lg border border-border bg-secondary px-4 text-sm text-foreground placeholder:text-muted-foreground focus:outline-none focus:ring-1 focus:ring-primary" value="">
    <button type="submit" class="flex h-11 w-full items-center justify-center rounded-lg bg-primary text-sm font-normal text-primary-foreground transition-colors hover:bg-primary/90 active:scale-[0.98] disabled:opacity-60">Continue</button>
</form>

Em vez disso:

<form class="form">
    <input type="email" placeholder="Email" class="field" value="">
    <input type="password" placeholder="Password" class="field" value="">
    <button type="submit" class="btn">Continue</button>
</form>

Só tenho que te chamar de doido hahahaha

Programmer404

2 meses atrás

O problema é no gerenciamento dessas classes e no arquivo .css. Não estou dizendo que prefiro tailwindcss, que foi motivo de muita dor de caebça para mim, mas que para produtividade, não tenho dúvidas que é a soluçao padronizada.

Hoje em dia .css melhorou bastante e se tornou mais modular, é claro, mas questão de tempo até que classes tenham o mesmo estilo, ou seja necessário refatoratr um arquivo com mais de 1k de linhas para otimizar mais, enfim, há diversos pontos.

DevJonathan

2 meses atrás

Muitos reclamam da verbosidade dos dos className q o tailwind tras. Mas esta é a ideia, nem sempre verbosidade é ruim.
Eu prefiro tailwind, por conta das classes prontas, px-2 etc etc, é muito mais rapido e fluído.

Acho q a i.a programa muito bem com tailwind, pois fica tudo no contexto direto. Nada de arquivo q referencia outro arquivo. Ja esta tudo no className.

Existem formas de deixar o classname mais enxuto caso seja preciso. Quando se acostuma com tailwind acho difícil querer sair dele, é simplesmente uma mão na roda. Minha visão...

nfoj

2 meses atrás

Sou Jr também e vou deixar minha opinião, acho que os projetos de estudo vale tudo, então é um momento bom para aprender principalmente se for freelancer, pegar pequenos projetos e aplicar tecnologias e formas diferentes de fazer em coisas que vão atender poucas pessoas faz você não só aprender algo novo como também ter contato depois quando precisar atualizar, adicionar novas funcionalidades e coisas do tipo.

Agora em relação ao Tailwind, não gosto muito, prefiro sempre usar css, todos meus projetos eu separo e organizo, tenho a mesma opinião em relação a framework, prefiro usar js para tudo, nada contra de verdade, apenas acho que quando você organiza bem um projeto, separa bem cada página, você tem um controle enorme de tudo e facilmente consegue atualizar, melhorar e corrigir.

Não sei, hoje acho que a coisa que mais gosto em qualquer projeto independente da tecnologia, é ter algo bem organizado e que facilmente eu entenda cada parte, o resto você aprende conforme vai precisando.