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

> Published 2026-10-11T13:55:33.049Z on https://www.crazystack.com.br/pt/p/next-js-ou-tanstack-start-o-que-muda-na-pratica/
> Source video: https://www.youtube.com/watch?v=WjcIJ8E-yXM

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](https://vercel.com) na Vercel, empresa que mantém o [Next.js](https://nextjs.org), 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](https://opennext.js.org) 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](https://nextjs.org/blog/next-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](https://tanstack.com/start) é o framework full-stack da organização TanStack, conhecida pelo [TanStack Query](https://tanstack.com/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](https://vitejs.dev) 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](https://reactrouter.com), 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](https://crazystack.com.br).

Experimente transformar seu próximo vídeo em artigo no [Skala Blog](https://skalablog.com).

[Source video](https://www.youtube.com/watch?v=WjcIJ8E-yXM)