Você não precisa de Next.js: escolha a stack certa para o projeto

Você não pediu Next.js. A IA entregou mesmo assim.

Alguns dias depois daquele primeiro “está pronto”, você pede uma mudança pequena. Aparece um erro. Manda a inteligência artificial corrigir. Ela atualiza uma biblioteca; outra para de funcionar. Muda uma configuração; a página roda no computador e, na hora do deploy, não carrega. Você corrige uma coisa e quebra outra. É nesse momento que descobre: não criou um site. Adotou uma criatura que precisa ser alimentada, atualizada e vigiada o tempo inteiro.

Para quem começa, alimentar essa criatura não é detalhe de gosto. Antes de eu explicar o motivo, vale separar o que um site de verdade é — porque o Next.js só faz sentido se você souber em cima de quê ele foi empilhado.

HTML, CSS, JavaScript — e o que o React tentou facilitar

Um site é HTML (o documento: texto, tags, estrutura), CSS (onde fica cada coisa, cor, linha, espaço) e JavaScript (o que dá vida: animação, formulário, comportamento). São, na prática, as únicas coisas que o navegador lê e interpreta. Esses arquivos podem ir estáticos, já prontos, ou nascer na hora por uma linguagem no servidor — o caso clássico do PHP.

Em 2013 o Facebook criou o React. Sim: a Meta, a mesma casa daqueles aplicativos terríveis, bugados e mal otimizados — o WhatsApp do desktop entra na piada. O React é uma biblioteca para montar interface complexa. Em vez de escrever a página inteira num arquivo só, você parte em peças: um botão é um componente, o menu é outro, o card do produto é outro. Isso funciona bem quando há muitas telas mudando, interação, coisa reativa.

O React sozinho não entregava o site. Ainda faltava criar página, organizar rota, carregar dado. Em 2016 surgiu o Next.js: um framework que compilava aquilo e empacotava o resto em volta do React. Na época, resolvia um problema real. O que muita gente ainda não atualizou na cabeça é que o JavaScript do Node, e o dos navegadores, incorporou boa parte desses recursos. A necessidade de um framework só para ter página, módulo e busca de dado diminuiu. A fama, não.

Por que o Next.js virou a resposta padrão da internet

O Next.js facilitava criar página, renderizar no servidor, organizar o projeto React. O React antigo entregava SPA: o HTML chegava vazio no navegador e o conteúdo só nascia depois, no cliente. Isso era péssimo para quem precisava do texto no primeiro carregamento — crawler, compartilhamento, leitura sem esperar o JavaScript. O Next.js chegou com a fama de devolver o HTML já montado. Cresceu por isso.

No mesmo pacote vinham renderização no cliente, geração estática, divisão de código, carregamento de dado e até recurso de backend. Uma das maiores empresas de hospedagem serverless, a Vercel, tornou fácil publicar site em Next.js. As duas cresceram juntas. Pertencem, na prática, a um mesmo desenho: a Vercel cria o Next. Tutoriais passaram a usar Next.js. Curso passou a ensinar Next.js. Template nasceu em Next.js. A inteligência artificial treinou nisso e passou a devolver Next.js como resposta comum para “cria um site”. Ela gera o projeto. Gerar não é o mesmo que você conseguir manter.

Tecnologia popular não é, automaticamente, a melhor opção nem a necessária. Esse é um dos maiores perigos do vibe coding. Se você não escolhe a stack, se não fala para a ferramenta deixar de puxar dependência, ela pega o caminho mais fácil — o que abre no localhost e te dá dor de cabeça daqui a dois anos. Ela é boa em fazer uma coisa funcionar. Manutenção, atualização, o peso de cada pacote: isso ela não sente. Ela pensa em entregar a resposta. Não pensa em você.

O erro pode estar em qualquer andar da torre

Mesmo quando a correção “funciona”, fica a pergunta: será que não escapou uma vulnerabilidade, um errinho? JavaScript para dashboard e admin, no meu juízo, já começa ruim — é terreno vulnerável e depende demais da sua manutenção. Aí a IA lê o erro e tenta mexer em alguma coisa. O maior problema do Next.js não é um arquivo específico. É a quantidade de andares entre o seu botão e a falha.

