O declínio do React: vulnerabilidades, complexidade e o êxodo de seniores

No dia 29 de novembro, o pesquisador Lachlan Davidson reportou uma vulnerabilidade de segurança altamente crítica no ecossistema do desenvolvimento web moderno, registrada sob o identificador CVE-2025-55182 e classificada com a pontuação máxima de gravidade de CVSS 10.0. Essa falha de segurança catastrófica permite a execução remota de código (RCE) sem qualquer necessidade de autenticação no ecossistema de React Server Components (RSC). Em mercados competitivos como o brasileiro, onde a arquitetura de software de grandes portais e sistemas de e-commerce depende quase integralmente dessa biblioteca, a revelação acendeu um sinal de alerta vermelho sobre os riscos de se delegar funções de infraestrutura de servidores a motores de renderização baseados em JavaScript de alta complexidade.

A crise de segurança se aprofundou na mesma semana quando a Vercel divulgou uma vulnerabilidade crítica de segurança diretamente associada ao seu framework principal, o Next.js. A forma como a empresa lidou com a divulgação do problema foi classificada por especialistas do setor como insensível, negligente e desrespeitosa com os princípios da comunidade de software livre, agravando temores antigos sobre a governança de projetos de código aberto geridos por interesses privados corporativos. Com o lançamento do Next.js 15.1+, diversos desenvolvedores seniores passaram a alertar publicamente que o ecossistema se transformou em uma armadilha de aprisionamento tecnológico (vendor lock-in) altamente acoplada à infraestrutura de nuvem paga da própria Vercel, tornando-se praticamente inutilizável fora dela.

O cenário reacendeu debates intensos sobre a hegemonia técnica do React, uma tecnologia originalmente desenvolvida para resolver as necessidades específicas de escala interna do Facebook em 2013, mas que acabou se tornando uma escolha padronizada e automática para qualquer novo projeto de software, independentemente do escopo real. Essa dependência reflexiva cria um ciclo vicioso que se alimenta da escassez de discussões sobre alternativas nas reuniões de planejamento de engenharia, onde as decisões são pautadas pelo efeito de rede (“vamos usar porque todo mundo já conhece”) em detrimento de uma análise criteriosa de arquitetura. O resultado é o surgimento de aplicações pesadas com uso massivo de JavaScript que exigem manutenção contínua e complexa, acumulando débitos técnicos crônicos de longo prazo.

Vulnerabilidades e governança centralizada

A descoberta do CVE-2025-55182 de nível CVSS 10.0 por Lachlan Davidson é um sintoma claro da crescente complexidade técnica inserida no núcleo do desenvolvimento frontend moderno. Ao migrar a computação para o lado do servidor por meio do React Server Components, a superfície de ataque do ambiente cliente-servidor expandiu-se de forma perigosa. O perigo de uma vulnerabilidade de execução remota de código não autenticada significa que qualquer agente malicioso na internet pode injetar e rodar códigos arbitrários diretamente nas máquinas servidoras que processam a interface, expondo dados de usuários e quebrando o perímetro de segurança corporativa em segundos.

Esse risco é amplificado pelo comportamento da Vercel na gestão de falhas de segurança em suas plataformas derivadas, como ocorreu na revelação recente envolvendo o framework Next.js. Críticos apontam que o modelo de governança da empresa prioriza a proteção de sua infraestrutura comercial de nuvem sobre a transparência devida aos desenvolvedores independentes que utilizam a ferramenta. A versão Next.js 15.1+ exemplifica essa fricção: ao desenhar APIs que performam de maneira ideal apenas quando hospedadas na própria infraestrutura da Vercel, o projeto afasta-se de seu propósito original de utilitário web neutro e impõe barreiras de custos que pesam no orçamento de pequenas e médias empresas brasileiras.

A crítica ao modelo de governança atinge também o fenômeno apelidado na comunidade de Frameworkism (ou “frameworkismo”). Essa tendência prega que qualquer problema de experiência do usuário ou de gargalo em aplicações deve ser mitigado pela adoção de mais ferramentas, pacotes e camadas provenientes do ecossistema do próprio framework, em vez de recorrer a padrões consolidados do desenvolvimento web. Para os praticantes desse modelo, soluções para problemas de usuários fora do universo cinematográfico estendido do React simplesmente não existem, resultando em um trabalho que simula engenharia de software real, mas que na verdade se resume a gerenciar infinitos pacotes e dependências de terceiros.

