Você não precisa de Next.js — por que migramos do Next para React

• Resultados obtidos ao migrar o dashboard da ComfyDeploy de Next.js para React:
  • tempo de build reduzido de 3 minutos para 18 segundos
  • hot reload melhorado para menos de 200 ms
  • a equipe ficou muito mais satisfeita
• No início, começamos com uma aplicação full-stack usando Next.js, e ela funcionava bem com segurança de tipos e código limpo graças ao Drizzle e às Server Actions, mas surgiram os seguintes problemas:
  • custos altos de API na Vercel, chegando a US$ 2.000 por causa de um usuário específico
  • aumento da complexidade para testar a API: mistura de Server Actions com rotas de API
  • tempo de build lento e ambiente de desenvolvimento local ineficiente
  • até pequenas mudanças causavam recarga completa de SSR
• Problemas
  • aumento da complexidade do Next.js: a abordagem tudo-em-um (full-stack) do Next.js gerou complexidade de desenvolvimento à medida que o app cresceu
  • nosso dashboard é principalmente baseado em React e não precisa dos recursos de servidor do Next.js
• Transição de Next.js para React
  • migração de Next.js para React usando TanStack Router e Rspack
    • início do servidor de desenvolvimento: em menos de 2 segundos
    • tempo de build na Vercel: 18 segundos
  • melhoria na configuração da API, remoção de dependências desnecessárias e simplificação do código, aumentando a produtividade
• Comparação de desempenho
  • Next.js 15 (usando modo Turbo)
    • build da primeira página: 10,4 segundos
  • React + TanStack Router + Rspack
    • cálculo de rotas: menos de 200 ms
    • build inicial do bundle: 1,67 segundo
• Trade-offs
  • O que perdemos
    • co-location entre código de frontend e backend: ao separar frontend e backend, os limites ficaram mais claros
    • recursos de cache do Next.js: como há muitos dados com atualização em tempo real, foram substituídos por cache personalizado
    • pré-renderização e carregamento inicial: em vez de Static Generation, foi implementada uma UX melhor — não há mais exibição de botões desativados
    • componentes e ações de servidor: perdemos a “mágica” dos componentes de servidor, mas houve melhora com um design de API mais intencional
  • O que ganhamos
    • fortalecimento do design de contratos de API
    • implementação de cache apenas onde necessário
    • projeto cuidadoso do fluxo de dados e da gestão de estado
• Conclusão
  • Next.js é adequado para tarefas como landing pages e SEO, mas para a maioria dos produtos traz complexidade excessiva
  • ainda usamos Next.js para landing pages e trabalho de SEO
  • o dashboard foi migrado para Pure React + TanStack Router + Rspack
  • a API roda em um servidor Python FastAPI no Google Cloud Run, com escalonamento automático conforme a necessidade
• É importante escolher a ferramenta certa, e para nós o Next.js foi uma escolha excessiva

[zerocyber]

Na nossa empresa, justamente quando estávamos nos preparando para padronizar/migrar o front-end para Next.js, acabei lendo um texto desses... isso realmente faz a gente pensar bastante....

[nemorize]

Operamos apenas serviços com foco em aplicativo móvel primeiro, então, nas áreas em que SEO é necessário, nem usamos React (ou algo parecido) e mantemos tudo bem leve.
Usamos a web apenas para atrair via SEO e direcionar para o app...

[beenzinozino]

"Escolher a ferramenta certa é importante e, para nós, Next.js foi uma escolha excessiva."

Acho que a última frase é o ponto principal.

Para escolher a ferramenta certa, acho que também é importante passar por muitos desses tipos de tentativa e erro.

[iolothebard]

Se você precisa de SEO, isso significa que o conteúdo é o principal,
mas como os componentes de UI(?) e o estado ocupam o centro de tudo... nasceram aberrações como SSR, ISR e Hydrate...

[schang124]

Concordo bastante com esse conteúdo.
Eu nunca adoto Next.js, a menos que haja necessidade de SEO.
Como no texto acima, usar apenas React traz muitas vantagens:

• Some a complexidade e os padrões desnecessários característicos do Next.js.
  • A manutenção fica mais simples
