Em 25/10/22 aconteceu o Next.js Conf 2022⇗, o evento online promovido pela Vercel⇗ que serviu de palco para o lançamento do Next.js 13⇗.

A 13ª versão do framework front-end React de código aberto criado pela Vercel chegou cheia de hype, com algumas novidades realmente marcantes, mas também com um tanto de promessas ousadas - que talvez se mostrem exageradas conforme os desenvolvedores começarem a usar o Next.js 13 na prática.

Nos chamaram a atenção as opiniões sobre o lançamento⇗ feitas pelo canal do YouTube chamado Fireship⇗.

Então, depois de mais de 100 mil visualizações do evento de lançamento - e um tanto de comentários sobre as novidades -, trouxemos aqui os principais pontos de reflexão sobre os recursos do Next.js 13 propostos pelo Fireship. Fizemos isso porque concordamos com as afirmações do canal. Mas a sua opinião só pode ser construída por você mesmo. Por isso, leia o texto, experimente a nova versão do Next.js e chegue às suas próprias conclusões. 🎯

Pois é, seu framework front-end predileto mudou. Bora reaprender? 😏

É legal deixarmos clara a nossa opinião sobre o Next.js 13 desde o início, citando uma frase do vídeo do Fireship:

Esses novos recursos mudam o jogo e são incrivelmente rápidos, mas não estão isentos de trade-offs.

Vamos entender melhor esta afirmação, falando um pouco sobre as principais novidades do Next.js 13.

Turbopack

Este é o nome da nova ferramenta de build do Next.js. O Turbopack⇗ é o sucessor do Webpack, que já foi baixado mais de 3 bilhões de vezes e, por isso mesmo, tornou-se parte integrante da construção da Web.

Então, por que substituir o Webpack? 🤔

Segundo a própria Vercel, "é hora de ir mais rápido e escalar sem limites."

Para dar conta do desafio, a Vercel contratou Tobias Koppers, o criador do Webpack, que é bastante versado em agrupamentos de módulos. O Turbopack foi construído desde o início com Rust, se integrando ao Turborepo para armazenar em cache operações duplicadas.

Juntos, esses fatores podem satisfazer sua necessidade de uma velocidade incrivelmente rápida. Tanto é que, durante o Next.js Conf 2022, foi feita a seguinte afirmação:

“O Turbopack mostra atualizações 10 vezes mais rápidas que o Vite e 700 vezes mais rápidas que Webpack”.

Só que essa comparação já foi refutada por Evan You, criador do VueJS⇗ e do Vite⇗. Em seu repositório no GitHub (yyx990803), You chamou os números de "enganosos" e "escolhidos a dedo", já que o Vite ainda usava Babel no momento do benchmarking - ou seja, dizer que o Turbopack é 10x mais rápido não se aplica ao caso.

Enfim, o Turbopack realmente parece incrível, mas atualmente é um alfa. Segundo o Fireship, há motivos para desconfiança:

• Já existe um enorme ecossistema de plug-ins do Webpack, o que dificultará a migração de aplicativos existentes.
• A Vercel provavelmente precisará contar com contribuições da comunidade com algum tipo de sistema de plug-in, e isso pode ser difícil porque muitos desenvolvedores de JavaScript não vão se dar ao trabalho de aprender Rust.

Além disso, esses ganhos de velocidade são realmente relevantes somente para projetos de grandes empresas. O Vite já é rápido o suficiente para a maioria dos projetos e oferece uma experiência de desenvolvedor incrível. Isso é difícil de bater.

🤑 Também não podemos esquecer que a Vercel tem interesse em ganhar dinheiro com o armazenamento de compilações na nuvem remotamente em cache, pois ela usa essa arquitetura há muito tempo.

Novo sistema de roteamento

Uma das features mais empolgantes do Next.js 13 é o novo sistema de roteamento, citado na conferência como “o melhor roteador possível”, o qual adiciona uma variedade de possibilidades e melhorias de desempenho ao framework.

Essas são grandes mudanças nas quais eles trabalharam diretamente com a equipe principal do React. E o melhor é que tudo pode ser adotado de forma incremental para que não interrompa seu projeto existente.

O Next.js 13 adiciona um novo diretório de aplicativos que também usa roteamento baseado em sistema de arquivos como antes, só que agora é tudo baseado em diretório. Junto com várias convenções de nomenclatura para diferentes casos de uso, para criar uma página, você dá ao diretório o nome da rota e adiciona um arquivo page.js a ele. Isso exporta o componente que você deseja exibir lá.

No entanto, por ser um diretório, podemos colocar componentes extras aqui também, em vez de precisar criar um diretório de componentes separado ou algum outro tipo de convenção. Mais importante, isso também abre a porta para layouts e nested routing.

Quando você dá a um arquivo o nome de layout.js, ele cria uma interface do usuário que as rotas filhas podem herdar e, quando você navega para uma rota dentro de um layout, apenas a interface do usuário interna é renderizada, em oposição à página inteira.