O calvário da hidratação redundante

A arquitetura padrão promovida pelas ferramentas modernas do ecossistema do React apoia-se no problemático padrão de hidratação (hydration pattern). Esse fluxo de trabalho inicia-se executando toda a computação lógica no servidor utilizando JavaScript, gerando e servindo a marcação HTML estática de forma imediata para o cliente — o que, teoricamente, aceleraria a primeira renderização da página. No entanto, o navegador do usuário é obrigado logo em seguida a baixar, analisar e executar exatamente o mesmo bloco redundante de arquivos JavaScript que já rodou no servidor, apenas para vincular novamente os manipuladores de eventos à árvore visual existente.

By default, you get the dreaded hydration pattern—do all the computing on the server in JavaScript, serve up HTML straight away …and then serve up all the same JavaScript that’s on the server anyway.

Esse fluxo focado em bibliotecas pesadas de JavaScript mostra-se incompatível com metas de desempenho de longo prazo para qualquer projeto de tamanho considerável. Na prática diária do mercado, produtos construídos sob essa arquitetura mostram-se invariavelmente mais lentos do que o prometido em apresentações comerciais, deterioram-se em velocidade à medida que novos recursos são codificados e exigem uma quantidade desproporcional de esforço para desenvolvimento, manutenção preventiva e depuração de bugs simples. O acúmulo de arquivos estáticos gigantescos prejudica diretamente a experiência de usuários de dispositivos móveis que dependem de conexões de internet instáveis ou de franquias de dados móveis limitadas.

A estratégia mobile do React também é criticada por forçar as equipes de tecnologia a se submeterem ao aprisionamento de plataformas nativas de lojas de aplicativos. Em vez de abraçar o potencial da web aberta — que oferece distribuição direta, livre de intermediários oficiais e isenta de taxas de distribuição —, o ecossistema empurra as corporações para o desenvolvimento híbrido proprietário. Essa arquitetura centralizada sabota a inovação técnica, onde o acesso equitativo a serviços digitais de qualidade depende da eficiência do tráfego de dados e da leveza dos códigos enviados aos terminais dos usuários.

Como alternativa a essa engrenagem complexa, defensores de uma arquitetura limpa apontam para o poder da simplicidade do HTML puro. Uma estrutura de dados de base baseada em marcação limpa que recebe aprimoramento progressivo (progressive enhancement) apenas quando o JavaScript está disponível oferece benefícios claros: garante que o usuário obtenha uma interface usável de forma rápida, previne que o carregamento do site falhe em conexões móveis lentas, e assegura que os fluxos fundamentais de navegação permaneçam funcionais mesmo quando ocorrem erros críticos de execução de script no navegador. Para satirizar o inchaço dessa pilha tecnológica, desenvolvedores criaram tutoriais de como criar componentes em apenas uma linha, bastando arrastar o diretório node_modules diretamente para a lixeira do sistema operacional.

Migrações bem-sucedidas para alternativas

A insatisfação com as promessas não cumpridas de performance levou grandes players do mercado global a abandonarem a biblioteca. O time de desenvolvimento do navegador Microsoft Edge realizou uma migração histórica ao remover o React de sua interface de usuário interna, substituindo-o por uma arquitetura focada em Web Components integrados a um design focado primeiramente em marcação HTML de baixo nível. A mudança resultou em benefícios consideráveis na responsividade do software para os usuários finais, especialmente em dispositivos de especificações técnicas modestas e com restrições severas de hardware.

Histórias semelhantes de reformulações de código começam a se espalhar por startups e grandes empresas ao redor do mundo. Uma equipe de engenheiros registrou o processo de reconstrução completa de uma aplicação web inteira em seu artigo detalhando que reescreveu o aplicativo para o framework Svelte em apenas três semanas. Ignorado inicialmente por muitos engenheiros como apenas mais um ruído passageiro, o Svelte provou-se uma alternativa leve e de compilação extremamente eficiente, reduzindo as barreiras de desenvolvimento e eliminando as dores de cabeça causadas pela renderização desnecessária de componentes na árvore de visualização virtual.

