O fim do React? Uma análise calma sobre Signals, Svelte 5 e o futuro do frontend

1. O contexto que gerou o burburinho: por que "fim do React" virou manchete

1.1. O ciclo natural de hype e desilusão no ecossistema frontend

Desde que o React foi lançado pelo Facebook em 2013, o ecossistema frontend vive um ciclo previsível: uma nova tecnologia surge, gera entusiasmo, enfrenta críticas e, eventualmente, encontra seu lugar. Nos últimos meses, o burburinho em torno do "fim do React" foi alimentado por três fatores principais: o lançamento do Svelte 5 com seus Runes, a popularização dos Signals como paradigma de reatividade, e o cansaço de uma parcela da comunidade com a complexidade crescente do React (Server Components, Suspense, hooks complexos).

1.2. A ascensão do Svelte 5 e a promessa de reatividade sem Virtual DOM

Svelte 5 chegou prometendo uma reatividade mais explícita e previsível. Diferente do Svelte 4, que era um compilador que "sumia" com o framework, o Svelte 5 introduziu os Runes — símbolos especiais ($state, $derived, $effect) que tornam a reatividade visível no código. A promessa? Performance superior ao React em atualizações frequentes, sem a sobrecarga do Virtual DOM.

1.3. Signals como novo paradigma: o que são e por que estão em todas as bibliotecas

Signals são primitivas de reatividade que permitem atualizações granulares — apenas os componentes que dependem de um sinal específico são re-renderizados, sem necessidade de reconciliação de árvore. Eles estão presentes no Solid.js, Qwik, Preact (via @preact/signals) e agora no Angular. A pergunta inevitável: se Signals são tão eficientes, por que React insiste no Virtual DOM?

2. Signals: a verdadeira revolução silenciosa no gerenciamento de estado

2.1. Como Signals funcionam: reatividade granular vs. reconciliação de árvore

Enquanto React re-renderiza componentes inteiros e compara árvores virtuais, Signals rastreiam dependências individuais. Quando um sinal muda, apenas os consumidores diretos são atualizados. Veja a diferença:

// React: re-renderiza o componente inteiro
function Contador() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}

// Signals: apenas o nó que usa o sinal é atualizado
const count = signal(0);
function Contador() {
  return <button onClick={() => count.value++}>{count.value}</button>;
}

2.2. Comparação prática: useState vs. Signals em cenários de alta frequência de atualização

Em um dashboard financeiro com 1000 indicadores atualizando a cada 100ms, o React precisaria re-renderizar toda a árvore ou usar memoização complexa. Com Signals, apenas os indicadores que mudaram são atualizados:

// React com memo (ainda re-renderiza se o pai mudar)
const Indicador = React.memo(({ valor }) => <span>{valor}</span>);

// Signals: atualização granular automática
const precos = signal(Array(1000).fill(0));
// Apenas o <span> que depende do índice alterado é atualizado

2.3. Por que Signals não são exclusividade do Svelte — e como React pode se beneficiar

React já experimenta Signals via useSignal experimental no pacote react (canary). Bibliotecas como @preact/signals-react permitem usar Signals dentro de componentes React. Isso sugere que, em vez de substituir React, Signals podem ser incorporados como uma ferramenta adicional.

3. Svelte 5: o que mudou de fato com os Runes ($state, $derived, $effect)

3.1. A quebra de compatibilidade necessária: de compilador reativo para reatividade explícita

No Svelte 4, a reatividade era implícita — qualquer let declarado no script era reativo. No Svelte 5, você precisa declarar explicitamente com $state. Isso quebrou milhares de componentes, mas trouxe previsibilidade:

// Svelte 4 (implícito)
let count = 0;
function increment() { count++; }

// Svelte 5 (explícito com Runes)
let count = $state(0);
function increment() { count++; }

3.2. Svelte 5 ainda é "sem Virtual DOM"? Análise do runtime e do mecanismo de atualização

Sim, Svelte 5 continua sem Virtual DOM. O compilador gera código JavaScript puro que manipula o DOM diretamente. Os Runes são processados em tempo de compilação, gerando chamadas a funções do runtime mínimo do Svelte. O resultado: bundles menores e atualizações mais rápidas que React em benchmarks como o js-framework-benchmark.

