Smashing Podcast Episódio 23 Com Guillermo Rauch: Qual é o Next.js?

Hoje, vamos falar sobre Next.js. O que é e onde pode se encaixar em nosso fluxo de trabalho de desenvolvimento web? Falei com o co-criador Guillermo Rauch para descobrir.

Mostrar notas

• Guilhermo Rauch no Twitter
• Next.js

Atualização semanal

• “Dominando Props e PropTypes em React”
  por David Adeneye
• “Decisões de design inspiradas com Bradbury Thompson: a arte do design gráfico”
  por Andy Clarke
• “Configurando uma API usando Flask, Cloud SQL e App Engine do Google”
  por Wole Oyekanmi
• “Formulários e validação em Ionic React”
  por Jerry Navi
• “Como ajudar seus clientes a obter mais backlinks por meio do design”
  por Suzanne Scacca

Transcrição

Drew McLellan: Ele é o fundador e CEO da Vercel, uma plataforma em nuvem para sites estáticos que se encaixa em um fluxo de trabalho Jamstack. Ele também é o co-criador do Next.js. Ele fundou anteriormente o LearnBoost e o CloudUp e é conhecido como o criador de várias bibliotecas de código aberto de nós populares, como Socket.io, Mongoose e SlackIn. Antes disso, ele era um desenvolvedor principal do MooTools, então sabemos que ele conhece o JavaScript como a palma da mão. Você sabia que ele uma vez recebeu uma comissão real do rei da Espanha para criar uma escultura de gelo de alface? Meus amigos esmagadores, por favor, dêem as boas-vindas a Guillermo Rauch. Olá Guilherme, tudo bem?

Guillermo Rauch: Estou muito bem, obrigado por me receber.

Drew: Eu queria falar com você hoje sobre todo o mundo do Next.js, já que é algo que obviamente você conhece muito bem, tendo se envolvido como co-criador desde o início. Next.js é um daqueles nomes de projetos que estiveram no meu radar enquanto trabalhava no espaço Jamstack, mas não é algo que eu tenha visto pessoalmente ou trabalhado muito de perto antes. Para pessoas que são como eu, que talvez não estejam cientes do que é o Next.js, talvez você possa nos dar um pouco de conhecimento sobre o que é e quais problemas ele tenta resolver.

Guillermo: O Next.js é um membro muito interessante do universo Jamstack, porque o Next.js na verdade começou a ser um framework totalmente focado em SSR. Começou a ter muita adoção fora do espaço Jamstack, onde as pessoas estavam construindo coisas muito grandes especificamente quando queriam ter conteúdo gerado pelo usuário ou conteúdo dinâmico ou redes sociais ou comércio eletrônico, e eles sabiam que queriam SSR porque seu conjunto de dados era muito grande ou muito dinâmico. Acho que caiu no radar de muitas pessoas no mundo Jamstack, mas mais tarde o Next.js ganhou os recursos para otimização estática.

Guillermo: Por um lado, por exemplo, se você não fizesse a busca de dados no nível superior da sua página com o Next.js, sua página React seria... Aliás, para quem não conhece totalmente, Next.js é simplesmente o framework React para produção, mas tem essa capacidade de fazer alguma renderização. Então, quando você entrar nos recursos de otimização estática, se você não definir a busca de dados no nível superior da sua página, ela será automaticamente exportada como HTML em vez de tentar fazer qualquer coisa com a renderização do servidor.

Guillermo: Mais tarde, ele também ganhou a capacidade de geração de site estático, o que significa que você pode definir um gancho de dados especial, mas esse gancho de dados obtém dados em tempo de compilação. O Next.js se tornou um framework dinâmico e estático híbrido, muito poderoso, e agora vem crescendo muito também no espaço Jamstack.

Drew: As pessoas podem dizer que o React já é um framework, você certamente o ouve descrito dessa maneira. O que realmente significa ser um framework para React?

Guillermo: Essa é uma ótima observação, porque eu sempre aponto para as pessoas que React no Facebook e React fora do Facebook são feras completamente diferentes. O React no Facebook na verdade é usado junto com a renderização do servidor, mas mesmo a renderização do servidor, por exemplo, não usa Node.js, ele usa uma máquina virtual altamente especializada chamada Hermes que se comunica com seu tipo de hack de produção e pilha PHP e respostas todas essas necessidades avançadas e exóticas do Facebook.

