1) Modelo mental: “utility-first” vs “estilos por componente”

Tailwind CSS incentiva a criação de UI usando classes utilitárias diretamente no markup. Você compõe layout, espaçamento,
tipografia e cores com uma linguagem declarativa e consistente.

CSS Modules parte do princípio de que os estilos devem pertencer ao componente. O arquivo
*.module.css gera classes com escopo local (hash), evitando colisões e mantendo o CSS organizado por responsabilidade.

2) Escopo, colisões e previsibilidade de mudanças

CSS é historicamente propenso a efeitos colaterais: mudar uma regra global pode quebrar outra parte da UI.
Com CSS Modules, isso diminui bastante, pois as classes são locais ao componente.

Tailwind também reduz colisões porque trabalha com classes bem específicas (cada utilitário é “um estilo atômico”).
Ainda assim, você pode ter conflitos quando usa custom classes, plugins, ou quando mistura estilos globais (ex.: reset manual) com utilitários.

• CSS Modules: colisões são menos prováveis por design; seletor global dentro de um módulo é um alerta.
• Tailwind: colisões são raras no nível de utilitários; o risco aparece ao criar regras customizadas e reaproveitar nomes.

Na prática, ambos aumentam previsibilidade, mas por caminhos diferentes: escopo local via hash (CSS Modules) vs composição explícita no markup (Tailwind).

3) Manutenibilidade: legibilidade, consistência e “custo de refatoração”

O custo de manutenção não é só “quantidade de CSS”. É principalmente: como você evolui o design sem criar divergência.

Tailwind: velocidade e padronização (com risco de verbosidade)

• Consistência: tokens e escala (spacing, colors, typography) aparecem como convenções do framework.
• Refatoração: mudar escala/tokens é relativamente direto (via config) e costuma refletir no app.
• Leitura: interfaces complexas podem ter linhas longas e “classe soup” se não houver convenções.

CSS Modules: CSS mais “natural” (com risco de regras duplicadas)

• Leitura: o CSS fica mais familiar para quem pensa em seletores e regras.
• Encapsulamento: os estilos seguem o componente (bom para times que preferem separar markup e estilo).
• Refatoração: você precisa decidir bem como reutilizar padrões (ex.: componentes visuais) para evitar repetição.

4) Performance e build: o que observar no mundo real

Performance aqui tem duas faces: tempo de build e tamanho/eficiência do CSS gerado.
O impacto final varia com arquitetura e configuração.

O ponto mais importante: medir antes de decidir. Em geral, o “gargalo” raramente é o método de CSS em si — é a arquitetura, o design system e a disciplina de reutilização.

Exemplo comparativo (React): Tailwind vs CSS Modules

Abaixo eu deixo um exemplo equivalente de card com estado de “active”. Note como em Tailwind a regra fica explícita na classe,
enquanto em CSS Modules a regra vive no arquivo de estilo do componente.

// Tailwind CSS (exemplo)
function CardTailwind({ active = false }) {
  return (
    

      
Status
      

        {active ? "Ativo" : "Inativo"}
      
    
  );
}

// CSS Modules (exemplo)
import styles from "./Card.module.css";

function CardModules({ active = false }) {
  return (
    <div
      className={[
        styles.card,
        active ? styles.active : ""
      ].join(" ")}
    >
      <h3 className={styles.title}>Status</h3>
      <p className={styles.desc}>{active ? "Ativo" : "Inativo"}</p>
    </div>
  );
}

// Card.module.css
.card {
  border-radius: 12px;
  padding: 12px 16px;
  border: 1px solid rgba(255,255,255,.10);
  background: rgba(15,27,49,.35);
  backdrop-filter: blur(8px);
  transition: box-shadow .15s ease, border-color .15s ease;
}
.active {
  border-color: rgba(124,92,255,.70);
  box-shadow: 0 0 0 2px rgba(124,92,255,.25);
}
.title {
  font-size: 14px;
  font-weight: 700;
  color: #e7eefc;
}
.desc {
  margin-top: 4px;
  font-size: 12px;
  color: #a9b7da;
}