Isso é muito legal porque também temos convenções de nomenclatura de arquivos para carregamento e erro que podem renderizar uma interface do usuário diferente no nível do componente com base em seu estado atual.

Por exemplo: se o componente quebrar, ele vai renderizar error.js em vez de page.js, enquanto o restante da interface do usuário permanece intacto. Isso torna a vida muito mais fácil. 🎯

Data fetching

Segundo o vídeo do Fireship, o recurso mais épico desta nova versão é a busca de dados.

O Next.js é praticamente o framework oficial do React. A Vervel valorizou isso na Next.js Conf 2022:

"Isso é o nosso endosso de que esta é a solução de busca de dados para o React que todos estavam esperando”.

Acontece que todos esses são componentes do servidor React por default. Segundo o vídeo do Fireship, os componentes do servidor são uma primitiva de baixo nível no React que permite a renderização do lado do servidor, mas até agora eles sempre foram meio difíceis para o desenvolvedor comum usar.

Então isso representa uma grande vantagem porque agora podemos nos livrar totalmente de coisas como obter props estáticos e props do lado do servidor. Em vez disso, podemos simplesmente escrever uma função JavaScript simples que usa Fetch e aguardar o resultado dessa função diretamente em um componente. Não há necessidade de passar props entre cliente e servidor.

"Parece totalmente natural, como se você estivesse apenas usando Vanilla JS, e você nem precisa serializar dados, o que pode ser um grande problema", diz o vídeo.

Além disso, você não precisa mais de conceitos como ISR, SSR e SSG. O novo modelo mental gira inteiramente em torno do cache. Por padrão, todas as páginas serão armazenadas em cache para fornecer o desempenho de um site estático, mas, se você quiser novos dados em cada solicitação, como SSR, poderá adicionar a opção de cache no-store para buscar - ou, para regeneração estática incremental, usar a próxima opção com o número de segundos de revalidação.

Outra coisa incrível é que a interface do usuário pode ser transmitida de forma incremental, graças ao React.Suspense. Tudo o que você precisa fazer é definir um arquivo loading.js para definir a interface do usuário.

Se um componente ainda estiver aguardando dados, ele o mostrará automaticamente no nível do componente enquanto renderiza todo o resto no aplicativo.

Ok, isso é revolucionário, só que muitos desses recursos são claramente inspirados no framework full stack Remix⇗, que, segundo o Fireship, é realmente ótimo. Estranhamente, não há como escrever rotas de API no novo diretório de aplicativos, e isso parece um desleixo do Next.js 13. Então falta uma maneira de gravar dados, semelhantes aos formulários do Remix.

Enfim, concordamos com o Fireship que a busca de dados parece incrível, mas as mutações são uma história totalmente diferente. Na documentação diz que a equipe Next está trabalhando em um novo RFC para dados mutantes, mas, atualmente, você usaria um componente do lado do cliente, escreveria sua lógica de mutação e passaria uma função de retorno de chamada de uma atualização para atualizar quaisquer dados nesse rota após a mutação estar completa.

Isso é semelhante a como as coisas funcionam na consulta React, mas parece que o framework poderia fornecer uma solução mais intuitiva aqui.

Next.js 13: o veredito (ou ainda é cedo?) 🤔

Tanto o Fireship quanto o time do bohr.io acha que o Next.js 13 parece incrível, mas traz um probemão:

As principais mudanças aqpresentadas basicamente tornam todos os tutoriais existentes obsoletos.

Mesmo que essas mudanças representem um passo à frente, a realidade é que as pessoas não gostam de mudanças. No momento, todo mundo está super empolgado com esses novos recursos, mas se você é o cara que precisa migrar uma quantidade absurda de código, sua empolgação inicial pode se transformar em raiva.

Lucas Boemeke⇗, CTO do bohr.io, acha que a Vercel está retrocedendo na questão dos server components:

"Essa coisa de mandar renderizar o HTML no servidor, isso é como funcionava a base da internet. O PHP funciona assim. Muitos dos benefícios do Jamstack se perdem com o modelo de server components que estão propondo."

Boemeke acredita que o React continuará sendo por muito tempo o principal framework front-end, mas também acha que adotá-lo cegamente para tudo é um radicalismo não muito inteligente.

As pessoas mais versadas em tecnologia acabam descobrindo que existem várias outras formas de fazer as coisas, ao invés de mergulhar 100% no que está sendo proposto pela Vercel. Até porque esta dependência de uso do React está ficando com cara de walled garden, e ninguém gosta disso - a não ser própria corporação, é claro.

Sendo assim, não há melhor forma de terminar este blog post do que usando um jargão bastante surrado para falar sobre o futuro do Next.js 13:

Só o tempo irá dizer. 🔮

Você já experimentou as novidades no Next.js 13? Concorda com o que escrevemos aqui ou até agora tudo está suave? Compartilhe suas experiências nos comentários!