Guillermo: Quando eles abrem o React, é quase como abrir o código de um componente. Eu sempre chamo isso de código aberto do motor, mas não dando a você o carro. O que aconteceu é que as pessoas realmente queriam ir e dirigir com ele, queriam chegar a lugares com React. Na comunidade, as pessoas começaram a criar carros e incorporaram o React como o motor, que era o que o motorista, o desenvolvedor procurava em primeiro lugar, fazer do React a parte fundamental do carro. Coisas como Next.js e Gatsby e React Static e muitos outros frameworks começaram a aparecer que estavam resolvendo a necessidade de “Eu realmente quero criar páginas e aplicativos totalmente carregados”.

Guillermo: Enquanto o React era mais parecido com o componente e o mecanismo para widgets específicos dentro da página, esse certamente era o caso do Facebook. Eles admitirão ampla e publicamente que o inventaram para coisas como o lote de notificação, o widget de bate-papo, o componente de feed de notícias e esses componentes eram rotas React que foram incorporadas ao conteúdo do aplicativo existente de produção com muitas e muitas linhas de código e até mesmo outras bibliotecas e frameworks JS.

Guillermo: O que significa criar uma estrutura para o React, significa que você faz do React a parte fundamental da história, espero que seja algo que tentaremos fazer com o Next.js, a curva de aprendizado é principalmente sobre o React com algumas superfície para Next.js, principalmente em relação à busca e roteamento de dados. Também fazemos muitas otimizações de produção, então quando você obtém o React, quando você obtém o aplicativo Create React, que é tipo, eu gosto de chamá-lo de um carro inicial que o Facebook oferece, talvez as necessidades de produção não sejam realmente atendidas . Ou se você tentar fazer isso sozinho configurando o Webpack e o Babel e configurando a renderização do servidor e a geração estática, também é difícil montar um carro do zero. Next.js lhe dará essa configuração zero e também um conjunto de padrões otimizados para produção em torno da construção de grandes coisas com o React.

Drew: É como se quase colocasse uma espécie de ecossistema em torno do seu aplicativo React com uma coleção de ferramentas pré-configuradas para permitir que você-

Guilherme: Correto.

Drew: Comece a trabalhar e faça a geração de sites estáticos ou renderização ou roteamento de servidores.

Guillermo: Correto, e você usou uma palavra aí que é muito, muito chave para tudo isso, que está pré-configurada. Temos a sorte de chamar a atenção do Google Chrome como colaborador do Next.js. Uma das líderes deste projeto, sua coisa é que quando eles estavam trabalhando em frameworks internamente no Google, eles enfrentaram muitos dos mesmos problemas que a comunidade e o código aberto estão enfrentando hoje. Havia muitas iniciativas concorrentes diferentes no Google sobre como dimensionar e criar aplicativos da Web realmente de alto desempenho prontos para uso.

Guillermo: Você entraria como Googler e receberia uma estrutura com a qual criaria aplicativos realmente grandes, prontos para produção e de alto desempenho. Shubie fez parte de muitas dessas iniciativas, e o que ela descobriu é que há dois ingredientes principais para fazer uma estrutura ter sucesso em escala. Uma é a pré-configuração, o que significa que você vem para o trabalho, vai iniciar um aplicativo totalmente novo, deve receber algo que já está pronto para ser usado e atende a muitas demandas de produção conhecidas naquele momento em tempo.

Guillermo: Por outro lado, o outro passo muito importante para o qual estamos trabalhando é a conformidade. Você pode receber a estrutura pré-configurada pronta para produção mais altamente otimizada, mas se você for em frente e, por exemplo, começar a introduzir muitas dependências pesadas ou scripts de terceiros ou usar layouts muito ineficientes que levam muito tempo para pintar e assim por diante e assim por diante, então você fará com que essa pré-configuração seja desperdiçada. Ao misturar a pré-configuração com a conformidade ao longo do tempo, o desenvolvedor não está apenas tendo um ótimo ponto de partida, mas também é guiado para o sucesso ao longo do tempo.

Drew: Parece que uma característica do Next.js, que é bastante opinativo, a camada de interface do usuário é React, usa type script, usa Webpack, e essas são todas as escolhas que o projeto fez e é isso que você obtém. Corrija-me se estiver errado, mas você não pode trocar React por Vue, por exemplo, dentro do Next.js.

Guillermo: Esse é um bom ponto, onde a tomada de decisão técnica encontra uma espécie de arte. Por um lado, eu realmente gostaria de afirmar que Next é muito sem opinião, e a razão para isso é que se você for especificamente para github.com/vercel/nextjs e o diretório de exemplos, verá que há quase como um explosão combinatória de tecnologias que você pode usar junto com o Next.js. Você verá baseado em fogo, verá Graphic UL, verá Apollo, verá Redux, verá MobX, no espaço CSS há ainda mais opções.

