Você deve remover o React em 2026? O playbook de simplificação do frontend para CTOs

React em todo lugar não é uma lei da física. Foi um padrão inteligente para uma década de UX na web, mas isso não significa que seu SaaS precise ser um único app que se hidrata perpetuamente em 2026. A onda recente de equipes arrancando o React em favor de htmx e MPAs renderizadas no servidor não é nostalgia; é uma avaliação sóbria de complexidade e custo. Um post no HN que está circulando detalha uma empresa removendo o React e substituindo‑o por htmx para interatividade. Isso é um alerta para quem paga plantões por bugs de hidratação sem entregar uma UX à altura.

O que mudou desde que todos apostamos em SPA?

• O navegador ficou rápido; seu app ficou limitado pela CPU. Engines modernos e HTTP/2+ tornaram baratas as navegações multi‑página. Seu gargalo real é o parsing de JS, a hidratação e a saturação da thread principal.
• A maior parte da superfície B2B ainda é CRUD. Se 70–80% das suas telas são formulários, tabelas e paginação, uma biblioteca de 14 KB que troca fragmentos de HTML é suficiente. React + react‑dom + router + camada de dados normalmente somam 150–300 KB gzippados antes do seu código.
• Os Core Web Vitals monetizaram a performance. Você sente isso em SEO e nos funis de ativação. Cortar a hidratação é o ganho mais rápido de INP/LCP que resta para muitas equipes.
• Os frameworks de servidor evoluíram. Rails 7 + Hotwire, Django + htmx, Phoenix LiveView, Laravel Livewire, Astro Islands — isso não é 2013. MPA + ilhas seletivas é um caminho de primeira classe.

React é ótimo — até deixar de ser

React continua sendo uma excelente escolha quando seu produto é um canvas colaborativo, pesado em estado (pense no Figma, no editor de blocos do Notion, dashboards profundamente interativos) ou exige garantias offline‑first. Mas para fluxos de entrada de dados, painéis de administração, fluxos de marketing/ciclo de vida do usuário, bases de conhecimento, páginas de configurações, você está pagando um imposto de plataforma permanente por um problema que não tem.

Se você suspeita que está nesse grupo, pare de discutir gosto e rode os números.

O framework de decisão de um CTO: você deve remover o React?

Avalie seu produto em cinco eixos (0–5 cada)

1. Densidade de interatividade. Quantos controles com estado simultâneos por tela? 0 = formulários/tabelas simples, 5 = componentes aninhados e arrastáveis, editores, widgets sincronizados. Limite: se as telas médias tiverem ≤ 2 controles, pontuação ≤ 2.
2. Colaboração em tempo real. Multi‑cursor, presença, resolução de conflitos. 0 = nada, 5 = núcleo do produto. Limite: qualquer ≥ 3 mantém você no mundo SPA para essa superfície.
3. Offline/Sincronização em segundo plano. Precisa funcionar com conectividade instável? 0 = não, 5 = sim, com estado local robusto. Offline ≥ 3 favorece SPA ou nativo.
4. Modelo de navegação. As views são independentes com URLs limpas ou é uma grande cena única? 0 = amigável a MPA, 5 = centrado em SPA com estado de cena compartilhado.
5. Pressão regulatória/SEO. Rastreabilidade, determinismo de renderização e privacidade (sem PII do cliente em JS). 0 = baixa, 5 = alta. Valores altos favorecem SSR/MPA.

Heurística: Se sua média ponderada for ≤ 2,5, você provavelmente entregará mais rápido, cairá menos e terá notas melhores com uma stack de MPA + progressive enhancement. Se ≥ 3,5, mantenha o React onde ele traz alavancagem real. Se estiver no meio, misture: um shell MPA com algumas ilhas de React ou Web Components.

O caso financeiro: o que você para de pagar

• Imposto de bundle e hidratação. htmx tem ~14 KB gzippados. Uma stack típica de React (react + react‑dom + router + query + sua cola) fica em 150–300 KB gzippados. Cortar 200 KB e pular a hidratação rotineiramente rende 15–30% de melhoria em LCP e ganhos notáveis de INP em dispositivos intermediários.
• Bugs de estado e tempo de plantão. Inconsistências de hidratação, caches obsoletos, loops de efeitos — se suas rotações de incidentes conhecem isso de cor, você está financiando uma máquina de Rube Goldberg. Times que migramos de padrões SPA rotineiramente reduzem o volume de incidentes de UI em 20–40% em três meses.
• Arrasto no throughput de desenvolvimento. Entregar um fluxo CRUD em React frequentemente significa escrever o mesmo schema três vezes (servidor, cliente, validador) e encadear estado por camadas de query/mutação. Com SSR + htmx, você renderiza uma vez, melhora progressivamente onde necessário e se apoia em validações e transações de servidor já provadas em batalha.

