React nunca foi um framework completo — e isso importa mais agora

English summary: React was designed to solve the UI layer, not to define an entire web application. That distinction explains why Vite, Next.js, routers, data libraries, and deployment conventions exist around it. This article separates those responsibilities, shows a minimal runnable React/Vite example, and offers a stack decision framework that accounts for security, ownership, and reversibility.

Published 9 de abril de 2026
Reading time: 16 min
Keywords: React, Vite, Next.js, arquitetura frontend, SSR, SPA, segurança web, decisões de stack

Uma equipe escolhe React para um produto novo e, algumas semanas depois, percebe que ainda precisa decidir roteamento, build, carregamento de dados, cache, renderização, autenticação, observabilidade e deploy. O problema não é ter escolhas. O problema é acreditar que a primeira escolha já definia a aplicação inteira.

Minha tese é simples: React continua sendo uma excelente biblioteca de UI, mas não deve ser tratado automaticamente como um framework completo. Essa fronteira define quem é responsável por cada decisão, quanto da arquitetura precisa ser composto pelo time e quão fácil será mudar de direção depois.

React não ficou menor porque o ecossistema cresceu. O ecossistema cresceu porque React resolveu uma camada importante sem tentar possuir todas as outras.

A diferença não é semântica; é um contrato de responsabilidade

React organiza a composição de interfaces declarativas, componentes e hooks. Ele participa da renderização da UI e oferece primitivas para descrever como a interface reage ao estado.

Isso não significa que React, sozinho, escolha:

• como URLs viram telas;
• onde os dados são buscados e invalidados;
• se uma rota é renderizada no cliente, no servidor ou no build;
• como o JavaScript é dividido e publicado;
• como erros, carregamentos e mutações atravessam a aplicação;
• onde a autenticação e a autorização são executadas;
• quem possui o contrato de deploy e de observabilidade.

Essas responsabilidades podem ser preenchidas por outras ferramentas ou por código próprio. O ponto é não atribuí-las automaticamente ao React. A documentação oficial hoje recomenda começar novos apps com um framework, mas também descreve o caminho “from scratch” para aplicações com restrições específicas ou para quem quer montar sua própria solução.¹

Isso é uma recomendação de contexto, não uma lei arquitetural. Um framework reduz decisões repetitivas; React puro preserva liberdade. Cada benefício cria um tipo diferente de custo.

Quatro falhas recorrentes antes de escolher a solução

Antes de comparar stacks, vale nomear os atalhos que produzem decisões ruins.

1. Tratar “React” como o nome da stack inteira

“Vamos usar React” costuma encerrar a conversa no momento em que ela deveria começar. Ainda faltam decisões sobre roteamento, dados, build, testes, limites entre browser e servidor, identidade visual, acessibilidade, erros e deploy.

O resultado previsível é uma arquitetura que parece simples no primeiro mês e acumula decisões locais incompatíveis no sexto. O time não escolheu liberdade; escolheu responsabilidade sem um contrato explícito.

2. Comparar Vite e Next.js como se fossem concorrentes da mesma camada

Vite é uma ferramenta de desenvolvimento e build. Ele oferece um servidor de desenvolvimento com HMR e produz assets de produção. O próprio guia do Vite descreve esse papel e também mostra que um projeto React continua precisando escolher suas convenções de aplicação.²

Next.js é um framework para aplicações React. Seu App Router define convenções de rotas e integra recursos como Server Components, Suspense e Server Functions.³

Uma comparação honesta pergunta “qual superfície de aplicação eu preciso?” e não “qual marca é mais moderna?”.

3. Colocar segredo no lugar errado

Em uma SPA, o código e os valores enviados ao browser devem ser tratados como públicos. Uma chave com prefixo VITE_ é exposta no bundle pelo Vite; ela serve para configuração não secreta, não para credenciais.⁴

Esconder uma rota no cliente também não é autorização. O browser pode inspecionar o JavaScript e chamar a API diretamente. A autorização precisa ser aplicada no servidor ou no serviço que possui o dado, com uma política que tenha dono e testes.

