React está vencendo por padrão e desacelerando a inovação no frontend

• Hoje, a adoção do React acontece por padrão, e não por superioridade técnica, e isso está desacelerando a inovação no ecossistema de frontend
• Muitas equipes escolhem o “React que todo mundo conhece” sem considerar as restrições do projeto, criando uma situação em que os efeitos de rede passam a determinar decisões de arquitetura mais do que a adequação técnica
• Frameworks inovadores como Svelte, Solid e Qwik oferecem modelos de desempenho melhores, mas ficam para trás na disputa pelo mainstream por falta de adoção
• O React tem muitas qualidades, mas o problema é que a mentalidade de React-como-padrão aumenta o custo de oportunidade e impede considerar alternativas melhores
• Para um ecossistema saudável, diversidade e concorrência são necessárias, e a mensagem é que frameworks devem ser escolhidos com base em restrições e adequação, não como padrão

---

A vitória do React por padrão e seus limites

• O React já não é mais escolhido por superioridade técnica; em muitos casos, ele é adotado como padrão
  • Isso reforça o hábito de equipes usarem React automaticamente, sem avaliar as restrições do projeto
• Frameworks alternativos (Svelte, Solid, Qwik), apesar de terem vantagem de desempenho sobre o React em certos cenários, não são devidamente avaliados
• Mais do que um problema do próprio React, a mentalidade de React-como-padrão está criando uma estrutura que bloqueia a inovação

O teto da inovação

• O Virtual DOM do React fazia sentido em 2013, mas hoje atua como overhead desnecessário
• Hooks resolveram problemas dos componentes de classe, mas introduziram novas complexidades, como arrays de dependência e stale closure
• Server Components e React Compiler tentam melhorar o desempenho, mas isso funciona como um remendo para contornar as limitações do modelo do React
• Já as Runes do Svelte, a reatividade granular do Solid e a Resumability do Qwik mostram um potencial muito maior com modelos completamente diferentes

Dívida técnica

• Escolher React como padrão gera custos de runtime desnecessários e a carga de gerenciar rerenderizações
• Desenvolvedores acabam gastando tempo com dependências de effects ou gerenciamento de hydration, em vez de focar no valor de negócio
• Em benchmarks, o Solid mostra desempenho de atualização 2 a 3 vezes mais rápido que o React
• Pensar centrado em padrões do React enfraquece os fundamentos da web e aprofunda a inércia arquitetural

Frameworks alternativos

• Svelte: a revolução do compilador

  • O Svelte executa a maior parte do trabalho em tempo de compilação e elimina o virtual DOM
  • Os componentes ficam mais próximos da estrutura nativa da web, e o overhead em tempo de execução cai bastante
  • Ainda assim, sua adoção é baixa por causa da percepção de que “há poucas oportunidades de trabalho”
  • Casos como The Guardian, Wired e Shawn Wang mostram que, após adotar Svelte, houve grande redução no tamanho dos bundles e no tempo de carregamento, além de melhora na produtividade dos desenvolvedores
  • Por exemplo, Shawn Wang reduziu o tamanho de seu site de 187KB em React para 9KB com Svelte

• Solid: uma abordagem direta à reatividade fina

  • O Solid combina reatividade precisa (reatividade fina) com sintaxe JSX
  • Por meio de signals, ele acessa diretamente apenas o DOM alterado, evitando completamente gargalos de reconciliation
  • Tem como pontos fortes o excelente desempenho e a simplicidade no gerenciamento de estado
  • Os casos de adoção ainda são limitados, mas equipes pioneiras relatam grande inovação tanto em eficiência quanto em simplicidade de código

• Qwik: a inovação da Resumability

  • Em vez de traditional hydration, o Qwik tem como força a resumability, permitindo startup imediato
  • Ele carrega progressivamente apenas o que é necessário no momento, e tanto estado quanto código podem ser serializados
  • Mostra desempenho excepcional em sites grandes, sessões longas e redes lentas
  • Muitas equipes ainda não o testaram, mas as que adotaram relatam grandes melhorias tanto no tempo de carregamento inicial quanto na eficiência de recursos

• A complexidade da API do React e a simplicidade dos frameworks alternativos

  • A API do React inclui conceitos complexos como hook, context, reducer, memoization etc., elevando a carga cognitiva para desenvolvedores
  • Quando usados de forma incorreta, esses recursos aumentam muito o risco de bugs por problemas de dependência e o peso de decisões excessivamente elaboradas
  • Por exemplo, a interrupção da Cloudflare em 12 de setembro de 2025 também foi causada por um erro na configuração do array de dependências de useEffect
  • Em contraste, alternativas como Svelte, Solid e Qwik usam APIs muito menores e mais focadas, enfatizando simplicidade e os princípios fundamentais da web
  • Os três têm vantagem técnica suficiente, mas, por causa da cultura do React como padrão, na maioria dos casos nem chegam a ser testados

