CSS Básico, BEM e ACSS: qual arquitetura usar no seu projeto?

Comparação de arquiteturas CSS

Sem uma metodologia, o CSS cresce sem direção. Cada desenvolvedor escreve como aprendeu, o seletor mais novo sobrescreve o mais antigo sem querer, e ninguém toca no que já existe por medo de quebrar algo. Em projetos com mais de dois devs e mais de seis meses de vida, isso é a regra — não a exceção.

A boa notícia: o problema não é o CSS em si, mas a falta de um contrato explícito sobre como escrever e organizar os estilos. É exatamente isso que as metodologias de arquitetura CSS resolvem.

Este artigo compara três abordagens — CSS Básico, BEM e CSS Atômico (ACSS) — explicando o problema que cada uma resolve, quando usá-la, e o que você ganha (e perde) com cada escolha.

O problema que todas tentam resolver

Imagine que você precisa estilizar um botão desabilitado dentro de um card de produto. Sem metodologia, você talvez escreva:

.card button.disabled { opacity: 0.5; }

Seis meses depois, outro dev precisa do mesmo botão numa modal. Ele escreve:

.modal .btn-disabled { opacity: 0.4; cursor: not-allowed; }

Agora há dois estilos para "botão desabilitado" no projeto, com valores diferentes, em seletores diferentes, sem conexão explícita entre si. Multiplique isso por centenas de componentes ao longo de anos.

Metodologias de arquitetura CSS são convenções que evitam esse problema — definindo regras sobre como nomear, organizar e escalar os estilos de forma previsível.

CSS Básico — simples por design

O CSS Básico não é uma metodologia — é a ausência de uma. Você escreve seletores que fazem sentido para o contexto imediato, sem seguir convenções de nomenclatura ou estrutura.

.header {
  background: #1e1e2e;
  padding: 20px;
}
 
.button {
  background: #cba6f7;
  color: #1e1e2e;
  padding: 10px 20px;
  border-radius: 6px;
}

Para um projeto pessoal, um protótipo ou uma landing page simples, isso funciona perfeitamente. O problema aparece quando o projeto cresce:

• Conflitos de especificidade

  Seletores competem entre si sem regra clara. A solução viram !important ou seletores cada vez mais específicos.

• Sem convenção de nomenclatura

  .button, .btn, .cta-button, .action-btn — qual usar? Cada dev resolve diferente.

• Difícil de escalar

  Com múltiplos devs, o CSS cresce sem estrutura. Descobrir de onde um estilo vem e o que ele afeta torna-se investigação.

• Velocidade inicial

  Nenhuma curva de aprendizado. Para projetos pequenos e de vida curta, é a escolha mais racional.

Use CSS Básico quando: o projeto é pequeno, você trabalha sozinho, e o escopo não vai crescer significativamente.

BEM — tornando relacionamentos explícitos

O BEM (Block, Element, Modifier) resolve o problema de nomenclatura com uma convenção simples: o nome da classe descreve explicitamente de onde o elemento vem e o que ele é.

A sintaxe:

• .bloco — componente autônomo e independente
• .bloco__elemento — parte interna do bloco (dois underscores)
• .bloco--modificador — variação do bloco (dois hífens)