Guillermo: Nós temos uma porta CSS padrão que está embutida, mas então você pode usar dois tipos dela, uma com importação, outra com tags de estilo que chamamos de Style JSX, que se assemelha muito à abordagem de plataforma web para Shadow CSS. A razão pela qual quero dizer sem opinião é que queremos que o Next.js fique muito próximo do “bare metal” da web, e não introduza muitos primitivos com os quais a web de 10 anos a partir de hoje seria incompatível. Então, se você observar os exemplos, verá que há todas essas outras tecnologias que você pode conectar.

Guillermo: O nível básico de opinião é que existe o React e você não poderá substituí-lo, pelo menos tão cedo. Depois, há o conceito de que você deve ser capaz de criar páginas, e isso era uma coisa nova quando o lançamos pela primeira vez, que era todo mundo tentando criar aplicativos de página única. O que percebemos é que a internet é composta de sites com muitas páginas que criam pontos de entrada distintos por meio de mecanismos de busca, pelo Twitter, pelo Facebook, pelas redes sociais, por meio de companheiros de e-mail, como você sempre orienta a pessoa em direção a um ponto de entrada, e essa pessoa que passa por esse ponto de entrada não precisa baixar o ônus da totalidade do aplicativo.

Guillermo: Então esse caminho nos levou a implementar a renderização do servidor, depois a geração estática para várias páginas, etc., etc. Esse outro nível básico de opinião é o Next deve ser uma estrutura que funcione para a web, não contra a web. Então, além disso, o React estava faltando os primitivos de busca e roteamento de dados, e nós os adicionamos. Há um nível de opinião com o qual todo mundo precisa de um roteador, então é melhor ter um roteador embutido por padrão.

Drew: A grande vantagem de ter esses padrões é que tira muito da complexidade da escolha, que está lá, está configurado, e você pode começar a usá-lo sem precisar pensar muito, porque acho que todos nós -

Guilherme: Exatamente.

Drew: Já estive em situações em que há muitas opções de quais componentes usar, e isso pode ser esmagador e atrapalhar a produtividade.

Guilherme: Exatamente.

Drew: Para que tipo de projetos você vê as pessoas usando o Next.js? É basicamente para qualquer situação em que você possa criar um aplicativo React de produção ou é mais adequado para tipos específicos de sites pesados ​​de conteúdo? Importa nesse sentido?

Guillermo: Sim, então este tem sido um debate antigo da web, é a web para aplicativos, é a web para sites, é um híbrido? Qual é o papel do JavaScript, et cetera, et cetera? É meio difícil dar uma resposta direta, mas minha opinião sobre isso é que a web sempre evoluiu para ser um híbrido de conteúdo que está evoluindo para ser cada vez mais dinâmico e pessoal para o usuário. Mesmo quando você diz como um site de conteúdo, os sites de conteúdo de ponta do mundo têm bases de código que são muito comparáveis ​​aos aplicativos.

Guillermo: Um ótimo exemplo aqui é como o New York Times, eles te dão widgets embutidos com ferramentas de análise de dados e animação interativa, e eles recomendam qual história ler em seguida, e eles têm um modelo de assinatura embutido que às vezes te dá parte do conteúdo e às vezes conta quantos artigos você leu. Como se eu dissesse isso quando a web foi inventada, como Tim Berners-Lee diria: “Não, isso é loucura, isso não é possível na web”, mas essa é a web que temos hoje.

Guillermo: O Next.js está respondendo a muitas dessas complexas necessidades modernas, o que significa que você verá muito uso de e-commerce, você verá muito conteúdo com isso. E-commerce significa, a propósito, não apenas comprar itens, mas experiências como os maiores sites imobiliários da web, realtor.com, zillow.com, trulio.com, toda a categoria é Next.js, então conteúdo locais. Acabamos de integrar o washingtonpost.com como cliente da Vercel e Next.js, temos então uma terceira categoria que é mais emergente, mas muito interessante, que são aplicativos completos e conteúdo gerado pelo usuário, como tiktok.com, e mais ou menos como você pensaria que o caso de uso do aplicativo de página única original também está bem representado lá.

Guillermo: Next.js meio que brilha quando você precisa ter muito conteúdo que precisa ser servido muito, muito rapidamente, tem que ser otimizado para SEO e, no final das contas, é uma mistura de dinâmico e estático.

