O Next.js domina o ecossistema React e tem motivos para isso. Server Components, App Router, middleware na edge. Mas essa abrangência cobra um preço: complexidade. Nem todo projeto precisa de tudo que o Next.js oferece, e em vários cenários existem frameworks que resolvem o problema com menos fricção.

Este post organiza 8 alternativas por tipo de site. A ideia é simples: em vez de comparar features lado a lado numa tabela genérica, partir do projeto que você precisa construir e chegar no framework que faz mais sentido.

Por que considerar alternativas ao Next.js

O Next.js cresceu. Next.js 16 com React 19, Turbopack estável, Server Actions, Partial Prerendering. O problema é que esse crescimento trouxe uma superfície de API enorme. Middleware, route handlers, server actions, use server, use client, layouts paralelos, intercepting routes. Para um blog ou landing page, é como usar um trator para arar um vaso de planta.

Além disso, o acoplamento com a Vercel gera preocupação legítima. O deploy funciona em qualquer lugar, mas o DX otimizado é claramente pensado para a plataforma deles. Projetos que rodam em Cloudflare Workers, AWS Lambda ou num VPS com PM2 sentem essa diferença.

E tem a questão do ecossistema. O mundo não é só React. Vue, Svelte e até frameworks sem biblioteca de UI produzem resultados excelentes dependendo do contexto. Ficar preso ao React por inércia é uma escolha, não uma necessidade.

Sites de conteúdo e blogs

Para sites onde o conteúdo é rei e a interatividade é mínima, duas opções se destacam.

Astro

O Astro foi construído para isso. A arquitetura de Islands permite que 95% da página seja HTML estático puro, sem JavaScript. Só os componentes interativos (um formulário de newsletter, um botão de like) recebem hidratação.

O Astro 5 trouxe a Content Layer API, que permite carregar conteúdo de qualquer fonte (Markdown local, CMS headless, API, banco de dados) com type safety completa. Os builds ficaram até 5x mais rápidos para sites pesados em Markdown, com 50% menos uso de memória comparado ao approach anterior.

E aqui está o ponto que mais importa na prática: você pode usar componentes React, Vue ou Svelte dentro do Astro. Se seu time já tem componentes React prontos, eles funcionam sem reescrita.

// astro.config.mjs — usando React dentro do Astro
import { defineConfig } from 'astro/config';
import react from '@astrojs/react';
import tailwind from '@astrojs/tailwind';

export default defineConfig({
  integrations: [react(), tailwind()],
  output: 'static',
});

Eleventy

Se você quer ainda menos magia, o Eleventy é a opção. Zero JavaScript no output por padrão. Sem bundler, sem framework de UI, sem opinião sobre como você organiza CSS. Você escreve templates em Nunjucks, Liquid ou até JavaScript puro, e ele cospe HTML.

O Eleventy brilha em projetos onde o controle total é mais valioso que conveniência. Documentação técnica, blogs pessoais de desenvolvedores, sites institucionais que precisam durar 10 anos sem quebrar por causa de uma major version.

Sites estáticos e documentação

Quando o site tem centenas ou milhares de páginas e a velocidade de build importa tanto quanto a velocidade de carregamento.

Hugo

O Hugo compila em Go e a diferença de velocidade é absurda. O site da Smashing Magazine, com 7.500 páginas, compila em cerca de 13 segundos. O equivalente em Jekyll levaria minutos. Em benchmarks diretos, o Hugo é entre 23x e 63x mais rápido que o Jekyll.

Para documentação técnica, o Hugo tem um ecossistema maduro de temas (Docsy, Hugo Book, Geekdoc) que já vem com busca, versionamento e navegação lateral prontos.

O tradeoff é que o sistema de templates do Hugo (baseado em Go templates) tem uma curva de aprendizado própria. Não é HTML com JSX. É HTML com {{ .Params.title }} e {{ range .Pages }}. Funciona, mas exige adaptação.

