Next.js ou TanStack Start: o que muda na prática

Next.js ou TanStack Start? Use Next.js se você quer o padrão do mercado, server components e o ecossistema mais maduro. Use TanStack Start se você quer TypeScript completo nas rotas, cache explícito, Vite como bundler e liberdade para renderizar por página. Um projeto pode até misturar os dois conceitos em times diferentes.

Next.js ou TanStack Start: qual escolher?

Next.js ou TanStack Start? A resposta curta: Next.js continua sendo o padrão do mercado e a escolha segura para quem quer vaga no frontend, enquanto o TanStack Start ganha pontos quando você quer cache explícito, TypeScript integral e menos dependência da Vercel. Felipe Rocha, do canal Full Stack Club, resumiu essa reflexão em um vídeo publicado em 3 de julho de 2026, e a conclusão dele foi clara: ele não abandonou o Next.js, mas passou a estudar o TanStack Start para projetos próprios.

A decisão entre Next.js ou TanStack Start não é técnica apenas. É uma decisão de risco: quanto sua aplicação depende de features que só funcionam bem em um provedor específico? Quanto o seu time aguenta reaprender cache a cada versão? As seções abaixo destrincham os três argumentos do vídeo e o que o TanStack Start propõe em resposta.

Vendor lock-in: o problema mais grave do Next.js hoje

O primeiro e mais grave problema apontado por Felipe é o vendor lock-in na Vercel, empresa que mantém o Next.js, framework React open source para produção. Nem toda feature do Next funciona igual fora da Vercel: partial prerendering (PPR) e streaming com Suspense têm comportamento limitado em outras plataformas, especialmente em ambientes serverless como Cloudflare, AWS e Netlify.

A comunidade criou o OpenNext para mitigar isso, permitindo deploy serverless em outros provedores. Felipe, que relata ter usado a ferramenta em produção, a descreve como um hack: o suporte a alguns recursos é parcial, e atualizar a versão do Next depende do time do OpenNext atualizar a biblioteca primeiro. A alternativa oficial é rodar em Docker, seguindo o guia da própria Vercel, o que preserva as funcionalidades mas abre mão da escalabilidade automática e encarece a operação.

O detalhe que incomoda é estrutural: o Next.js é open source, mas a Vercel é a principal mantenedora, e features desenvolvidas com contribuição da comunidade acabam funcionando plenamente apenas na infraestrutura da empresa. Para um projeto corporativo, onde decisões técnicas custam caro, esse é um risco real de avaliar antes de escolher.

Abordagem server-first: quando ela pesa contra

A Vercel parte da premissa de que a maior parte do conteúdo da web é estática, e o Next.js reflete essa visão. Todo componente criado é, por padrão, um server component, sem interatividade. Para usar interatividade no cliente, você marca explicitamente com use client.

Para aplicações realmente pouco interativas, essa abordagem funciona bem. Para aplicações ricas em interação, ela adiciona uma camada cognitiva constante: decidir o que é client component, o que pode ser importado, o que não pode. Felipe é cuidadoso aqui e não afirma que server-first é ruim. Ele diz que depende da aplicação, e que aplicações interativas são mais comuns do que a premissa da Vercel sugere.

O TanStack Start inverte a lógica com uma abordagem client-first, partindo do princípio de que a maioria das aplicações tem interatividade. Server-side rendering existe, mas por página, não como padrão global. Você pode ter páginas renderizadas no servidor e outras funcionando como SPA, com apenas o shell HTML e conteúdo inserido via JavaScript, algo útil em dashboards, por exemplo.

Caches implícitos e breaking changes entre versões

Para Felipe, o que mais pega no Next.js é o sistema de caches embutido. Um exemplo clássico: o fetch era cacheado por padrão, seguindo a visão de que o conteúdo provavelmente é estático. Cache implícito é problemático porque um dado cacheado sem que você saiba pode afetar a aplicação de formas difíceis de rastrear.

A comunidade reclamou, e a Vercel recuou: no Next.js 15, lançado em 2024, o fetch deixou de ser cacheado por padrão, como documentado nas notas de versão do Next.js 15. Felipe relata, por experiência própria como educador, que gravou uma formação completa na versão 15 e precisou regravar boa parte do material quando o Next.js 16 mudou o sistema de cache novamente. Segundo ele, as mudanças foram para melhor, mas cada quebra gera carga cognitiva no time.