4. Otimizar a primeira demo e ignorar o custo de saída

Uma escolha pode acelerar a tela inicial e ainda criar um caminho de migração caro. Uma aplicação que depende profundamente de Server Components, Server Actions, middleware e semântica de cache do framework não sai de Next.js como quem troca um bundler. Da mesma forma, uma SPA que espalha window, localStorage e chamadas diretas pelo domínio pode exigir bastante trabalho para ganhar renderização no servidor.

Reversibilidade não significa ausência de acoplamento. Significa saber onde ele está, quem o possui e quanto custa sair antes de precisar sair.

O que React oferece — e o que fica fora do seu contrato

Pensar em camadas evita tanto vender React como plataforma completa quanto subestimá-lo como “apenas uma biblioteca”.

A biblioteca é valiosa justamente por manter o foco. O erro é confundir “não possuir a camada” com “não poder participar dela”. React pode ser usado dentro de uma SPA, de um framework full-stack, de um widget em um sistema legado ou de um design system.

Por que a documentação do React recomenda frameworks

Aplicações públicas atuais frequentemente precisam combinar rotas, dados, renderização, loading, tratamento de erro, otimização de assets e uma estratégia de deploy. Montar tudo isso manualmente pode ser a decisão certa, mas não é uma decisão sem custo.

O guia oficial de criação de apps do React recomenda um framework para um novo app ou website e, ao mesmo tempo, reconhece que algumas restrições justificam começar do zero. Ele inclusive lembra que frameworks full-stack não exigem necessariamente um servidor: podem oferecer CSR, SPA e SSG e ser publicados em CDN, dependendo do caso.¹

A mensagem madura não é “todo mundo deve usar Next.js”. É: se o produto precisa de uma plataforma completa, escolha conscientemente a camada que fornecerá essa plataforma. Se o produto não precisa dela, não invente complexidade para obedecer a uma tendência.

React, Vite e Next.js são camadas diferentes

O mapa abaixo é mais útil que uma disputa de popularidade:

React com Vite

O Vite não é “React com backend embutido”. Ele fornece o ambiente de desenvolvimento e o build. O comando vite build gera um bundle de produção adequado para hospedagem estática; o próprio Vite recomenda consultar a documentação do framework quando a divisão de chunks pertence a uma camada acima.⁵

Essa composição é ótima quando o produto é essencialmente uma SPA autenticada, um painel operacional, um widget incorporado ou um design system. Também funciona para produtos maiores, desde que o time aceite possuir explicitamente as decisões que um framework não está fornecendo.

Next.js

O App Router do Next.js é um roteador baseado em sistema de arquivos e integra recursos recentes do React, incluindo Server Components e Suspense.³ A documentação de fetching também descreve componentes assíncronos no servidor, streaming e estados de loading por segmento de rota.⁶

Isso pode reduzir a quantidade de cola arquitetural em produtos públicos com múltiplas rotas, conteúdo indexável, carregamento progressivo e necessidades de renderização diferentes. Em troca, o time precisa dominar as fronteiras do framework e aceitar que cache, execução e deploy passam a ter semântica própria.

Onde a comparação termina

Vite pode aparecer dentro de outras arquiteturas, e Next.js também possui modos de uso que se comportam como SPA. Portanto, a diferença não é “Vite só faz frontend” contra “Next.js sempre usa servidor”. A diferença é o conjunto de convenções e responsabilidades que cada camada assume por padrão.

Exemplo mínimo executável: uma UI React com Vite

O exemplo abaixo mostra exatamente o que uma escolha React + Vite resolve: uma interface interativa que roda no browser e pode ser construída como assets estáticos. Ele não implementa autenticação, roteamento, persistência, SSR ou autorização.

Requer Node.js compatível com a versão atual do Vite e npm. Crie o projeto e execute:

npm create vite@latest react-boundary-demo -- --template react
cd react-boundary-demo
npm install
npm run dev

Substitua src/App.jsx por:

import { useState } from "react";