# Criando um novo site Hugo e servindo localmente
hugo new site meu-docs
cd meu-docs
git init
git submodule add https://github.com/google/docsy themes/docsy
hugo server --buildDrafts

Astro (de novo)

O Astro também funciona bem para documentação, especialmente com o Starlight, um tema oficial para docs. A vantagem sobre o Hugo é que você mantém JSX/TSX e pode embedar componentes interativos (playgrounds de código, sandboxes) sem sair do ecossistema JavaScript.

Aplicações full-stack e SaaS

Aqui a conversa muda. O projeto precisa de autenticação, dashboards, formulários complexos, APIs. O framework precisa lidar com server-side rendering, data fetching e mutações de dados.

SvelteKit

O Svelte 5 com Runes redefiniu a reatividade do framework. O $state, $derived e $effect substituem o modelo anterior e entregam reatividade granular: só o trecho exato do DOM que mudou é atualizado, sem reavaliar a árvore inteira.

Na prática, isso significa bundles 50% menores que o equivalente em React. Um e-commerce em SvelteKit entregou bundle 65% menor que a mesma página em Next.js 16 em um benchmark publicado na comunidade DEV. O Svelte compila para JavaScript vanilla, sem runtime.

// +page.server.ts — data loading no SvelteKit
import type { PageServerLoad } from './$types';
import { error } from '@sveltejs/kit';
import { db } from '$lib/server/database';

export const load: PageServerLoad = async ({ params }) => {
  const product = await db.query.products.findFirst({
    where: (p, { eq }) => eq(p.slug, params.slug),
    with: { category: true, reviews: true },
  });

  if (!product) {
    throw error(404, 'Produto não encontrado');
  }

  return { product };
};

O ponto de atenção: o ecossistema Svelte é menor que o do React. Bibliotecas de componentes, integração com serviços terceiros, vagas de emprego. Se o time não conhece Svelte, o custo de aprendizado existe.

React Router v7 (ex-Remix)

O Remix foi absorvido pelo React Router v7. O que era o Remix v2 virou o "framework mode" do React Router. Loaders, actions, nested routes, streaming SSR tudo vive agora dentro do pacote react-router.