O argumento central é simples: cache deveria ser explícito. Em vez de descobrir pela documentação que uma chamada tem cache, você escreve a intenção no código, como um revalidate: 3600. O Next.js também criou mecanismos próprios de cache em vez de usar integralmente o header Cache-Control padrão da web, o que adiciona mais uma curva de aprendizado específica do framework.

O que o TanStack Start faz de diferente

O TanStack Start é o framework full-stack da organização TanStack, conhecida pelo TanStack Query e pelo TanStack Router. A documentação mantém uma seção dedicada à comparação com o Next.js, seu concorrente direto. O resumo da proposta cabe em uma tabela.

Client-first em vez de server-first

Componentes nascem no cliente, e o SSR é opcional por página. Todos os componentes passam por hydration, então o conteúdo pode ser gerado no servidor quando você quiser, sem a divisão rígida entre server e client components do Next.js.

Explicitude em tudo

Cache, middleware, qualquer comportamento fora do padrão está escrito no código. A documentação do framework trata explicitamente o tema implicit versus explicit. Para quem já perdeu tempo debugando um cache invisível, essa é a diferença mais convincente.

Vite e TypeScript integral

O TanStack Start usa o Vite como bundler, no lugar do Webpack e do Turbopack do Next.js, e é 100% TypeScript, incluindo tipagem nas rotas e links. A limitação declarada: não há server components, pelo menos por enquanto. Se você precisa deles, o Next.js segue sendo o caminho.

Dimensão	Next.js	TanStack Start
Abordagem	Server-first	Client-first
Cache	Histórico de implicit caching, em correção	Explícito por padrão
Bundler	Webpack / Turbopack	Vite
TypeScript	Tipagem de rotas limitada	100% tipado, incluindo rotas
Server components	Sim	Não, por enquanto
Deploy fora da Vercel	Exige OpenNext ou Docker	Renderização independente por página

E o React Router v7 e o Remix?

Antes de chegar ao TanStack Start, Felipe considera o React Router v7, que absorveu o projeto Remix como framework. Ele avalia a documentação como um pouco confusa quanto à questão de ser framework, mas reconhece que é uma opção válida no mesmo espaço.

A conclusão prática: existem alternativas ao Next.js, mas nenhuma com a maturidade de mercado dele. O próximo passo natural é aprender bem o Next.js e, a partir dele, frameworks como TanStack Start e React Router se tornam muito mais fáceis de entender, já que resolvem os mesmos problemas com premissas diferentes.

Perguntas frequentes

• Felipe Rocha abandonou o Next.js? Não. No vídeo de julho de 2026, ele deixa claro que não abandonou o framework, mas passou a estudar o TanStack Start para projetos próprios. Ele segue recomendando Next.js para quem quer entrar ou crescer no mercado frontend.

• O TanStack Start tem server components? Não, pelo menos não no momento da análise. Todos os componentes passam por hydration, e você pode ativar server-side rendering por página. Se server components são requisito do seu projeto, o Next.js é a escolha adequada.

• **É possível fazer deploy do Next.js fora da Vercel, por dois caminhos: OpenNext para ambientes serverless, com suporte parcial a algumas features, ou Docker, que preserva as funcionalidades mas perde escalabilidade automática e aumenta o custo de operação.

• Por que cache implícito é considerado um problema? Porque um dado cacheado sem que o desenvolvedor saiba pode alterar o comportamento da aplicação de forma difícil de rastrear. Cache explícito, escrito no código, comunica a intenção e facilita a manutenção pelo time.

• Um iniciante deve começar pelo TanStack Start? A recomendação do vídeo é começar pelo Next.js por ser o padrão do mercado. Depois de dominá-lo, frameworks como TanStack Start e React Router ficam muito mais simples de aprender.

Do vídeo ao artigo escrito

Questionar as ferramentas que você usa é o tipo de lição que merece existir em mais de um formato. O vídeo do Felipe Rocha funciona bem em vídeo, mas muita gente consome conteúdo técnico por busca e prefere uma referência escrita, com links diretos para a documentação e comparações em tabela.

Se você também tem conhecimento valioso gravado em vídeos do YouTube, sejam aulas, opiniões ou análises como esta sobre Next.js e TanStack Start, você pode transformar esse material em artigos estruturados. O fluxo é direto: você cola a URL do vídeo, obtém a transcrição e gera um artigo pronto para revisar. A mesma lógica vale para conteúdos de criadores como Gustavo Dev Doido, do Bootcamp do Dev Doido, e das formações do Crazystack Typescript, disponíveis em crazystack.com.br.

Experimente transformar seu próximo vídeo em artigo no Skala Blog.

Source video