Além do seu código, tem o React, o próprio Next.js, as bibliotecas instaladas, o sistema do projeto, o ambiente de execução e a plataforma de publicação, com os Nodes e as libs que sobem na hora do deploy. Quando quebra, você ainda precisa descobrir em qual dessas camadas quebrou. Um botão que não clica deixa de ser “abre o arquivo do botão”. Vira hidratação, cache, configuração escondida, versão de pacote, runtime da Vercel, React, Next, ou a lib que a IA atualizou ontem para calar um aviso.

• O código que você (ou a IA) escreveu
• React
• Next.js
• Bibliotecas e o package.json que ninguém revisou linha a linha
• Ferramenta de build e convenção de pastas do framework
• Ambiente de execução (Node, edge, o que a plataforma decidir)
• A própria hospedagem, com as libs que ela carrega no deploy

Dezesseis versões maiores em menos de dez anos

O outro problema grande: o Next.js muda o tempo todo. Lançado em 2016, em menos de dez anos já estava na versão maior 16. Na data desta gravação isso já era fato; o Next.js 16 saiu em 21 de outubro de 2025. Elixir, que é mais velho, ainda não saiu da versão maior 1 — em junho de 2026 foi ao 1.20 e continuou 1.x. Recebeu dezenas, centenas de atualizações e funções novas. O número da frente não andou. Quem fez um site em Next 1 teve que atravessar dezenas de majors para o projeto não quebrar. Quem fez em Elixir há treze anos ainda roda, porque atualização frequente não é a mesma coisa que quebra de contrato.

Versão tem maior, menor e patch. Patch é correção; em geral você não mexe em nada. Menor às vezes quebra uma coisinha, é raro. Maior, com certeza, muda alguma coisa drástica e te manda revisar código durante dias. Toda semana tem atualização no Next. Com frequência, atualização maior. Programador experiente foge disso porque já conhece a conta. Agora imagine quem começou a codar com IA.

Quando você escolhe Next.js, não escolhe só uma ferramenta. Escolhe acompanhar o Next, o React e as bibliotecas que dependem dos dois. É uma obrigação de manutenção, não uma linguagem. Até o WordPress, em PHP, com os milhões de arquivos e os plugins que atualizam o tempo todo, costuma ser mais fácil de gerir do que um Next.js da vida. Aquilo raramente te dá a mesma dor de cabeça de major em major.

A web de 2016 não é a de agora — e vanilla não é amadorismo

Muitos problemas que o Next.js ajudou a resolver foram comidos pela evolução do próprio JavaScript e dos navegadores. Hoje o JavaScript tem módulo nativo. Você divide o projeto em vários arquivos, usa import e export, tem um arquivo para produto, outro para pesquisa, outro para formulário, outro para interface — sem Next e sem React. Tem fetch. Tem async e await. Tem API, parâmetro, localStorage, IndexedDB. O JavaScript nativo já cobre função, módulo e organização de peça. Você não depende de biblioteca nenhuma para o site existir.

Quanto menos camada, mais fácil entender e corrigir — para você e para a inteligência artificial. Botão não funciona: olha o código do botão. Request falha: olha a request. Não precisa navegar em node_modules atrás do que aconteceu. Existe ferramenta de sobra para atualizar, corrigir e caçar vulnerabilidade no Next e no React. Ainda assim é dor de cabeça. Quanto mais você se centraliza no que o navegador já faz, menos você precisa descobrir se o problema está no React, no Next, no servidor, no navegador, na hidratação, no cache, na lib ou numa configuração que ninguém documentou.

Quando o site é JavaScript ou TypeScript puro, a gente chama de vanilla. Isso não é código amador nem bagunça. Dá para otimizar e organizar do jeito que você quer — e essa é a vantagem. Você estrutura na sua cabeça, não na de alguém que, anos atrás, decidiu uma torre de pastas: “vamos colocar isso aqui, adicionar aquilo que você nunca vai usar, e mais esta pasta”. Vira torre de Babel. Esse é o grande problema do Next.js: a estrutura chega antes da necessidade.

Vue, Nuxt, Vite, Astro, Hono — e o que vira JavaScript no final