Arquiteturas que vencem em 2026

1) MPA + htmx (or Turbo) + sprinkles

Mantenha seu framework de servidor no volante. Renderize HTML; troque fragmentos via htmx; adicione pequenos sprinkles com alpine.js ou vanilla para estado local de UI. Seu modelo mental é direto: a URL mapeia para uma ação no servidor que retorna HTML. Progressive enhancement cobre 80% da interatividade sem um runtime completo de estado no cliente.

2) MPA + Islands

Use um framework de islands (Astro, Marko, Qwik) para enviar 90% de HTML e ativar componentes interativos discretos sob demanda. Para widgets complexos — grade de dados com virtualização, editor WYSIWYG — monte uma ilha em React/Vue/Svelte em uma página que, no restante, é renderizada no servidor. Você mantém o React onde ele se paga.

3) LiveView‑style SSR over websockets

Phoenix LiveView e padrões similares permitem que o servidor seja dono do estado enquanto envia diffs para o cliente. Esse modelo brilha em uma ampla gama de ferramentas de back‑office e dashboards com JS mínimo no cliente, limites de segurança fortes e excelente performance.

Riscos e trade‑offs (não finja que não existem)

• Pool de contratação e tração. React tem o maior pool de candidatos e ecossistema. htmx e LiveView são mais simples, mas menos comuns nos currículos. Mitigação: capacite um pod nearshore para semear padrões e parear com seu time central por 8–12 semanas.
• Ecossistema de componentes. Você vai sentir falta de componentes React‑first. Planeje usar Web Components, headless UI, ou construir os poucos widgets de alto valor de que precisa, uma vez, como ilhas.
• Expectativas de roteamento no cliente. Transições de SPA podem parecer mais ágeis. Use pré‑carregamento orientado pelo servidor, alternativas ao push do HTTP/2 e trocas parciais para chegar a 95% da sensação com 5% do código.
• Feature flags e infraestrutura de A/B. Se suas ferramentas de experimentação são JS‑first, você precisará de variantes no servidor e renderização determinística. É positivo no agregado para observabilidade, mas há alguma tubulação inicial a fazer.

Migre sem reescrever a empresa

Reescritas completas falham. Em vez disso, estrangule a SPA.

Fase 0: Instrumente a dor

• Meça hoje. Core Web Vitals por caminho, bytes de JS por rota, taxa de crash, contagem de erros de hidratação, INP p95 em Android intermediário.
• Rotule suas superfícies. Classifique rotas como CRUD, marketing, configurações, editor, dashboard etc. Você não vai migrá‑las igualmente.

Fase 1: Prove em superfícies de baixo risco (2–4 semanas)

• Fluxos de marketing e autenticação. Mova login, signup, reset de senha, verificação de e‑mail para SSR. Eles já se beneficiam de renderização determinística e SEO.
• Configurações e perfis. Substitua estado no cliente por formulários no servidor e trocas de fragmentos com htmx. Espere ganhos imediatos de bundle e menos bugs de casos de borda.
• Meça de novo. Se você não vir melhorias de dois dígitos em LCP/INP e menos incidentes de UI nesses caminhos, pare. Sua SPA pode estar justificada.

Fase 2: Crie um shell renderizado no servidor (4–8 semanas)

• Rota por rota, mova navegação, headers, footers e a maioria das páginas para renderização no servidor. Mantenha seus widgets complexos montados como ilhas React dentro dessas páginas. Isso entrega 80% dos benefícios sem tocar na sua UI mais difícil.
• Adote uma API de fragmentos. Padronize endpoints que retornem HTML parcial para listas, paginação e conteúdo de modais. Eles se tornam seus novos primitivos de UI.
• Validações compartilhadas. Centralize schema e validação no servidor. O cliente faz progressive enhancement, não lógica de negócio.

Fase 3: Decida o destino dos seus widgets complexos (8–16 semanas)

• Mantenha React onde ele se paga. Editores, grades de dados pesadas, colaboração em tempo real: deixe como ilhas. Use hidratação tardia e só envie código onde for necessário.
• Simplifique o que puder. Muitos widgets “complexos” não são valor central. Uma tabela paginável e um formulário em modal podem substituir combinações sob medida de grid + edição inline sem prejudicar a UX.

Governança e gates de performance