A prisão dos efeitos de rede

• O domínio do React está criando barreiras que se reforçam sozinhas
• O mercado de trabalho busca apenas “desenvolvedores React”, e em cada organização bibliotecas de componentes e hábitos de desenvolvimento acabam cristalizados em torno do React
• Líderes avessos a risco naturalmente escolhem o React por parecer a opção segura, e as instituições de ensino seguem a mesma lógica
• Essa estrutura é uma característica de um ecossistema sem concorrência saudável

Rompendo os efeitos de rede

• Para sair disso, é preciso uma escolha consciente
• Líderes técnicos precisam abandonar a inércia e decidir a arquitetura com base nos requisitos; empresas podem reservar orçamento para pilotos e testar alternativas
• Desenvolvedores também devem evitar insistir em um único paradigma e aprender a lógica de vários frameworks
• Instituições de ensino precisam ampliar aulas sobre conceitos agnósticos de framework, e contribuidores open source podem fortalecer ecossistemas menores
  A mudança não vem sozinha; ela precisa ser construída intencionalmente.

Checklist para avaliar frameworks

Em novos projetos, os seguintes critérios podem ser usados como base de avaliação

• Requisitos de desempenho: carregamento inicial, eficiência de atualização, tamanho de bundle e possibilidade de otimização em tempo de compilação
• Capacidade da equipe e curva de aprendizado: considerar a experiência prévia; também existem alternativas compatíveis com React, como o Solid
• Escalabilidade e custo total de propriedade: avaliar custos de longo prazo, incluindo manutenção, gestão de dependências e dívida técnica
• Adequação do ecossistema: equilíbrio entre maturidade e inovação, com pilotos em áreas não centrais e testes de ROI

Objeções comuns e respostas

• Maturidade do ecossistema: um ecossistema mais antigo não é necessariamente mais adequado para os problemas de hoje. Dependência alta de pacotes de terceiros gera efeitos colaterais como maior custo de manutenção, vulnerabilidades de segurança e bundles inchados. Ecossistemas menores, ao contrário, podem focar mais nos fundamentos da web, e com o avanço de ferramentas de IA ficou mais fácil e rápido desenvolver soluções customizadas.
• Problemas de contratação: a demanda acaba definindo o critério de contratação. É possível testar alternativas em áreas não centrais e compensar lacunas de habilidade com aprendizado prático.
• Bibliotecas de componentes: é possível reduzir lock-in e manter a produtividade com design systems independentes de framework e uso de Web Components.
• Estabilidade: o React também está em constante mudança, com hooks, Server Components etc. Em muitos casos, frameworks alternativos oferecem APIs até mais consistentes.
• Necessidade de validação em casos de grande escala: em certo momento, o jQuery também era um caso global de sucesso. O sucesso do passado não garante validade no futuro.

Os danos ao ecossistema e à indústria como um todo

• A monocultura do React desacelera o próprio avanço da web
• Talento e capital ficam concentrados apenas em resolver problemas do React, enquanto a inovação nativa da plataforma é adiada
• Instituições de ensino também ampliam o aprendizado de tecnologias pouco portáveis por causa de currículos voltados à empregabilidade imediata
• O próprio avanço da plataforma web fica bloqueado pela resposta “React basta”, e a falta de diversidade no ecossistema acaba gerando perdas para todos no longo prazo

O ecossistema desejável que podemos construir

• Diversidade é condição essencial para um ecossistema saudável
• A inovação nasce quando vários paradigmas competem e trocam ideias entre si
• Desenvolvedores crescem ao aprender diferentes formas de pensar, e a própria plataforma web evolui graças a esse espírito de experimentação

• Apostar tudo em um único framework cria um ponto único de falha. Quando ele atinge seu limite, o crescimento para e oportunidades melhores desaparecem
• Em cada projeto, a escolha deve ser guiada por restrições técnicas e adequação, sem depender apenas do React como padrão
• Só a diversidade garante inovação de verdade

• Agora é a hora de parar de plantar apenas a mesma “semente” (React) e participar da construção de um ecossistema web mais forte e inovador por meio de experimentos com frameworks mais diversos
• A escolha é nossa