Contexto
Abra qualquer componente React estilizado hoje e você vai encontrar uma de duas coisas: uma lista de classes utilitárias no JSX, ou um template literal de CSS anexado ao componente. Tailwind CSS e styled-components representam, cada um, um desses dois mundos. Tailwind aposta em classes utilitárias: em vez de nomear componentes e escrever regras CSS para cada um, você compõe a aparência diretamente no markup com classes pequenas e previsíveis (flex, gap-4, text-sm). styled-components aposta no CSS-in-JS: você escreve CSS de verdade dentro de um template literal anexado a um componente React, e a biblioteca cuida de gerar classes com escopo único e injetar esse CSS no navegador.
A diferença mais relevante para quem está escolhendo hoje não é só de sintaxe, é de momento do projeto. Tailwind passou por uma reescrita interna do seu motor de processamento, com configuração de tema migrando de um arquivo JavaScript para diretivas dentro do próprio CSS, e segue em desenvolvimento ativo. styled-components, depois de anos como a opção padrão de CSS-in-JS no ecossistema React, teve seus mantenedores anunciando publicamente que o projeto entrou em modo de manutenção — bugs críticos e correções de segurança continuam sendo tratados, mas não deve chegar recurso novo relevante.
Quando escolher Tailwind CSS
Tailwind compensa quando o time quer previsibilidade de build e não quer pagar o custo de runtime de gerar CSS no navegador a cada render. As classes são compostas direto no JSX:
export function Card({ title }: { title: string }) {
return (
<div className="rounded-xl border border-slate-800 bg-slate-900 p-6 shadow-sm">
<h3 className="text-lg font-semibold text-slate-100">{title}</h3>
</div>
);
}
Não existe um objeto de tema em JavaScript separado da folha de estilos: cores, espaçamentos e tipografia são declarados como tokens dentro do próprio CSS, usando a diretiva @theme, e cada token vira automaticamente uma variável CSS e uma classe utilitária correspondente — sem arquivo de configuração obrigatório. Como o CSS final é extraído em build-time, o navegador nunca precisa executar JavaScript para descobrir qual estilo aplicar, o que elimina uma classe inteira de problemas de performance que CSS-in-JS runtime historicamente carrega. O preço dessa abordagem é o vocabulário: o time precisa aprender e memorizar os nomes das classes utilitárias, e o markup fica mais denso de atributos className do que de elementos semânticos.
Quando escolher styled-components
styled-components compensa quando o projeto já pensa em termos de componentes estilizados como unidade de composição, e o time prefere escrever CSS de verdade — seletores, pseudo-classes, media queries — dentro do próprio arquivo do componente, com acesso direto a props tipadas:
import styled from "styled-components";
const Button = styled.button<{ $variant: "primary" | "ghost" }>`
padding: 0.5rem 1rem;
background: ${(p) => (p.$variant === "primary" ? "#4f46e5" : "transparent")};
`;
Essa proximidade com CSS puro reduz a curva de aprendizado para quem já domina a linguagem, e a tipagem das props de estilo pega em tempo de compilação erros que, em uma abordagem baseada em string de classes, só apareceriam visualmente. O ponto que pesa contra adotar styled-components hoje em um projeto novo é justamente o modo de manutenção: a biblioteca não vai acompanhar mudanças futuras do React em torno de renderização concorrente ou Server Components a menos que seja estritamente necessário, e migrar uma base de código grande de CSS-in-JS para outra abordagem depois de anos de investimento não é uma tarefa trivial.
Veredito
Na escolha entre Tailwind e styled-components hoje, o rumo de cada projeto pesa mais do que a sintaxe entre classes utilitárias e template literals. Tailwind está investindo em performance de build e em fazer o CSS ser a fonte de verdade do design system; styled-components sinalizou publicamente que não vai crescer além do que já é. Isso não torna styled-components inutilizável — projetos existentes que já dependem dele continuam funcionando e recebendo correções — mas muda o cálculo para quem está começando algo novo hoje: adotar uma dependência central de estilização que seus próprios mantenedores dizem não recomendar mais para projetos novos é um risco que precisa ser pesado contra o quanto o time já domina CSS-in-JS. Para um projeto greenfield, esse é o fator que mais deveria influenciar a escolha — mais do que preferência estética por classes ou por template literals.