Não me entendam mal. Eu conheço os problemas desde a migração do Pages Router para o App Router, o impacto que isso teve na experiência de desenvolvimento, as discussões sobre lock-in com a Vercel e até algumas questões de segurança que surgiram no caminho. Mas talvez o ponto principal não seja "Next é ruim". Talvez o ponto seja outro: será que a maioria desses projetos realmente precisavam usar Next?

O que Next.js realmente é

Next é, primeiramente, um framework opinativo pra construção de aplicações React com um foco imenso em renderização no servidor. Ele foi pensado pra SSR, ISR, SSG e toda essa sopa de letrinhas que a Vercel ajudou a popularizar. A proposta inicial sempre foi muito clara: pré-renderizar ao máximo, servir HTML pra otimizar SEO, reduzir tempo de carregamento e entregar uma experiência extremamente performática após o build. No cenário ideal, você gera páginas estáticas, invalida cache quando necessário, e entrega páginas mais performáticas.

Exemplos de uso quase perfeitos para isso são:

• Blogs
• Portais de notícia
• Landing pages
• Marketplaces com catálogo público
• E-commerces com foco em SEO

Ou seja: produtos onde o conteúdo pode ser pré-renderizado e o SEO é extremamente necessário pro sucesso.

Quando a escolha não faz sentido

O problema começa quando pegamos essa ferramenta, pensada pra server-side, e aplicamos em sistemas totalmente dinâmicos e dependentes do client.

• Sistemas internos com muita interatividade
• Aplicações com múltiplos filtros, modais, estados locais complexos e atualizações frequentes de dados.
• Produtos onde praticamente tudo depende de quem está logado e do que ele acabou de fazer.

Se SEO não é prioridade e quase nada pode ser gerado estaticamente, o HTML pré-renderizado deixa de ser diferencial. O que passa a importar, é estado, interatividade e previsibilidade no client.

Onde o TanStack se encaixa

E é aí que entra o TanStack.

TanStack segue um modelo muito mais próximo de uma SPA tradicional, com SSR como opt-in, não como premissa arquitetural. O fluxo padrão é simples: rota, query, mutação, invalidação.

Não existe a mesma preocupação constante sobre se um componente deve ser server ou client side. A aplicação nasce essencialmente como client, e o uso de server rendering é uma decisão consciente, não o ponto de partida.

Talvez o que esteja acontecendo agora não seja uma "rejeição ao Next". É só o reflexo da escolha do framework do momento ao invés de escolhas pensando em arquitetura e produto (farpas ao React que tem concorrentes que entregam soluções melhores de forma mais elegante, mas isso é papo pra outro post).