export default function App() {
  const [count, setCount] = useState(0);

  return (
    <main>
      <h1>React owns this interface</h1>
      <p>Local UI state is enough for this example.</p>
      <button type="button" onClick={() => setCount((value) => value + 1)}>
        Clicked {count} {count === 1 ? "time" : "times"}
      </button>
    </main>
  );
}

Para verificar o artefato de produção:

npm run build
npm run preview

Esse pequeno app prova que React renderiza e atualiza uma UI. Não prova que a stack está pronta para um produto público. O próximo passo, se a aplicação precisar de rotas, dados ou uma política de erro, é escolher essas camadas deliberadamente — ou adotar um framework que já as componha.

Decisão de stack: escolha pelo custo total

Use a tabela como ponto de partida, não como receita:

Perguntas úteis antes de instalar dependências:

1. O produto precisa de indexação orgânica ou de HTML pronto antes do JavaScript carregar?
2. A maior parte do tráfego é público, autenticado ou incorporado em outro sistema?
3. Onde vivem os dados sensíveis e quem pode autorizar sua leitura e mutação?
4. O time quer reduzir decisões repetitivas ou precisa controlar a composição?
5. Quais requisitos tornam uma futura migração cara: SSR, streaming, server actions, browser APIs, cache ou deploy?
6. Qual owner responderá pelo roteamento, dados, segurança e rollback?

Se as respostas não estiverem claras, ainda não existe uma decisão de stack; existe apenas uma preferência de ferramenta.

Segurança, ownership e reversibilidade

Arquitetura de frontend não é apenas uma escolha de DX. Ela também define superfícies de exposição e responsabilidades operacionais.

Segurança

• Considere todo código enviado ao browser público. Não coloque tokens privados, chaves de banco ou credenciais de serviço no bundle.
• No Vite, trate variáveis VITE_* como configuração pública. Use-as para endpoints, flags não sensíveis e identificadores que já poderiam ser vistos pelo usuário; mantenha segredos fora do cliente.⁴
• Em Next.js, uma fronteira server-side pode impedir que uma dependência ou dado seja enviado ao cliente, mas isso não substitui autorização. O serviço que possui o dado deve verificar identidade, permissões, tenant e escopo de operação.
• Não confunda esconder um botão com impedir uma ação. A API deve rejeitar a operação sem autorização mesmo quando chamada diretamente.
• Trate conteúdo remoto, Markdown e HTML como entrada não confiável. Sanitização, CSP, validação de schema e escaping pertencem ao desenho de segurança da aplicação, não ao slogan da stack.

Ownership

Defina um dono antes do primeiro incidente:

Um framework pode fornecer convenções para várias dessas áreas, mas não pode ser o owner. A responsabilidade continua sendo de uma equipe identificável.

Reversibilidade

Uma decisão é mais reversível quando o acoplamento fica concentrado em adaptadores claros:

• mantenha regras de domínio fora de componentes de rota;
• encapsule acesso a dados atrás de funções ou módulos testáveis;
• evite espalhar variáveis específicas do bundler por todo o domínio;
• trate URLs e contratos de API como interfaces versionadas;
• mantenha testes que expressem comportamento, não apenas a estrutura de pastas;
• registre quais recursos dependem do runtime do framework.

Mover uma SPA React + Vite para Next.js pode ser administrável quando componentes são puros e rotas/dados estão isolados. Pode ser caro quando a aplicação depende de APIs do browser em toda parte. Fazer o caminho inverso é especialmente custoso se SSR, Server Components, Server Actions, middleware e cache fazem parte do produto, não apenas do tooling.

O objetivo não é evitar todo lock-in. É transformar o lock-in em uma decisão visível, com owner, testes e custo de saída conhecido.

Falhas comuns depois que a stack foi escolhida

Mesmo uma escolha correta pode ser operada de forma incorreta.

“O framework cuida da segurança”

Framework pode organizar execução server-side, cookies e headers, mas não conhece a política de negócio. Autorização deve ser verificada perto do recurso protegido e testada com casos permitidos e negados.

“Se o build passou, a aplicação está pronta”