3.3. Exemplo real de migração: componente Svelte 4 vs. Svelte 5 com Runes

<!-- Svelte 4 -->
<script>
  let nome = 'Mundo';
  let maiusculo = nome.toUpperCase();
  $: console.log('Nome mudou:', nome);
</script>
<h1>Olá {maiusculo}!</h1>

<!-- Svelte 5 -->
<script>
  let nome = $state('Mundo');
  let maiusculo = $derived(nome.toUpperCase());
  $effect(() => console.log('Nome mudou:', nome));
</script>
<h1>Olá {maiusculo}!</h1>

4. React ainda é imbatível em ecossistema e escala — mas por quanto tempo?

4.1. O peso da herança: Server Components, Suspense e a complexidade acumulada

React Server Components (RSC) adicionaram uma camada de complexidade que muitos desenvolvedores consideram desnecessária. Suspense, concorrência e o novo compilador React Forget prometem simplificar, mas a realidade é que a curva de aprendizado do React aumentou significativamente.

4.2. A força da comunidade: bibliotecas, empregabilidade e inércia corporativa

Com mais de 200 mil pacotes no npm, uma vasta gama de bibliotecas de componentes (Material UI, Ant Design, Chakra) e milhares de vagas de emprego, React tem uma inércia que nenhum concorrente consegue igualar. Grandes empresas como Meta, Netflix, Airbnb e Uber usam React extensivamente.

4.3. Onde React ainda ganha (e onde perde feio) para Svelte e Signals

React ganha em: ecossistema maduro, SSR complexo com Next.js, suporte corporativo, ferramentas de debugging. Perde feio em: tamanho de bundle, performance em atualizações frequentes, simplicidade de aprendizado para iniciantes.

5. O futuro do frontend: coexistência, não substituição

5.1. Cenários onde Svelte/Signals fazem mais sentido que React

  • Dashboards e aplicações com muitas atualizações em tempo real
  • Aplicações mobile com Tauri ou Electron (bundle menor)
  • Projetos pessoais e MVPs (menos boilerplate)
  • Jogos e animações no navegador (performance granular)

5.2. Cenários onde React continua sendo a melhor escolha

  • Grandes equipes com múltiplos projetos legados
  • Aplicações com SSR complexo e SEO crítico (Next.js)
  • Produtos que dependem de bibliotecas exclusivas do ecossistema React
  • Empresas com processos de contratação baseados em React

5.3. A tendência de hibridização: usando Signals dentro de React, e React dentro de Svelte

Já existem soluções como @preact/signals-react que permitem usar Signals em componentes React. Da mesma forma, é possível embutir componentes React em Svelte via svelte-react. O futuro não será "React vs Svelte", mas "como combinar o melhor de cada mundo".

6. Lições para quem está escolhendo a stack hoje (sem pânico)

6.1. Critérios objetivos para decidir

  • Maturidade do time: time júnior? Svelte pode ser mais produtivo. Time sênior? React oferece mais controle.
  • Tipo de produto: dashboard em tempo real → Svelte/Signals. E-commerce com SSR complexo → React/Next.js.
  • Ciclo de vida: projeto de curto prazo → Svelte. Projeto de longo prazo com manutenção → React (mais profissionais disponíveis).

6.2. O que aprender independentemente da escolha

  • Conceitos de reatividade (não importa o framework)
  • Como compiladores otimizam código (Svelte, Solid, Vue)
  • Gerenciamento de estado global (Signals, Zustand, Pinia)
  • SSR e hidratação (Next.js, SvelteKit, Nuxt)

6.3. Previsão realista: React não vai morrer, mas vai se transformar

Assim como jQuery não "morreu" — foi absorvido por frameworks modernos —, React não vai desaparecer. Vai se transformar: provavelmente incorporará Signals oficialmente, simplificará sua API e continuará sendo a escolha dominante para aplicações empresariais. Svelte e Signals crescerão em nichos específicos, e a competição beneficiará toda a comunidade.

Referências