• Você deixa de arcar com custos desnecessários de SSR
• Há mais liberdade de escolha em relação a bibliotecas de infraestrutura de front-end, como router e bundler

[jhj0517]

Não sei ao certo, mas aparentemente há bastante diferença no tempo de build.

[bichi]

Parece que você ainda não percebeu que o React é muito mais lento do que outros frameworks.

[slowandsnow]

Porque velocidade não é importante. Se velocidade importasse, o expressjs ainda não seria usado. A comunidade e as bibliotecas são esmagadoramente maiores.

[devheerim]

Parece que o foco está em migrar do Next para o React haha

[bbulbum]

Não sei se é uma escolha fácil ir contra isso, já que a comunidade React abandonou o CRA logo no início e migrou para os frameworks.

[sacru2red]

A maioria migrou para o Vite, e o framework continua sendo usado conforme a necessidade, ainda hoje

[bbulbum]

Ao criar uma nova aplicação ou um site inteiro com React, é recomendável usar um framework.

É isso que está escrito no react.dev~

[kandk]

Interessante. O Next é mais pesado em comparação com o React?
Só cheguei a fazer a configuração inicial de projetos com Next, mas foi extremamente simples montar o projeto e começar o desenvolvimento.

[cichol]

"Simples" <= por trás disso existe uma mágica(?) que traz muitos trade-offs para conseguir alcançar isso.

[beenzinozino]

Concordo. Há uma quantidade enorme de dependências escondidas por baixo do Next.js...

[GN⁺]

Opiniões no Hacker News

• Muitas pessoas estão focadas demais em saber se uma ideia consegue escalar para bilhões de usuários. Por isso, às vezes usam Kubernetes mesmo quando o site tem só 5 visitantes. Já vi estudantes usando Next.js para criar sites que poderiam simplesmente ser feitos com HTML + CSS

• Já construí projetos com Next.js, mas achei complicado de usar. A API de acesso a cookies é diferente entre cliente e servidor, e ainda há confusão como precisar acessar variáveis de ambiente com process.env.NEXT_PUBLIC_*. Eu queria escrever código que funcionasse no cliente e no servidor com o mínimo de mudanças possível, mas não foi assim. Senti que o aprendizado e a sobrecarga não valiam a pena pelo que o Next.js oferece

• A base de código ficou mais simples e a renderização das páginas ficou mais rápida. É uma pena que a comunidade esteja sendo empurrada desnecessariamente para frameworks assim. A maioria das pessoas só precisa de npx rsbuild init. Usei rspack e rsbuild para obter um roteador simples e uma simplicidade bonita

• Uso desde o lançamento do Next.js v14 e estou muito satisfeito. Com RSCs, grande parte do app continua funcionando bem mesmo com o JS do lado do cliente desativado. Tem a força simples de um app em PHP, e permite incluir de forma fluida sistema de tipos e componentes de cliente interativos baseados em estado no "nível de folha" da árvore de views

• Graças a Rails e Hotwire, consegui sair da confusão do ecossistema React. Há opções demais: bibliotecas de gerenciamento de estado, meta-frameworks, bibliotecas de data fetching etc. Não há necessidade de complicar a tarefa simples de mostrar na página dados vindos do servidor

• Trabalho em um CMS que usa NextJS (PayloadCMS), e NextJS é a pior tecnologia que já usei

• Quase todo projeto que usa frameworks/bibliotecas pesados de frontend como Next.js, React e Vue estaria melhor usando uma biblioteca que renderiza templates no backend. Às vezes faz sentido usar renderização no cliente com EJS. Fico me perguntando por que usar esses frameworks

• Uso Next.js por causa de SEO e otimização para crawlers. Se a página não precisa ser rastreada por crawlers, como um dashboard atrás de login, então não há necessidade de Next.js e React puro provavelmente será mais simples

• Surpreende que Next.js tenha virado a opção padrão de início. Parece uma grande mudança em comparação com 2 ou 3 anos atrás

• Estou tentando substituir apps em NextJS usando Vike, e estou satisfeito. Dá para construir do jeito que você quer sem atrapalhar

[aer0700]

Kubernetes para um app com 5 usuários... impressionante.