Voltar ao blog
Next.js & React5 min de leitura

O React Apostou Contra os Signals, e Todo Mundo Apostou do Outro Lado

O React escolheu um compilador. Svelte, Solid, Vue, Preact e Angular escolheram signals. Isso não é debate de performance, é uma aposta sobre quem é dono da otimização.

Gabriel Santos

O React Apostou Contra os Signals, e Todo Mundo Apostou do Outro Lado

Todo framework passou anos perseguindo o mesmo conserto: parar de fazer o dev escrever useMemo na mão. Em 2026 o ecossistema finalmente se dividiu em dois times resolvendo isso, e o React escolheu exatamente o caminho que todo mundo abandonou.

O time que escolheu signals

Svelte, Solid, Vue, Preact e Angular convergiram para signals: valores reativos granulares que rastreiam seus próprios dependentes e atualizam só o nó exato do DOM que depende deles. Sem re-render, sem diffing, sem memoização para lembrar. É preciso por construção. A proposta de Signals do TC39 está avançando na padronização justamente porque muitos frameworks chegaram ao mesmo princípio de forma independente, uma implementação nativa e compartilhada encerraria anos de código de reatividade específico de cada framework.

O time de um só

O React Compiler apostou no caminho oposto. Em vez de um novo princípio reativo, uma etapa de build lê o código do seu componente e insere a memoização que você escrevia à mão, useMemo, useCallback, React.memo, sem você tocar em nada disso. Seu código continua no mesmo modelo de "re-renderizar o componente inteiro" que o React sempre teve. O compilador só torna esse modelo barato o suficiente para deixar de importar.

  • Signals mudam como você escreve componentes: valores reativos granulares, uma mudança real de modelo mental
  • O compilador não muda nada em como você escreve componentes, só o que a etapa de build gera
  • Signals precisam de um princípio em nível de linguagem para atingir todo o potencial, ainda em padronização
  • O compilador já funciona, dentro do modelo que o React já entregava

Por que a bifurcação importa mais que qualquer feature

Isso não é um debate de performance. É uma aposta sobre onde a complexidade deveria morar. Signals empurram para como você escreve componentes. O compilador empurra para a etapa de build e mantém a escrita simples, ao custo de confiar numa ferramenta para inferir corretamente o que um useMemo explícito deixava claro. Nenhum dos dois lados está errado aqui, e essa é a parte incômoda. São respostas diferentes para uma pergunta: quem é dono da otimização, o dev, a linguagem ou o compilador?

O que fazer com isso na prática

Se você está no React, adote o compilador e pare de escrever memoização à mão, essa briga acabou. Se você está escolhendo framework para algo do zero, saiba que signals deixaram de ser nicho, é para lá que o resto do ecossistema está padronizando. Escolha pelo seu time e seu ecossistema, não por qual soa mais novo esse mês. As duas apostas são sérias e as duas estão em produção agora. Qual delas você teria feito?

Curtiu?

Explore mais artigos de engenharia da CodaCrew.