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.[^react-app]

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.[^vite-guide]

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.[^next-app]

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.[^vite-env]

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.[^react-app]

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.[^vite-build]

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.[^next-app] A documentação de fetching também descreve componentes assíncronos no servidor, streaming e estados de loading por segmento de rota.[^next-data]

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.