Drew: Eu já falei com Marcy Sutton sobre Gatsby, que parece estar em um tipo similar de espaço. É sempre bom ver mais de uma solução para um problema e poder escolher entre um projeto e outro. Você diria que Next.js e Gatsby estão operando no mesmo tipo de espaço de problema, e quão semelhantes ou diferentes eles são?

Guillermo: Acho que há uma sobreposição para alguns casos de uso. Por exemplo, meu blog pessoal rauchg.com roda em Next.js, poderia ter sido apenas um ótimo blog Gatsby também. Há essa sobreposição no tipo de espaço menor do site estático e, por pequeno, não quero dizer que não seja relevante. Muitas pontocoms que são super, super importantes são executadas basicamente na web estática, então essa é a beleza do Jamstack na minha opinião. Como o Next.js pode otimizar suas páginas estaticamente e, em seguida, você pode obter ótimas pontuações do Lighthouse com isso, você pode usá-lo para casos de uso sobrepostos.

Guillermo: Eu acho que a linha é traçada quando você começa a entrar em necessidades mais dinâmicas e você tem muitas páginas, você tem a necessidade de atualizá-las de uma só vez. Embora Gatsby esteja criando soluções para isso, o Next.js já tem soluções prontas para produção que funcionam com qualquer tipo de banco de dados, qualquer tipo de backend de dados para basicamente “gerar” ou “imprimir” muitas e muitas páginas. É onde hoje os clientes vão para o Next.js em vez do Gatsby.

Drew: Um dos problemas que todos parecem se deparar à medida que sua solução baseada em JavaScript aumenta é o desempenho e como as coisas podem começar a ficar muito lentas, você tem grandes tamanhos de pacotes. Tradicionalmente, coisas como divisão de código podem ser bastante complexas para serem configuradas corretamente. Vejo que esse é um dos recursos que me chamou a atenção do Next.js, que afirma que a divisão de código é automática. O que o Next.js faz em termos de divisão de código para que isso funcione?

Guillermo: Sua observação está 100% correta. Uma das maiores coisas da web e um dos maiores pesos na web é o JavaScript, e assim como materiais diferentes têm densidades e pesos diferentes, independentemente do volume físico real, o JavaScript tende a ser um elemento muito denso e pesado. Mesmo pequenas quantidades de JavaScript em comparação com, por exemplo, imagens que podem ser processadas de forma assíncrona e fora do encadeamento principal, o JavaScript tende a ser particularmente incômodo.

Guillermo: A Next.js investiu muito esforço para otimizar automaticamente seus pacotes. A primeira que foi minha primeira intuição quando tive a ideia do Next.js foi você definir, por exemplo, 10 rotas. No mundo Next.js, você cria um diretório de páginas e coloca seus arquivos nele Index.js, About.js, Settings.js, Dashboard.js, Termsofservice.js, Signup.js, Login.js. Esses se tornam pontos de entrada para seu aplicativo que você pode compartilhar por meio de todos os tipos de mídia.

Guillermo: Quando você os insere, queremos fornecer a você o JS relevante para essa página em primeiro lugar, e talvez um pacote comum para que as navegações subsequentes no sistema sejam muito rápidas. Next.js também, que é muito, muito bom, pré-busca automaticamente o restante das páginas que estão conectadas a esse ponto de entrada, de modo que pareça um aplicativo de página única. Muitas pessoas dizem como: “Por que não usar o aplicativo Create React se eu sei que tenho talvez algumas rotas?” Eu sempre digo a eles: “Olha, você pode encontrá-los como páginas e, como o Next.js pré-busca automaticamente os que estão conectados, você acaba obtendo seu aplicativo de página única, mas é melhor otimizado em relação à pintura inicial , esse ponto de entrada inicial.”

Guillermo: Essa foi a abordagem inicial de divisão de código, mas depois se tornou muito mais sofisticada com o tempo. O Google contribuiu com uma otimização muito bacana chamada Module and No Module, que dará JS diferencial para navegadores modernos, e JS legado que é pesado com polyfields para outros navegadores, e essa otimização 100% automatizada e produz uma economia enorme. Demos para um cliente nosso que hospedamos na Vercel chamado Parnaby's, acho que se não me engano foi algo muito, muito significativo. Foi talvez uma economia de 30% em tamanhos de código, e isso foi apenas porque eles atualizaram o Next.js para uma versão que otimizava melhor os pacotes JS.