/* Bloco */
.card { border: 1px solid #45475a; border-radius: 8px; }
 
/* Elementos do bloco */
.card__title { font-size: 18px; font-weight: 600; }
.card__price { color: #a6e3a1; font-weight: 700; }
.card__button { background: #cba6f7; padding: 8px 16px; }
 
/* Modificadores */
.card--featured { border-color: #f9e2af; }
.card__button--disabled { opacity: 0.5; cursor: not-allowed; }

O insight central do BEM: ao tornar o componente e seus elementos explícitos no nome da classe, você elimina a ambiguidade. .card__title é inequivocamente o título de um card — não qualquer título que esteja dentro de um card por acidente de cascata.

• Cada classe é autodocumentada

  .card__button--disabled diz exatamente o que é, de onde vem, e qual seu estado — sem precisar abrir o HTML.

• Especificidade previsível

  Todas as classes BEM têm especificidade (0, 1, 0). Sem surpresas de cascade, sem !important.

• Blocos são portáveis

  Um bloco BEM bem escrito pode ser copiado para qualquer parte do projeto sem afetar outros estilos.

• Nomes podem ficar longos

  .navigation__item__link--active--mobile existe no mundo real. Disciplina é necessária para não abusar do aninhamento.

Use BEM quando: o projeto tem mais de um desenvolvedor, os componentes são reutilizados em múltiplos contextos, ou você precisa de uma convenção que toda a equipe consiga seguir sem ambiguidade.

CSS Atômico (ACSS) — classes de propósito único

O CSS Atômico inverte completamente o paradigma. Em vez de criar classes semânticas que descrevem o que o elemento é, você aplica diretamente classes que descrevem o que o CSS faz.

<!-- BEM: semântico -->
<button class="card__button card__button--primary">Comprar</button>
 
<!-- ACSS / Tailwind: atômico -->
<button class="bg-purple-400 text-gray-900 px-4 py-2 rounded-md hover:opacity-90">Comprar</button>

Cada classe faz uma única coisa: bg-purple-400 aplica um background, px-4 aplica padding horizontal, rounded-md aplica border-radius. Não há CSS customizado — o estilo vive inteiramente no HTML.

• CSS não cresce com o projeto

  Com BEM ou CSS Básico, cada novo componente adiciona novas linhas de CSS. Com ACSS, você reutiliza as mesmas classes em tudo — o bundle de CSS tem tamanho quase fixo.

• Zero decisões de nomenclatura

  Não existe "devo chamar isso de .btn ou .button?". Você escreve bg-blue-500 e pronto.

• Consistência de design automática

  As classes utilitárias usam os mesmos valores de design tokens — spacing, cores, tipografia. Impossível usar um valor fora do sistema acidentalmente.

• HTML fica verboso

  class="flex items-center gap-4 px-6 py-3 bg-purple-500 text-white rounded-xl hover:bg-purple-600 transition-colors" é real. Editores modernos amenizam isso com syntax highlighting.

• Curva de aprendizado inicial

  Memorizar os nomes das classes utilitárias leva tempo. A produtividade inicial pode cair antes de subir.

Use ACSS/Tailwind quando: o projeto usa um design system com tokens bem definidos, a equipe está confortável com a abordagem, ou você precisa de consistência visual automática sem esforço manual.

Comparação ao vivo — o mesmo componente nas três abordagens

Veja o mesmo card de produto estilizado com CSS Básico, BEM e ACSS. Troque de abordagem e adicione variantes para entender como cada metodologia lida com mudanças:

.card { border: 1px solid #e5e7eb; border-radius: 8px; padding: 16px; background: #fff; }
.card__title { font-size: 18px; font-weight: 600; color: #111827; margin-bottom: 4px; }
.card__price { color: #16a34a; font-weight: 700; font-size: 20px; margin-bottom: 12px; }
.card__button { background: #3b82f6; color: white; padding: 8px 16px; border-radius: 4px; border: none; cursor: pointer; font-weight: 600; }

.card { border: 1px solid #e5e7eb; border-radius: 8px; padding: 16px; background: #fff; }
.card__title { font-size: 18px; font-weight: 600; color: #111827; margin-bottom: 4px; }
.card__price { color: #16a34a; font-weight: 700; font-size: 20px; margin-bottom: 12px; }
.card__button { background: #3b82f6; color: white; padding: 8px 16px; border-radius: 4px; border: none; cursor: pointer; font-weight: 600; }

Qual escolher?

Não existe resposta universal — a escolha certa depende do contexto do projeto.

• Consistência é mais importante que a metodologia

  Uma equipe que segue o CSS Básico de forma disciplinada produz código melhor do que uma equipe que usa BEM de forma inconsistente.

• Metodologias podem ser combinadas

  Muitos projetos usam BEM para componentes customizados e Tailwind para utilitários de layout. Não precisa ser tudo ou nada.

• Migração tem custo real

  Adotar uma nova metodologia num projeto existente é trabalho. Avalie se o ganho justifica o esforço antes de decidir.