Executando verificação de segurança...
1

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.

Carregando publicação patrocinada...
2

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

1

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.

1

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?

2

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?

1

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...

1

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.

1

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

1

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.