Guillermo: Esse foi o ponto que estávamos analisando anteriormente, que é você escolher o Next.js e ele só fica melhor e mais otimizado com o tempo, continuará otimizando as coisas em seu nome. Essas são, novamente, pré-configurações com as quais você nunca teria que lidar ou se incomodar, e cuja pesquisa você nem quer fazer, para ser honesto. Como se eu não estivesse obviamente muito envolvido com isso, mas eu olhei para algumas das discussões internas e eles estavam discutindo todos esses policampos que só importavam para o Internet Explorer X e o Soho, eu estava tipo, "Eu nem quero saber , vamos apenas atualizar o Next.js e obter todos esses benefícios.”

Drew: Às vezes há grandes benefícios em manter os padrões e manter a configuração mais comum das coisas, o que parece ser realmente a abordagem Next.js. Lembro-me de quando comecei a escrever PHP no início dos anos 2000, e todo mundo estava usando PHP e MySQL, e na época eu tinha acabado de sair do Windows, então queria usar PHP e Microsoft Sequel Server. Você pode fazer isso, mas está nadando contra a maré o tempo todo. Então, assim que mudei para o MySQL, todo o ecossistema começou a funcionar para mim e não precisei pensar sobre isso.

Guillermo: Sim, tudo se encaixa, essa é uma ótima observação. Vemos isso o tempo todo, como se o ecossistema Babel fosse tão poderoso agora que você poderia se tornar, por exemplo, um pouco mais rápido trocando o Babel por outra coisa, mas depois troca essa incrível compatibilidade com o ecossistema. Isso é algo que você tocou no desempenho anteriormente e, como para muitas pessoas, o desempenho de compilação e o desempenho de geração estática são um grande gargalo, e isso é algo em que somos muito diligentes em melhorar o desempenho de nossas ferramentas de forma incremental.

Guillermo: Por exemplo, uma das coisas que o Next.js está fazendo agora é atualizar seu padrão do Webpack 4 para o Webpack 5, que tem algumas coisas interessantes, e é por isso que estamos oferecendo primeiro às pessoas como opção. em flag, mas mais tarde se tornará o padrão. O Webpack 5 traz melhorias de desempenho incríveis, mas não estamos sacrificando o ecossistema do Webpack, melhoramos de forma incremental. Claro, havia algumas coisas muito pequenas que precisavam ser sacrificadas, mas esse é um benefício incrível do ecossistema JS hoje que muitas pessoas estão ignorando, eu acho, porque talvez eles vejam: “Oh, poderíamos ter feito X no Soho, talvez fosse um pouco mais rápido, ou talvez o MPM no Soho levasse menos tempo.” Eles captam alguns detalhes e perdem a visão geral, que é o valor do ecossistema é enorme.

Drew: O valor de ter toda a configuração e manutenção e esse lado feito por um projeto como o Next.js, em vez de assumir isso por si mesmo, trocando para usar outra coisa, é incrível, porque assim que você se afasta desses padrões , você está assumindo o ônus de manter todas as compatibilidades e fazer isso sozinho. Uma das coisas que realmente me interessam com o Next.js é que existem opções disponíveis para geração de site estático ou renderização do lado do servidor, ou talvez um híbrido dos dois. Acho que houve algumas mudanças recentes em uma atualização recente, você pode nos contar um pouco sobre isso e quando você pode escolher um ou outro?

Guilherme: Sim, com certeza. Um dos principais componentes dessa abordagem híbrida combinada com o sistema de páginas que descrevi anteriormente é que você pode ter páginas totalmente estáticas ou páginas renderizadas pelo servidor. Uma página totalmente estática tem o incrível benefício do que chamo de içamento estático, que é você pegar esse ativo e colocá-lo automaticamente na borda. Ao colocá-lo na borda, quero dizer que você pode armazená-lo, pode armazená-lo preventivamente, pode replicá-lo, pode fazer com que, quando uma solicitação chegar, ela nunca toque o servidor porque sabemos com antecedência, “ Ei, Slash Index é uma estática.”

Guillermo: Esse é um benefício muito, muito interessante quando se trata de atender ao público global. Você basicamente obtém uma CDN automática pronta para uso, especialmente quando implanta as redes de borda modernas como Vercel ou AWS Amplify ou Netlify e assim por diante. Next.js tem essa premissa de que se pode ser estático, deve ser estático. Quando você está começando um projeto e está trabalhando em sua primeira página ou está chutando os pneus do framework, pode muito bem tornar tudo estático.