Build prova que uma etapa de transformação terminou. Não prova deep links, cache, autorização, hidratação, observabilidade ou comportamento em produção. No Vite, vite preview é para pré-visualização local e não deve ser tratado como servidor de produção.⁷

“Mais convenção sempre é melhor”

Convenção reduz variação, mas também cria uma superfície de aprendizado e acoplamento. Um framework é bom quando suas convenções removem decisões que o produto realmente precisa tomar, não quando apenas adicionam pastas.

“Mais liberdade sempre é mais simples”

Liberdade no início pode se tornar uma coleção de decisões irreversíveis. Se o time escolhe React + Vite, escreva desde o primeiro dia o contrato de rotas, dados, auth, erros, variáveis e deploy.

Checklist operacional

Antes de aprovar a stack:

• A equipe consegue dizer em uma frase o que React resolve neste produto.
• Roteamento, dados, cache, renderização e build têm owners definidos.
• A decisão entre SPA, SSR, SSG ou streaming está ligada a um requisito real.
• Vite está sendo tratado como build/dev tool, não como backend ou camada de autorização.
• A aplicação não depende de segredo no bundle do cliente.
• APIs rejeitam chamadas sem autorização mesmo quando o cliente é manipulado.
• A política de loading, erro e retry foi testada nas rotas críticas.
• Deep links e refresh direto funcionam no ambiente de deploy escolhido.
• O time registrou quais recursos criam acoplamento ao framework.
• Existe um plano de rollback e uma hipótese de migração, mesmo que a migração nunca aconteça.
• O custo operacional da escolha foi aceito por um owner identificável.

FAQ

React puro está ultrapassado?

Não. Ele continua adequado para componentes reutilizáveis, widgets, design systems, SPAs internas e produtos cujas restrições justificam uma composição própria.

Todo projeto novo com React deve usar Next.js?

Não. A recomendação oficial do React é começar com um framework, não necessariamente com Next.js. React Router e outras opções também aparecem na documentação; Vite pode ser o build tool de uma aplicação deliberadamente composta.¹

Vite substitui Next.js?

Não como regra. Vite resolve principalmente desenvolvimento e build. Next.js fornece uma moldura de aplicação. Eles podem participar de decisões relacionadas, mas não são equivalentes.

Usar Next.js significa deixar de usar React?

Não. Significa usar React dentro de um framework que assume mais responsabilidades de aplicação.

A melhor stack é a mais leve?

A melhor stack é a que mantém o custo total adequado ao produto. Menos dependências pode significar mais decisões próprias; mais convenções pode significar mais acoplamento. Meça ambos.

Conclusão

React nunca foi um framework completo, e isso não é um defeito a ser corrigido. É a decisão de escopo que permitiu que a biblioteca fosse usada em interfaces isoladas, SPAs, design systems e frameworks de aplicação muito diferentes.

O erro é transformar essa flexibilidade em negação de responsabilidade. Ao escolher React, o time ainda precisa escolher — ou delegar conscientemente — roteamento, dados, renderização, segurança, build, operação e estratégia de saída.

Use React + Vite quando a simplicidade de uma SPA, widget ou build estático for uma vantagem real e o time aceitar possuir as camadas restantes. Use Next.js ou outro framework React quando o produto se beneficia de uma plataforma integrada para rotas, renderização, dados e loading. Em ambos os casos, mantenha as fronteiras de segurança e ownership explícitas.

React resolve muito bem a interface. A aplicação inteira é outra decisão.

Fontes oficiais atuais

Consultadas em 12 de agosto de 2026:

• React — Creating a React App: recomendação de frameworks e opção de começar do zero.
• React — Reference Overview: escopo das APIs de React e React DOM.
• Vite — Getting Started: papel do Vite como dev server, HMR e build tool.
• Vite — Building for Production: produção de assets estáticos e configuração de build.
• Vite — Env Variables and Modes: exposição de variáveis prefixadas e modos de build.
• Vite — Command Line Interface: comandos de dev, build e preview.
• Next.js — App Router: roteamento baseado em arquivos e recursos atuais do React.
• Next.js — Fetching Data: fetching server-side, streaming e estados de loading.