A migração de projetos Remix existentes começa com um codemod que troca imports de @remix-run/* para react-router. Para a maioria dos projetos, essa é a parte mais trabalhosa. Para projetos novos, você inicia direto com React Router v7.

O React Router v7 faz sentido quando você quer ficar no ecossistema React mas prefere um modelo mental mais simples que o do Next.js. Sem Server Components, sem a dualidade use client/use server. Loaders carregam dados no servidor, actions processam mutações, e o framework cuida do resto.

// route.tsx — loader e action no React Router v7
import type { Route } from './+types/route';
import { data, redirect } from 'react-router';
import { getUser, updateUser } from '~/lib/db';

export async function loader({ params }: Route.LoaderArgs) {
  const user = await getUser(params.id);
  if (!user) throw data(null, { status: 404 });
  return { user };
}

export async function action({ request, params }: Route.ActionArgs) {
  const formData = await request.formData();
  await updateUser(params.id, Object.fromEntries(formData));
  return redirect(`/users/${params.id}`);
}

TanStack Start

O TanStack Start é o mais novo competidor nesse espaço. Construído sobre o TanStack Router e Vite, está em Release Candidate e se posiciona como um framework full-stack com type safety de ponta a ponta.

A proposta é clara: rotas com tipagem inferida, server functions tipadas, streaming SSR, e deploy em qualquer provider (Cloudflare, AWS, Vercel, Netlify). O diferencial é que o TanStack Start evita a complexidade dos React Server Components. Usa SSR tradicional com hidratação completa, mas com streaming.

Se você já usa TanStack Query e TanStack Router no seu projeto, o Start é a evolução natural. Se não, o ecossistema ainda está amadurecendo e a documentação é mais escassa que a dos concorrentes.

Nuxt

Para times que trabalham com Vue, o Nuxt é a escolha óbvia. O Nuxt 4, lançado em 2025, trouxe a nova estrutura com diretório app/, data fetching melhorado com useAsyncData e useFetch, e o motor Nitro para o servidor.

Um caso concreto: após migrar um e-commerce para Nuxt 3 com Nitro, o TTFB caiu 40% e o número de páginas indexadas pelo Google subiu 60%, graças ao híbrido SSG/SSR que o Nitro permite.

O Nuxt 4.3 já permite opt-in em features do Nuxt 5, que vai trazer o Nitro 3 com cron jobs nativos e execução mais eficiente. O ecossistema de módulos é maduro: autenticação, i18n, SEO, tudo tem módulo oficial ou da comunidade.

// nuxt.config.ts — configuração básica do Nuxt 4
export default defineNuxtConfig({
  compatibilityDate: '2025-01-01',
  future: {
    compatibilityVersion: 4,
  },
  modules: [
    '@nuxtjs/tailwindcss',
    '@sidebase/nuxt-auth',
  ],
  nitro: {
    preset: 'cloudflare-pages',
  },
});

E-commerce e plataformas transacionais

E-commerce precisa de performance (cada 100ms de latência custa conversão), SEO forte (páginas de produto indexadas) e personalização em tempo real (carrinho, recomendações).

SvelteKit para e-commerce leve

Para lojas menores ou marketplaces com catálogo moderado, o SvelteKit entrega bundles minúsculos e Lighthouse scores consistentemente acima de 90. A ausência de runtime significa que o Time to Interactive cai drasticamente.

Nuxt para e-commerce em escala

O híbrido SSG/SSR do Nuxt com Nitro permite pré-renderizar páginas de categoria e produto (SEO) enquanto mantém carrinho e perfil em SSR (personalização). A combinação é forte para e-commerces com milhares de SKUs.

Hydrogen (Shopify)

Se a plataforma é Shopify, o Hydrogen é o framework oficial deles. Construído sobre React e Remix (agora React Router), integra diretamente com a Storefront API do Shopify. Não é uma alternativa genérica ao Next.js, mas para lojas Shopify é a opção com menor fricção.

Quando o Next.js ainda faz sentido

Nem toda discussão de alternativas precisa terminar com "abandone o Next.js". Ele continua sendo a melhor escolha em cenários específicos.

Times grandes com experiência em React precisam de um framework com documentação extensa, ecossistema vasto e facilidade de contratação. O Next.js entrega isso. Projetos que precisam de SSR, SSG, ISR, Server Components, API Routes, middleware e edge functions ao mesmo tempo não encontram outro framework React que empacote tanta coisa num lugar só.

Se o deploy já é na Vercel, o DX do Next.js é difícil de igualar. Preview deployments, analytics, image optimization, tudo funciona out of the box. E para projetos existentes em Next.js que funcionam bem, migrar por migrar não faz sentido. Se o time está produtivo e os usuários estão satisfeitos, a melhor alternativa pode ser nenhuma.

Conclusão

A escolha de framework em 2026 é menos sobre qual é "melhor" e mais sobre qual resolve o problema do seu projeto com o mínimo de complexidade desnecessária.

Para conteúdo estático, Astro e Hugo eliminam JavaScript onde ele não precisa existir. Para aplicações full-stack fora do React, SvelteKit e Nuxt oferecem modelos de reatividade e data fetching maduros. Dentro do React, o React Router v7 e o TanStack Start oferecem alternativas com menos superfície de API que o Next.js.

O próximo passo prático: pegue o próximo projeto que você precisa começar e, antes de rodar npx create-next-app, gaste 30 minutos no getting started do framework que mais se encaixa na lista acima. A experiência de primeira mão vale mais que qualquer comparativo.

Referências pesquisadas nesta publicação