Guillermo: Mesmo para necessidades de ponta, por exemplo, vercel.com, nosso próprio uso do Next.js é totalmente estático. É uma combinação de geração de site totalmente estático e estático, então todas as nossas páginas de marketing são estáticas, nosso blog é gerado estaticamente a partir de uma fonte de dados dinâmica e, em seguida, nosso painel tem muitos dados dinâmicos, mas podemos entregá-los como shells ou esqueletos , todas as páginas associadas à visualização de suas implantações, visualização de seus projetos, visualização de seus logs, etc., etc., são basicamente páginas estáticas com JavaScript do lado do cliente.

Guillermo: Isso nos serve incrivelmente bem porque tudo que precisamos de um desempenho muito rápido no primeiro painel já está pré-renderizado, tudo que precisa de SEO, já pré-renderizado, e tudo que é extremamente dinâmico, só temos que nos preocupar com segurança, por por exemplo, da perspectiva do lado do cliente que usa as mesmas chamadas de API que, por exemplo, nossa CLI usou ou nossas integrações usam, etc., etc. Um site totalmente estático, muito barato de operar, incrivelmente escalável e assim por diante.

Guillermo: Agora, uma coisa em particular que precisávamos com nosso blog era que queríamos atualizar os dados muito rapidamente. Queríamos corrigir um erro de digitação muito rapidamente e não esperar que uma compilação inteira acontecesse, e esse é um benefício muito significativo do Next.js, que, à medida que você passa de um estático para um dinâmico, ele também oferece essas soluções intermediárias . Para nosso blog, usamos geração estática incremental, portanto, essencialmente, podemos reconstruir uma página de cada vez quando o conteúdo subjacente muda.

Guillermo: Imagine que não tivéssemos apenas algumas centenas de posts de blog e tivéssemos muitos posts de blog sendo gerados e atualizados o tempo todo, como mencionei um de nossos clientes, o Washington Post, nesse caso você precisa ir mais em direção ao SSR completo, especialmente quando você começa a personalizar o conteúdo para cada usuário. Essa jornada de complexidade que acabei de descrever começou com uma página de marketing, um blog com algumas milhares de páginas, dezenas de milhares ou milhões de páginas. Essa é a jornada do Next.js que você pode percorrer com seu próprio negócio.

Guillermo: Então você começa como desenvolvedor para escolher entre talvez menos responsabilidade para mais responsabilidade, porque quando você opta por usar SSR, agora você está executando código no servidor, está executando código na nuvem, há mais responsabilidade com mais poder. O fato de você poder decidir onde usar cada tipo de ferramenta é um benefício muito, muito interessante do Next.

Drew: Apenas nos aspectos práticos de combinar a geração estática do site e a renderização do lado do servidor, como isso funciona em termos do elemento servidor? Você está precisando de uma plataforma dedicada como a Vercel para conseguir isso ou é algo que pode ser feito de forma mais direta e simples?

Guillermo: O Next.js oferece um servidor de desenvolvimento, então você baixa o Next e executa seu Next Dev, e esse é o servidor dev. O servidor dev é obviamente incrivelmente otimizado para desenvolvimento, como se tivesse a mais recente tecnologia de atualização rápida que o Facebook lançou, onde… Na verdade, o Facebook não o lançou, o Facebook o usa internamente para obter a melhor e mais confiável substituição de módulo quente , de modo que você está basicamente digitando e as mudanças estão refletindo na tela, então esse é o servidor dev.

Guillermo: O Then Next oferece um servidor de produção chamado Next Start, e o Next Start tem todos os recursos do framework para auto-hospedagem. O interessante sobre o Vercel é que quando você implanta o Next nele, ele é otimizado automaticamente e é 100% serverless, o que significa que não há nenhuma responsabilidade de administração, dimensionamento, desconto e validação de desconto, purga, replicação, failover global e assim por diante e assim por diante que você teria que assumir quando executasse o Next Start por conta própria.

Guillermo: Esse também é o grande benefício do Next.js, então, por exemplo, apple.com tem várias propriedades, subdomínios e páginas diferentes em pontocom no Next.js que eles auto-hospedam, devido a necessidades de segurança e privacidade muito, muito avançadas e rigorosas . Por outro lado, washingtonpost.com usa Vercel, então temos esse tipo de ampla gama de usuários e estamos extremamente felizes em oferecer suporte a todos eles. O bom de onde o serverless está indo, na minha opinião, é que ele pode oferecer o melhor dos dois mundos em termos de desempenho ideal que só melhora com o tempo, com a melhor experiência de desenvolvedor do tipo: “Ei, eu não tenho se preocupar com qualquer tipo de infraestrutura.”

Drew: O Next.js é um projeto de código aberto que está sendo desenvolvido pela equipe da Vercel. Existem outros colaboradores fora da Vercel?