Mesmo que você não queira vanilla, existem framework, biblioteca e build que facilitam site moderno em TypeScript ou JavaScript sem o Next.js como primeira opção. Para o lugar do React, Vue. Para o lugar do Next.js, Nuxt. Se você nem quer framework, um bundler como o Vite segura o desenvolvimento em arquivos comuns. Blog ou portal: Astro. API, site um pouco mais completo, Cloudflare Workers: Hono. É o que eu uso nas minhas stacks — Hono, às vezes um pouco de Vue, e Astro. O Hono é pequeno, leve, trabalha perto dos padrões da web e ainda cuida de rota, autenticação e consulta a banco, sem a frescura de Next.js no front.

Aplicação com muitas telas, formulário, informação mudando o tempo inteiro, dashboard, SaaS: primeiro, eu nem recomendo JavaScript para isso. Como eu já falei, a linguagem é vulnerável e a manutenção fica na sua conta. Existem linguagens melhores se o foco for backend e área de membros. Se ainda quiser insistir no JavaScript, aí a hospedagem barata e boa que eu indico é a Cloudflare. Proteja o backend e o admin com Cloudflare Access. Faça o site público o mais chão possível.

Se a interface realmente pede componente e lógica mais avançada, Vue, Svelte e Astro existem. No final, tudo isso vira JavaScript. O framework entrega uma estrutura para você trabalhar. Na hora de publicar, a pergunta volta: será que vai criar muita lib, muita dependência? Você está preparado para alimentar essa criatura? Quando uma coisa é famosa demais, em geral ela é a mais problemática — não a melhor.

1. Escreva o que a primeira versão faz de verdade: página institucional, blog, formulário, API ou painel com dezenas de telas.
2. Comece com HTML, CSS e JavaScript (ou TypeScript) em arquivos que o navegador lê. Sem Next.js, sem React, sem “já deixa o template”.
3. Se o projeto tiver vários arquivos e você quiser um servidor de desenvolvimento, acrescente um bundler como o Vite — não um framework de aplicação.
4. Blog ou portal: olhe o Astro. API e site na Cloudflare: Hono. Muitas telas reativas: Vue ou Svelte. Nuxt só se você realmente quer o desenho “meta-framework em cima do Vue”, não porque é o primo do Next.
5. Painel e admin: coloque atrás do Cloudflare Access. Não deixe a ferramenta inventar login no mesmo saco do site público.
6. Antes do deploy, abra o package.json. Se a lista cresceu sem você ter pedido cada pacote, volte atrás e corte camada.

Não siga a manada: Vercel, Supabase e a moda do mês

Enquanto muitos recomendam a Vercel, eu recomendo a Cloudflare. Enquanto muitos recomendam o Supabase, eu recomendo o SQLite, o D1. Enquanto a maioria ama o Claude Code, eu estou usando Codex. Não seja enganado pela manada. Pare de seguir modinha que muitas vezes só é falada porque envolve dinheiro.

Se você trabalha sozinho, evite Next.js — para você e para o cliente. Menos trabalho, menos dor de cabeça, menos tempo perdido em major release. Se quer um site moderno, limpo, fácil de gerir e fácil de codar: vem para a Cloudflare, usa D1, usa Hono. A stack cabe na cabeça. Quando quebra, você sabe em qual arquivo olhar.

Na sequência

1. Recuse o Next.js automático: peça HTML, CSS e JavaScript, a menos que a interface realmente precise de componente.
2. Conte as camadas do projeto: seu código, React, Next, libs, runtime, plataforma. Cada andar extra é um lugar para o erro se esconder.
3. Trate package.json inchado como cheiro ruim, não como sinal de site “profissional”.
4. Blog ou portal → Astro. API e Workers → Hono. Muitas telas → Vue ou Svelte. Build sem framework → Vite.
5. Admin e dashboard atrás de Cloudflare Access, separados do site público.
6. Banco: SQLite ou D1 antes de puxar Supabase. Hospedagem: Cloudflare antes de Vercel, se você não está casado com Next.
7. Lembre que major do Next quebra contrato; patch não. Elixir ainda está no 1.x — isso não é atraso, é disciplina.

Onde isso quebra