• Defina budgets. Budget de JS por rota (ex.: ≤ 50 KB gz para páginas sem ilhas), thresholds de INP p75, budgets de erro para inconsistências de hidratação (alvo: zero em rotas MPA).
• Codeowners e ADRs. Qualquer nova superfície em SPA exige um Architecture Decision Record com justificativa explícita frente aos cinco eixos. O default é MPA + enhancement.

Segurança, privacidade e compliance ficam mais fáceis

• Menos PII no cliente. Renderizar no servidor significa evitar enviar campos sensíveis ao navegador até que seja absolutamente necessário. Isso reduz sua superfície de exposição de dados.
• Menos efeitos colaterais transversais. Nada de caches extensos no cliente e stores globais vazando estado entre tenants ou sessões.
• Auditoria determinística. O que o servidor renderizou é o que o usuário viu. Isso importa para fluxos regulados e preservações legais.

Exemplos reais para calibrar seu instinto

• Basecamp/HEY popularizaram Hotwire/Turbo para sustentar SaaS complexos sem um runtime de SPA, reportando grandes ganhos de performance e redução de complexidade.
• GitHub há muito usa técnicas ao estilo PJAX/Turbo com HTML renderizado no servidor e sprinkles. Ninguém chama o GitHub de lento.
• Times em Django + htmx entregam produtos repletos de administração em semanas, não meses, apoiando‑se em formulários no servidor, transações e UI otimista via trocas de fragmentos.

Não são apps de brinquedo. Eles provam que, se sua proposta de valor é fluxo de trabalho e correção dos dados — não um canvas multiplayer pixel‑perfect — server‑first funciona e escala.

Como operamos isso em um engajamento nearshore

Se você não tem ciclos para travar essa batalha sozinho, semeie com um pod que já entregou esse padrão repetidamente. Nossas equipes baseadas em Brazil trabalham nos seus horários (6–8 horas de sobreposição com o horário dos U.S.) e começam com um piloto de duas sprints em fluxos de baixo risco. Codificamos padrões, construímos sua API de fragmentos e deixamos você com budgets, regras de lint e uma pista de migração. Você mantém o React onde ele pertence; você para de hidratar todo o resto.

FAQ para CTOs céticos

“Investimos em um design system construído em React. Vamos jogá‑lo fora?”

Não. Trate‑o como uma biblioteca de ilhas. Exporte primitivos headless como Web Components onde fizer sentido. A maioria dos tokens visuais, CSS e trabalho de acessibilidade se transfere sem atrito.

“E o cache complexo no cliente e os updates otimistas?”

Coloque a consistência em primeiro lugar: mutações autoritativas no servidor, embrulhadas em transações. Para velocidade percebida, faça streaming de parciais, use cache HTTP agressivamente e aplique UI otimista no punhado de interações que merecem. Você não precisa de um cache global no cliente para uma página de configurações.

“Vamos perder transições rápidas?”

Use prefetch no cliente ao passar o mouse, links boosted do htmx e trocas parciais. A diferença vs SPA é desprezível quando você não exige que um celular intermediário faça parse de 300 KB de JS antes.

“Isso não é só trocar uma complexidade por outra?”

Sim — exceto que a nova complexidade fica mais perto dos seus dados e invariantes, onde você já tem testes, transações e observabilidade. Esse é um lugar melhor para gastar seu orçamento limitado de complexidade.

Uma regra simples que você pode defender para seu CEO

Se uma tela pode ser descrita como “carregar dados, renderizar formulário/tabela, enviar e mostrar resultado”, ela é culpada até prova em contrário de precisar de um runtime de SPA. Use React onde colaboração, offline ou computação pesada no cliente tornem‑no claramente mais barato. No restante, pare de pagar o imposto da hidratação.

Pontos‑chave

• Escolha padrão MPA + progressive enhancement; adicione React como ilha onde ele se paga.
• Pontue cada superfície por densidade de interatividade, colaboração, necessidades offline, modelo de navegação e pressão de SEO/regulatória.
• Espere ganhos de 15–30% em LCP/INP e 20–40% menos incidentes de UI ao desidratar superfícies CRUD.
• Migre estrangulando a SPA: comece por auth, marketing e configurações; depois crie um shell renderizado no servidor; mantenha widgets complexos como ilhas.
• Defina budgets de JS por rota e exija ADRs para quaisquer novas superfícies SPA.
• Segurança e compliance melhoram ao renderizar de forma determinística no servidor com menos PII no cliente.
• Use um pod nearshore experiente para semear padrões, parear com seu time e sair deixando guardrails em 8–12 semanas.