Guillermo: Sim, então o Google Chrome sendo o principal que envia PRs de servidor ativamente, nos ajuda com otimizações e testando com parceiros, como usuários muito grandes do Next.js que já fazem parte do ecossistema do Google, por exemplo, devido ao uso de muitos e muitos aplicativos, então eles precisam estar envolvidos de perto como parceiros. Facebook, mantemos um ótimo relacionamento com a equipe do Facebook. Por exemplo, atualização rápida, fomos a primeira estrutura React a conseguir isso, e eles ajudaram a nos guiar por todas as coisas que aprenderam sobre o uso do React e a atualização rápida no Facebook.

Guillermo: Trabalhamos com muitos parceiros que têm implantações muito grandes de aplicativos Next.js em estado selvagem de todos os tipos diferentes de casos de uso, como imaginar comércio eletrônico e conteúdo. Depois, há muitos e muitos colaboradores independentes, pessoas que usam o Next.js pessoalmente, mas também educadores e membros de equipes de infraestrutura de frente em grandes empresas. É um esforço comunitário muito, muito amplo.

Drew: Parece a preocupação que alguém pode ter, que isso está sendo desenvolvido em uma parte significativa pela Vercel, que eles podem ter a preocupação de que vão ficar presos na implantação nessa plataforma em particular, mas parece muito parecido com isso não é o caso, e eles poderiam desenvolver um site e implantá-lo no Firebase ou Netlify ou…

Guilherme: Sim, com certeza. Gosto muito de compará-lo com o Kubernetes da era do Front End de certa forma, porque no final das contas acredito firmemente que … Kubernetes é algo que praticamente todo mundo precisa quando precisa executar processos Linux , como você estava falando sobre opinião e você está dizendo que é uma boa tecnologia, não é muito opinativo, mas há alguma opinião que nós meio que esquecemos. É como se, no final das contas, ele crescesse a partir da execução de demônios específicos de programas Linux empacotados como contêineres.

Guillermo: O próximo está em uma posição semelhante, porque o que consideramos o primitivo universal do mundo como um componente React, obviamente é opinativo, mas achamos que para muitas empresas, assim como todas gravitam em direção ao Linux, estamos vendo a mesma coisa para React e Vue, mas Vue felizmente tem Nuxt também, que é uma solução muito incrível, é equivalente em ideação e princípios como Next. Estamos gravitando para essas plataformas como Next.js, como Nuxt, como Sapper para o ecossistema Svelte.

Guillermo: Acho que deveriam ser plataformas abertas, porque novamente, se todo mundo vai precisar disso, é melhor não reinventar a roda em toda a indústria, certo? Saudamos muito essa posição, convidamos as pessoas a implantá-la, reconfigurá-la, reconstruí-la e redistribuí-la e assim por diante.

Drew: Recentemente uma nova versão do Next.js foi lançada, acho que a versão 9.5. Que mudanças significativas ocorreram nesse lançamento?

Guillermo: O mais incrível é, como eu estava dizendo antes, muitas coisas começam estáticas e depois se tornam mais dinâmicas à medida que as coisas crescem. Este foi o empreendimento para o WordPress, a propósito. O WordPress no início era baseado em uma abordagem de banco de dados de arquivo estático e, em seguida, cresceu precisando de um banco de dados, como o que você descreveu com como o PHP evoluiu para ser cada vez mais MySQL. O que é bom sobre o Next.js 9.5 é que ele torna a geração estática incremental um recurso pronto para produção, então nós o tiramos do sinalizador instável.

Guillermo: Esse recurso permite que você faça essa jornada de estático para dinâmico sem abrir mão de todos os benefícios estáticos e sem ter que ficar cheio para a dinâmica renderizada pelo servidor, estendendo a vida útil do seu tipo de estática. A maneira como o usamos na Vercel, por exemplo, como mencionei, é como se nosso blog fosse totalmente pré-renderizado no momento da construção, mas, por exemplo, estamos em alguns minutos prestes a fazer um grande anúncio e, quando nós blogamos sobre isso, queremos ser capazes de ajustá-lo, corrigi-lo, visualizá-lo, etc., sem ter que emitir uma compilação de cinco a 10 minutos toda vez que alterarmos uma letra de uma postagem no blog.