Outro relato marcante de transição tecnológica detalha a substituição completa de um aplicativo de página única (React SPA) pela tecnologia do framework Liveview. Motivada por severos gargalos de desempenho que inviabilizavam a experiência dos clientes, a empresa conduziu um teste conceitual rápido de dois dias de exploração e, em poucas semanas, concluiu a substituição de todo o frontend legado por páginas dinâmicas renderizadas nativamente no servidor. O movimento reduziu a complexidade de manter estados de dados sincronizados artificialmente entre o cliente e o servidor por meio de requisições de API lentas.

A busca por eficiência também tem motivado equipes a abandonarem de vez a abstração do Virtual DOM (VDOM). Ao migrar diretamente para as APIs nativas do DOM modernas do navegador, um time de engenharia relatou ganhos imediatos na velocidade de inicialização e na latência de interação de suas aplicações. A simplificação da infraestrutura de código — com a eliminação do empacotamento agressivo de scripts exigido anteriormente — provou que os navegadores contemporâneos possuem mecanismos internos poderosos o suficiente para gerenciar atualizações de tela dinâmicas sem a necessidade de uma camada intermediária de biblioteca complexa de terceiros.

A frustração de engenheiros seniores

Nos bastidores de empresas de tecnologia, diretores de tecnologia (CTOs) estão discretamente movendo seus projetos para fora da órbita do React. Vários desses líderes relatam um problema crônico na contratação de profissionais: embora o mercado esteja inundado com desenvolvedores que listam a tecnologia em seus currículos, programadores verdadeiramente qualificados que compreendem as nuances profundas e os padrões avançados de arquitetura de software tornaram-se caros e raros. Com isso, engenheiros de software seniores e experientes, frustrados por passarem a maior parte de suas rotinas gerenciando a complexidade acentuada da biblioteca, abandonam as equipes em busca de posições que utilizem pilhas de tecnologias mais limpas e funcionais.

React has become a bloated carcass of false promises, misleading claims, and unending layers of backwards compatibility – the wrong kind of backwards compatibility, as they still occasionally break your fucking code when updating.

Essa crise silenciosa de qualidade do ecossistema é sistematicamente ocultada por grandes eventos corporativos do setor de tecnologia, como a conferência global React Summit. Conforme revelado por relatórios de consultorias de engenharia independentes, os dados empíricos demonstram que as bases de código mantidas pela comunidade enfrentam um cenário crítico de bugs recorrentes de performance e arquitetura, uma realidade que os palestrantes desses grandes eventos corporativos preferem mascarar por meio de discursos motivacionais ou lançamento de novas ferramentas superficiais. O resultado é um abismo entre o marketing técnico exibido nos palcos das conferências e o caos enfrentado diariamente pelos desenvolvedores em produção.

A tentativa de justificar esses problemas persistentes de lentidão como uma mera falha de habilidade (ou “skill issue”) por parte dos programadores também tem sido duramente questionada por especialistas seniores do setor. Essa atitude arrogante desconsidera que a biblioteca perdeu a consistência em suas atualizações. Em ecossistemas estáveis de desenvolvimento, espera-se que um profissional consiga retornar a um projeto de software após um intervalo de três anos e consiga realizar melhorias sem precisar reconstruir toda a estrutura do projeto; no desenvolvimento web baseado no ecossistema do React, contudo, as dependências tornam-se obsoletas e as APIs internas mudam de forma tão abrupta que essa premissa torna-se um sonho ingênuo.

Problemas técnicos com a API

Os desafios de se trabalhar com o React vão muito além das falhas de arquitetura e segurança, estendendo-se a bugs técnicos básicos presentes em suas APIs de renderização diárias. Detalhes simples de acessibilidade e semântica web que funcionam nativamente há décadas mostram-se problemáticos sob as regras da biblioteca: a propriedade padrão de foco automático (autofocus) quebra frequentemente durante ciclos de re-renderização, elementos customizados nativos do navegador (custom elements) não são suportados de maneira estável fora das versões experimentais e o uso de recursos de interface modernos do HTML5, como as tags nativas dialog e componentes de popover, exige a criação de ganchos de efeito colateral complexos (useEffect) para funcionar adequadamente.

