O que é Next.js? Um guia simples para quem cria apps

Next.js é um framework para criar sites e apps web com React. O React oferece os blocos de construção de uma interface — botões, formulários, listas. O Next.js acrescenta o resto do site em volta deles: páginas e URLs, renderização das páginas no servidor para que cheguem prontas para leitura, carregamento de dados e execução de código de backend no mesmo projeto. É um projeto de código aberto, criado pela empresa Vercel, e uma das formas mais usadas para construir sites em React.

Por que o Next.js importa quando você cria apps com IA

Quando você descreve um app para uma ferramenta de IA, ela precisa escolher uma base técnica. Essa escolha molda coisas que você vai se importar depois:

• Visibilidade em buscas. Um site público que precisa aparecer no Google se beneficia de enviar HTML real, o que o Next.js faz bem.
• Onde fica o backend. O Next.js permite que as páginas do frontend e o código de servidor (como “salvar este formulário” ou “chamar a API de pagamento”) vivam em um único projeto.
• Hospedagem. Um app Next.js com recursos de servidor precisa de um servidor onde rodar, enquanto um app Vite simples pode ser servido como arquivos estáticos.

O Mythex começa novos projetos com Vite + React + TypeScript + Tailwind por padrão, e usa Next.js quando você pede — basta “Use Next.js” no seu primeiro prompt (como a tecnologia é escolhida). Por isso, vale saber quando essa escolha compensa.

Uma analogia do dia a dia

Se o React é uma caixa de peças de Lego de alta qualidade, o Next.js é um conjunto de Lego que já vem com as instruções, a base e as peças das portas e da hidráulica.

Você poderia construir a mesma casa com peças soltas — só teria de decidir sozinho como os cômodos se conectam, onde fica a porta da frente e como a água chega. O Next.js toma essas decisões por você de forma padronizada, então todo projeto Next.js tem um layout parecido, e um novo desenvolvedor (ou uma IA) consegue se orientar rapidamente.

O que o Next.js acrescenta ao React

O Next.js tem duas formas de organizar as páginas. O App Router (a pasta app/) é o mais novo e suporta Server Components. O Pages Router (a pasta pages/) é o original e ainda é suportado. Projetos novos geralmente usam o App Router. Se o código gerado pela sua ferramenta de IA ou um tutorial parecer estranho, esse costuma ser o motivo.

Um exemplo prático: um diretório público de cafeterias

Imagine um site que lista cafeterias da sua cidade, com uma página para cada uma, que você quer que apareça nos resultados de busca.

Uma página Next.js para uma cafeteria pode ser mais ou menos assim:

// app/cafes/[slug]/page.tsx  →  /cafes/porta-azul, /cafes/mirante ...
export default async function CafePage({ params }) {
  const { slug } = await params;
  const cafe = await db.cafe.findUnique({ where: { slug } });
  return (
    <main>
      <h1>{cafe.name}</h1>
      <p>{cafe.address}</p>
    </main>
  );
}

O que acontece quando alguém (ou o Google) visita /cafes/porta-azul:

1. O Next.js associa a URL a esse arquivo. A pasta [slug] significa “qualquer cafeteria”.
2. O componente roda no servidor, lê a cafeteria do banco de dados e monta o HTML.
3. O navegador recebe uma página completa com o nome e o endereço da cafeteria já incluídos — sem esperar o JavaScript buscar os dados.

Com um app React puro no navegador, o navegador primeiro receberia uma página quase vazia, depois baixaria o JavaScript, depois buscaria a cafeteria e só então a mostraria. Os mecanismos de busca muitas vezes conseguem lidar com isso, mas uma página totalmente formada é mais confiável. Veja SEO para sites criados com IA.

Compare com um painel restrito à equipe, atrás de um login: os mecanismos de busca não o veem de qualquer forma, então a renderização no servidor traz pouco benefício, e um app Vite mais simples costuma ser a melhor opção.

Termos principais

Ideias equivocadas comuns

• “O Next.js substitui o React.” Não substitui. Ele usa o React. Seus componentes continuam sendo componentes React.
• “O Next.js é sempre a melhor escolha.” Ele é mais poderoso e também exige mais entendimento. Renderização no servidor, cache e a diferença entre código de servidor e de cliente são fontes comuns de bugs confusos. Para um app que fica quase todo atrás de um login, um app React puro costuma ser mais simples.
• “O Next.js só roda na Vercel.” Ele é de código aberto e pode rodar em qualquer servidor Node.js ou em um contêiner Docker. Uma exportação totalmente estática é possível se você não usar recursos de servidor.
• “Usar Next.js garante um bom SEO.” Ele deixa as páginas legíveis, o que ajuda. As posições nas buscas ainda dependem de títulos, conteúdo, velocidade e links.
• “O código de servidor no Next.js é automaticamente privado.” Código marcado para o cliente acaba no navegador. Os segredos devem ficar apenas em código de servidor e nas variáveis de ambiente.

O que pedir à sua ferramenta de IA

• “Use Next.js com o App Router” — no seu primeiro prompt, se quiser.
• “Quais páginas são renderizadas no servidor, quais são estáticas e quais rodam no navegador — e por quê?”
• “Torne as páginas públicas de marketing e de listagem renderizadas no servidor ou estáticas, com títulos e descrições adequados.”
• “Guarde as chaves de API em código apenas de servidor e em variáveis de ambiente. Mostre onde cada uma é lida.”
• “Este app precisa de Next.js, ou um app Vite + React seria mais simples para o que estamos construindo?”

Next.js no Mythex

O Mythex usa Vite + React + TypeScript + Tailwind por padrão e muda para Next.js quando você pede no prompt; mencionar isso logo no início economiza créditos em comparação com mudar depois. Você vê o app na Prévia ao vivo, e Publicar o coloca em uma URL ativa sem que você precise configurar a hospedagem. A documentação do Mythex observa que apps de página única renderizados no cliente têm SEO mais fraco do que HTML renderizado no servidor ou estático, então, para um site de marketing em que a busca importa, vale dizer isso logo de início (SEO para o seu app).

Perguntas