Guillermo: Com a geração estática incremental, você pode reconstruir uma página por vez. O que poderia levar minutos ou até segundos, dependendo do tamanho do seu site, agora leva milissegundos. Novamente, você não teve que desistir de nenhum dos benefícios da estática. Talvez seja isso que me deixa mais empolgado que ficou estável no Next.js 9.5, e especificamente porque a comunidade JS e a comunidade React e a comunidade framework e a comunidade gerada por site estático têm falado sobre esse unicórnio de fazer um incremental estático para a long time, so the fact that Next.js did it, it's being used in production and it's there for everybody to use, I think it's a major, major, major milestone.

Guillermo: There's lots of little DX benefits. One that's really nice in my opinion is Next.js, as I said, has a page system. You would argue, “Okay, so let's say that I'm uber.com and I've decided to migrate on Next.js, do I need to migrate every URL inside over to Next.js in order to go live?” This has become a pretty important concern for us, because lots of people choose Next.js, but they already are running big things, so how do you reconcile the two?

Guillermo: One of the things that Next.js allows you to do in 9.5 is you can say, “I want to handle all new pages that I created with Next.js with Next.js, and the rest I want to hand off to a legacy system.” That allows you incremental, incremental is the keyword here today, incremental adoption of Next.js. You can sort of begin to strangle your legacy application with your Next.js optimized application one page at a time, when you deploy and you introduce in your Next.js page, it gets handled by Next. If it doesn't match the Next.js routing system, it goes to the legacy system.

Drew: That sounds incredibly powerful, and the incremental rendering piece of that, I can think of several projects immediately that would really benefit that have maybe 30-minute build times for fixing a typo, as you say. That sort of technology is a big change.

Guillermo: We talked to one of the largest, I believe, use cases in Jamstack in the wild, and it was basically a documentation website and their build times were 40 minutes. We're doing a lot in this space, by the way, like we're making pre-rendering a lot faster as well. One of my intuitions for years to come is that as platforms get better, as the primitives get better, as the build pipelines get better we're going to continue to extend the useful lifetime of statics. Like what ended up taking 40 minutes is going to take four.

Guillermo: A great example is we're rolling out an incremental build cache, as well, system. I sort of pre-announced it on Twitter the other day, we're already seeing 5.5 times faster incremental builds. One of the things that I like about Jamstack is that the core tenet is pre-render as much as possible. I do think that's extremely valuable, because when you're pre-rendering you're not rendering just in time at runtime. Like what otherwise the visitor would incur in in terms of rendering costs on the server gets transferred to build time.

Guillermo: One of the most exciting things that's coming to Next is that without you doing anything as well, the build process is also getting faster. On the Vercel side, we're also taking advantage of some new cloud technology to make pre-rendering a lot faster as well. I think we're always going to live in this hybrid world, but as technology gets better, build times will get better, pre-rendering will get better and faster, and then you'll have more and more opportunities to do kind of a mix of the two.

Drew: Sounds like there's some really exciting things coming in the future for Next.js. Is there anything else we should know before we sort of go away and get started working with Next.js?

Guillermo: Yeah. I think for a lot of people for whom this is new, you can go to nextjs.org/learn, it'll walk you through building your first small static site with Next.js, and then it'll walk you through the journey of adding more and more complexity over time, so it's a really fun tutorial. I recommend also staying tuned for our announcement that I was just starting to share on twitter.com/vercel, where we share a lot of Next.js news. Specifically we highlight a lot of the work that's being done on our open source projects and our community projects and so on. For myself as well, twitter.com/rauchg if you want to stay on top of our thoughts on the ecosystem.

Drew: I've been learning all about Next.js today, what have you been learning about lately, Guillermo?

Guillermo: As a random tangent that I've been learning about, I decided to study more economics, so I've been really concerned with like what is the next big thing that's coming in terms of enabling people at scale to live better lives. I think we're going through a transition period, especially in the US, of noticing that a lot of the institutions that people were “banking on”, like the education system, like the healthcare system, a lot of those, like where you live and whether you're going to own a house or rent and things like that, a lot of these things are changing, they have changed rapidly, and people have lost their compass.

Guillermo: Things like, “Oh, should I go to college? Should I get a student loan?” and things like that, and there is a case to be made for capitalism 3.0, and there is a case to be made for next level of evolution in social and economic systems. I've been just trying to expand my horizons in learning a lot more about what could be next, no pun intended. I've found there's lots of great materials and lots of great books. A lot of people have been thinking about this problem, and there is lots of interesting solutions in the making.

Drew: Isso é fascinante. If you, dear listener, would like to hear more from Guillermo, you can find him on Twitter at @RauchG, and you can find more about Next.js and keep up to date with everything that goes on in that space at nextjs.org. Thanks for joining us today, Guillermo. Você tem alguma palavra de despedida?

Guillermo: No, thank you for having me.