O próprio sistema de eventos sintéticos (synthetic event system) construído no núcleo do React é apontado como uma abstração problemática. Esse mecanismo artificial intercepta as interações nativas do navegador e tenta traduzi-las para um modelo interno próprio que, além de consumir recursos extras de memória e processamento do dispositivo do cliente, ensina muito pouco aos novos desenvolvedores sobre o funcionamento real do Modelo de Objeto de Documento (DOM). Essa dissociação da realidade do navegador cria uma geração inteira de programadores dependentes de ganchos reativos que desconhecem os fundamentos mais básicos do desenvolvimento web padrão.

A substituição da lógica de fluxo de dados pelas estruturas de ganchos do React, como o controverso mecanismo de React Hooks, gerou problemas de legibilidade e otimização em larga escala. Os ganchos de estado interno e de gerenciamento de efeitos colaterais são notoriamente difíceis de programar corretamente e ainda mais desafiadores de otimizar para evitar ciclos de renderização desnecessários que travam a aplicação do usuário final. Esse modelo arrastou milhares de aplicações para um estado crônico de má qualidade de escrita de código e engasgos de interface, um problema que abordagens modernas baseadas em Signals conseguem contornar sem impor regras de renderização bizarras aos desenvolvedores.

A instabilidade de seu ciclo de atualizações é evidenciada pelo imenso vácuo temporal entre os lançamentos oficiais de versões estáveis da biblioteca. Em determinados períodos históricos do ecossistema, os programadores enfrentaram janelas de até um ano e meio sem qualquer atualização de versão estável por parte do time principal de engenharia do projeto. Essa lentidão na correção de problemas crônicos contrasta drasticamente com a velocidade frenética com que o mercado lança pacotes experimentais paralelos, deixando as empresas sem um direcionamento técnico claro de longo prazo para guiar a manutenção de seus sistemas críticos.

O recuo do React 19

O anúncio recente do planejamento do React 19 escancarou o desgaste das discussões internas de engenharia da comunidade. A nova versão esteve prestes a implementar uma série de modificações na mecânica interna de renderização de componentes que, conforme apontado por analistas técnicos independentes, causaria o efeito colateral de desacelerar o carregamento de uma grande parte dos portais e serviços digitais da internet global. Após uma enxurrada de críticas públicas severas por parte de arquitetos experientes e debates acalorados nos fóruns de discussão especializados, o time de engenharia recuou na decisão de lançar a mudança prejudicial.

Esse recuo do React 19 ilustra por que o ecossistema tem sido descrito de forma ácida por engenheiros calejados como um projeto de desenvolvimento que parece seguir suas próprias regras sem ouvir as necessidades do mercado corporativo. Diante dessa realidade de retrabalho constante e desperdício de horas de engenharia valiosas, lideranças técnicas seniores estão incentivando seus pares a se posicionarem de forma firme e vocal contra novas propostas de refatoração para a biblioteca em reuniões internas de planejamento de arquitetura, evitando a criação de novos projetos de desenvolvimento problemáticos apelidados jocosamente de YAJSD (acrônimo para *Yet Another JavaScript Disaster*).

Para os profissionais de desenvolvimento de software que estão iniciando suas carreiras no mercado web de tecnologia, o abandono voluntário do aprendizado do React surge como um caminho alternativo viável a ser considerado de forma realista. Embora a decisão de evitar a tecnologia dominante possa representar uma diminuição temporária nas oportunidades de emprego de curto prazo nas plataformas tradicionais de recrutamento, essa especialização fora do ecossistema fechado pode atuar como um diferencial competitivo de alto valor, facilitando a colocação profissional em corporações inovadoras e focadas em eficiência real que valorizam o domínio sólido de fundamentos web e arquiteturas modernas baseadas em padrões nativos ou alternativas eficientes como Svelte ou Liveview.