Smashing Podcast Épisode 23 Avec Guillermo Rauch : Qu'est-ce que Next.js ?

Aujourd'hui, nous parlons de Next.js. De quoi s'agit-il et où pourrait-il s'intégrer dans notre flux de travail de développement Web ? J'ai parlé au co-créateur Guillermo Rauch pour le savoir.

Afficher les remarques

• Guillermo Rauch sur Twitter
• Suivant.js

Mise à jour hebdomadaire

• "Maîtriser les accessoires et les types d'accessoires dans React"
  par David Adeneye
• "Des décisions de conception inspirées avec Bradbury Thompson : l'art du design graphique"
  par Andy Clarke
• "Configuration d'une API à l'aide de Flask, Cloud SQL et App Engine de Google"
  par Wole Oyekanmi
• "Formulaires et validation dans Ionic React"
  par Jerry Navi
• "Comment aider vos clients à obtenir plus de backlinks grâce à la conception"
  par Suzanne Scacca

Transcription

Drew McLellan : Il est le fondateur et PDG de Vercel, une plate-forme cloud pour les sites statiques qui s'intègre dans un flux de travail Jamstack. Il est également co-créateur de Next.js. Il a précédemment fondé LearnBoost et CloudUp, et est bien connu comme le créateur de plusieurs bibliothèques open source de nœuds populaires comme Socket.io, Mongoose et SlackIn. Avant cela, il était développeur principal sur MooTools, nous savons donc qu'il connaît JavaScript comme sa poche. Saviez-vous qu'il a reçu une fois une commission royale du roi d'Espagne pour créer une sculpture de glace à partir de laitue iceberg ? Mes amis fracassants, veuillez accueillir Guillermo Rauch. Salut Guillermo, comment vas-tu ?

Guillermo Rauch : Je suis super bon, merci de m'avoir invité.

Drew : Je voulais vous parler aujourd'hui de tout le monde de Next.js, car c'est quelque chose que vous connaissez évidemment personnellement très bien, ayant été impliqué en tant que co-créateur dès le début. Next.js est l'un de ces noms de projet qui a été sur mon radar lorsque je travaillais dans l'espace Jamstack, mais ce n'est pas quelque chose que j'ai personnellement examiné ou travaillé de trop près auparavant. Pour les personnes comme moi, qui ne savent peut-être pas ce qu'est Next.js, vous pourriez peut-être nous donner un aperçu de ce que c'est et des problèmes qu'il tente de résoudre.

Guillermo : Next.js est un membre très intéressant de l'univers Jamstack, car Next.js a en fait commencé à être un cadre entièrement axé sur la SSR. Il a commencé à être beaucoup adopté en dehors de l'espace Jamstack où les gens construisaient de très grandes choses spécifiquement lorsqu'ils voulaient avoir du contenu généré par l'utilisateur ou du contenu dynamique ou des réseaux sociaux ou du commerce électronique, et ils savaient qu'ils voulaient SSR parce que leur ensemble de données était très grand ou très dynamique. Il est tombé sous le radar, je pense, pour beaucoup de gens dans le monde Jamstack, mais plus tard, Next.js a acquis les capacités d'optimisation statique.

Guillermo : D'une part, par exemple, si vous ne faisiez pas de récupération de données au niveau supérieur de votre page avec Next.js, votre page React serait… Aussi d'ailleurs, pour ceux qui ne sont pas tout à fait au courant, Next.js est simplement un framework React pour la production, mais a cette capacité de faire du rendu. Ensuite, lorsque vous obtenez des capacités d'optimisation statique, si vous ne définissez pas la récupération des données au niveau supérieur de votre page, elle sera automatiquement exportée au format HTML au lieu d'essayer de faire quoi que ce soit avec le rendu du serveur.

Guillermo : Plus tard, il a également acquis la capacité de générer des sites statiques, ce qui signifie que vous pouvez définir un crochet de données spécial, mais ce crochet de données obtient des données au moment de la construction. Next.js est devenu un framework dynamique et statique hybride, très puissant, et maintenant il se développe également beaucoup dans l'espace Jamstack.

Drew : Les gens pourraient dire que React est déjà un cadre, vous l'entendez certainement décrit de cette façon. Que signifie réellement être un framework pour React ?

Guillermo : C'est une excellente observation, car je fais toujours remarquer aux gens que React sur Facebook et React en dehors de Facebook sont des bêtes complètement différentes. React sur Facebook est en fait utilisé avec le rendu de serveur, mais même leur rendu de serveur, par exemple, n'utilise pas Node.js, il utilise une machine virtuelle hautement spécialisée appelée Hermes qui communique avec leur type de hack de production et de pile PHP et répond tous ces besoins avancés et exotiques de Facebook.

Guillermo : Quand ils open source React, c'est presque comme si l'on achetait un composant en open source. Je l'appelle toujours comme l'open source du moteur, mais sans vous donner la voiture. Ce qui s'est passé, c'est que les gens voulaient vraiment aller conduire avec, ils voulaient se rendre à des endroits avec React. Dans la communauté, les gens ont commencé à créer des voitures, et ils intégraient React comme moteur, ce que le conducteur, le développeur recherchait en premier lieu, faisant de React la partie fondamentale de la voiture. Des choses comme Next.js et Gatsby et React Static et de nombreux autres frameworks ont commencé à apparaître qui résolvaient le besoin de "Je veux vraiment créer des pages et des applications entièrement chargées".

Guillermo : Alors que React ressemblait davantage au composant et au moteur de widgets spécifiques au sein de la page, c'était certainement le cas pour Facebook. Ils admettront largement et publiquement qu'ils l'ont inventé pour des choses comme le lot de notification, le widget de chat, le composant de fil d'actualité, et ces composants étaient des routes React qui ont été intégrées dans le contenu de l'application existante de production avec beaucoup, beaucoup de lignes de code et même d'autres bibliothèques et frameworks JS.

Guillermo: Ce que cela signifie de créer un cadre pour React, cela signifie que vous faites de React la partie fondamentale de l'histoire, espérons-le et c'est quelque chose que nous essaierons de faire avec Next.js, la courbe d'apprentissage concerne principalement React avec quelques éléments supplémentaires surface pour Next.js, en particulier autour de la récupération et du routage des données. Nous faisons également beaucoup d'optimisations de production, donc lorsque vous obtenez React, lorsque vous obtenez l'application Create React, qui est un peu comme, j'aime l'appeler une voiture amorcée que Facebook vous donne, peut-être que les besoins de production ne sont pas vraiment satisfaits . Ou si vous essayez de le faire vous-même en configurant Webpack et en configurant Babel et en configurant le rendu du serveur et la génération statique, il est également difficile de créer une voiture à partir de rien. Next.js vous donnera cette configuration zéro et également un ensemble de valeurs par défaut optimisé pour la production autour de la construction de grandes choses avec React.

Drew : C'est comme si cela mettait presque une sorte d'écosystème autour de votre application React avec une collection d'outils préconfigurés pour vous permettre de...

Guillermo : Exact.

Drew : Lancez-vous et faites de la génération de site statique ou du rendu ou du routage de serveur.

Guillermo : Exact, et vous avez utilisé un mot qui est très, très clé pour tout cela, qui est préconfiguré. Nous avons la chance d'attirer l'attention de Google Chrome en tant que contributeur de Next.js. L'un des leaders de ce projet, son truc, c'est que lorsqu'ils travaillaient sur des frameworks en interne chez Google, ils ont rencontré beaucoup des mêmes problèmes auxquels la communauté et l'open source sont confrontés aujourd'hui. Il y avait de nombreuses initiatives concurrentes chez Google sur la façon de faire évoluer et de créer des applications Web vraiment performantes prêtes à l'emploi.

Guillermo : Vous rejoindriez Googler et vous recevriez un cadre avec lequel vous créeriez de très grandes applications prêtes pour la production et très performantes. Shubie faisait partie d'un grand nombre de ces initiatives, et ce qu'elle a découvert, c'est qu'il y a deux ingrédients clés pour qu'un cadre réussisse à grande échelle. L'un est la pré-configuration, ce qui signifie que vous venez travailler, vous allez démarrer une toute nouvelle application, vous devriez recevoir quelque chose qui est déjà prêt à l'emploi et qui répond à de nombreuses exigences de production connues à ce moment donné à l'heure.

Guillermo : D'un autre côté, l'autre étape vraiment importante vers laquelle nous travaillons est la conformité. Vous pouvez recevoir le framework préconfiguré prêt pour la production le plus optimisé, mais si vous allez de l'avant et, par exemple, commencez à introduire de nombreuses dépendances lourdes ou des scripts tiers ou utilisez des mises en page très inefficaces qui prennent beaucoup de temps à peindre, etc. et ainsi de suite, alors vous allez perdre cette pré-configuration. En mélangeant la pré-configuration avec la conformité au fil du temps, le développeur dispose non seulement d'un excellent point de départ, mais il est également guidé vers le succès au fil du temps.

Drew : Il semble qu'une caractéristique de Next.js, c'est qu'il est assez opiniâtre, la couche d'interface utilisateur est React, elle utilise un script de type, utilise Webpack, et ce sont tous des choix que le projet a faits et c'est ce que vous obtenez. Corrigez-moi si je me trompe, mais vous ne pouvez pas échanger React pour Vue, par exemple, dans Next.js.

Guillermo : C'est un bon point, où la prise de décision technique rencontre une sorte d'art. D'une part, j'aimerais vraiment affirmer que Next est très sans opinion, et la raison en est que si vous allez spécifiquement sur github.com/vercel/nextjs et le répertoire des exemples, vous verrez qu'il y a presque comme un explosion combinatoire de technologies que vous pouvez utiliser avec Next.js. Vous verrez basé sur le feu, vous verrez Graphic UL, vous verrez Apollo, vous verrez Redux, vous verrez MobX, dans l'espace CSS, il y a encore plus d'options.

Guillermo : Nous avons un port CSS par défaut qui est intégré, mais vous pouvez ensuite en utiliser deux variantes, une avec importation, une avec des balises de style que nous appelons Style JSX, qui ressemble beaucoup à l'approche de la plate-forme Web pour Shadow CSS. La raison pour laquelle je veux dire sans opinion est que nous voulons que Next.js reste très proche du "bare metal" du Web et n'introduise pas de nombreuses primitives avec lesquelles le Web d'il y a 10 ans serait incompatible. Ensuite, si vous regardez les exemples, vous verrez qu'il y a toutes ces autres technologies que vous pouvez brancher.

Guillermo : Le niveau d'opinion de base est qu'il y a React et que vous ne pourrez pas le remplacer, du moins de sitôt. Ensuite, il y a le concept selon lequel vous devriez être capable de créer des pages, et c'était un peu comme une nouveauté lorsque nous l'avons lancé pour la première fois, à savoir que tout le monde essayait de créer des applications d'une seule page. Ce qu'on s'est rendu compte c'est qu'internet est composé de sites avec plein de pages qui créent des points d'entrée distincts via les moteurs de recherche, via Twitter, via Facebook, via les réseaux sociaux, via des compagnons de messagerie, comme on guide toujours la personne vers un point d'entrée, et cette personne qui passe par ce point d'entrée ne devrait pas avoir à télécharger la charge de l'intégralité de l'application.

Guillermo : Ensuite, ce chemin nous a amenés à implémenter le rendu serveur, puis la génération statique pour plusieurs pages, etc., etc. Cet autre niveau d'opinion de base est Next devrait être un cadre qui fonctionne pour le Web, pas contre le Web. Ensuite, en plus de cela, il manquait à React des primitives de récupération de données et de routage, et nous les avons ajoutées. Il y a un niveau d'opinion qui doit être traité comme tout le monde a besoin d'un routeur, alors autant avoir un routeur intégré par défaut.

Drew : Le gros avantage d'avoir ces valeurs par défaut est qu'elles enlèvent une grande partie de la complexité du choix, qu'elles sont juste là, qu'elles sont configurées, et que vous pouvez simplement commencer à les utiliser sans trop réfléchir, car je pense que nous avons tous -

Guillermo : Exactement.

Drew : J'ai été dans des situations où il y a beaucoup trop de choix de composants à utiliser, et cela peut être écrasant et entraver la productivité.

Guillermo : Exactement.

Drew : Pour quel type de projets voyez-vous les gens utiliser Next.js ? Est-ce pour pratiquement n'importe quelle situation dans laquelle vous pourriez créer une application React de production, ou est-elle plus adaptée à des types particuliers de sites lourds de contenu ? Est-ce important dans ce sens ?

Guillermo : Oui, c'est donc un vieux débat sur le Web, le Web est-il pour les applications, le Web est-il pour les sites, est-ce un hybride ? Quel est le rôle de JavaScript, etc., etc. ? C'est un peu difficile de donner une réponse directe, mais mon point de vue est que le Web a toujours évolué pour devenir un hybride de contenu qui évolue pour être de plus en plus dynamique et personnel pour l'utilisateur. Même lorsque vous dites comme un site Web de contenu, les sites Web de contenu haut de gamme du monde ont des bases de code qui sont très comparables aux applications.

Guillermo : Un bon exemple ici est comme le New York Times, ils vous donneront des widgets intégrés avec des outils d'analyse de données et une animation interactive, et ils vous recommanderont quelle histoire lire ensuite, et ils ont un modèle d'abonnement intégré qui vous donne parfois partie du contenu et compte parfois le nombre d'articles que vous avez lus. Comme si je vous disais ça quand le web a été inventé, comme dirait Tim Berners-Lee : « Non, c'est fou, ce n'est pas possible sur le web », mais c'est le web que nous avons aujourd'hui.

Guillermo : Next.js répond à beaucoup de ces besoins modernes complexes, ce qui signifie que vous verrez beaucoup d'utilisation du commerce électronique, vous verrez beaucoup de contenu avec ça. Le commerce électronique signifie, en passant, pas seulement comme acheter des articles, mais des expériences comme les plus grands sites Web immobiliers sur le Web, realtor.com, zillow.com, trulio.com, cette catégorie entière est entièrement Next.js, puis le contenu des sites. Nous venons d'embarquer washingtonpost.com en tant que client de Vercel et Next.js, nous avons alors une troisième catégorie qui est plus émergente mais très intéressante, qui est des applications complètes et du contenu généré par les utilisateurs, comme tiktok.com, et un peu comme vous penserait que le cas d'utilisation original de l'application d'une seule page y est également bien représenté.

Guillermo : Next.js brille en quelque sorte lorsque vous avez besoin d'avoir beaucoup de contenu qui doit être servi très, très rapidement, doit être optimisé pour le référencement, et en fin de compte, c'est un mélange de dynamique et de statique.

Drew: J'ai déjà parlé à Marcy Sutton de Gatsby, qui semble être dans un espace similaire. C'est toujours agréable de voir plus d'une solution à un problème et d'avoir le choix d'un projet à l'autre. Diriez-vous que Next.js et Gatsby opèrent dans le même type d'espace problématique, et dans quelle mesure sont-ils similaires ou différents ?

Guillermo : Je pense qu'il y a un chevauchement pour certains cas d'utilisation. Par exemple, mon blog personnel rauchg.com fonctionne sur Next.js, cela aurait pu être aussi un super blog Gatsby. Il y a ce chevauchement dans le plus petit espace de site Web statique, et par petit, je ne veux pas dire non pertinent. Beaucoup de dotcoms qui sont super, super importants fonctionnent sur un Web essentiellement statique, c'est donc la beauté de Jamstack à mon avis. Étant donné que Next.js peut optimiser statiquement vos pages et que vous pouvez ensuite obtenir d'excellents scores Lighthouse grâce à cela, vous pouvez l'utiliser pour des cas d'utilisation qui se chevauchent.

Guillermo : Je pense que la limite est tracée lorsque vous commencez à avoir des besoins plus dynamiques et que vous avez beaucoup de pages, vous devez les mettre à jour en même temps. Bien que Gatsby crée des solutions pour ceux-ci, Next.js a déjà des solutions en direct prêtes pour la production qui fonctionnent avec n'importe quel type de base de données, n'importe quel type de backend de données pour essentiellement "générer" ou "imprimer" beaucoup et beaucoup de pages. C'est là qu'aujourd'hui les clients se tournent vers Next.js au lieu de Gatsby.

Drew : L'un des problèmes que tout le monde semble rencontrer à mesure que leur solution basée sur JavaScript s'agrandit est la performance et la façon dont les choses peuvent commencer à devenir assez lentes, vous avez de grandes tailles de bundles. Traditionnellement, des choses comme le fractionnement de code peuvent être assez complexes pour être configurées correctement. Je vois que c'est l'une des fonctionnalités qui m'a sauté aux yeux de Next.js, qu'il prétend que le fractionnement du code est automatique. Que fait Next.js en termes de fractionnement de code pour que cela fonctionne ?

Guillermo : Votre observation est 100 % juste. L'une des plus grandes choses avec le Web et l'un des plus gros poids sur le Web est JavaScript, et tout comme différents matériaux ont des densités et des poids différents quel que soit le volume physique réel, JavaScript a tendance à être un élément très dense et lourd. Même de petites quantités de JavaScript par rapport, comme par exemple, aux images qui peuvent être traitées de manière asynchrone et hors du fil principal, JavaScript a tendance à être particulièrement gênant.

Guillermo : Next.js a investi énormément d'efforts dans l'optimisation automatique de vos bundles. La première qui a été ma première intuition lorsque j'ai eu l'idée de Next.js était que vous allez définir, par exemple, 10 routes. Dans le monde Next.js, vous créez un répertoire de pages et vous y déposez vos fichiers Index.js, About.js, Settings.js, Dashboard.js, Termsofservice.js, Signup.js, Login.js. Ceux-ci deviennent des points d'entrée vers votre application que vous pouvez partager sur tous types de supports.

Guillermo : Lorsque vous les entrez, nous voulons vous donner d'abord et avant tout un JS pertinent pour cette page, puis peut-être un ensemble commun afin que les navigations ultérieures dans le système soient très rapides. Next.js également, ce qui est très, très agréable, pré-extrait automatiquement le reste des pages qui sont connectées à ce point d'entrée, de sorte que cela ressemble à une application d'une seule page. Beaucoup de gens disent: "Pourquoi ne pas simplement utiliser l'application Create React si je sais que j'ai peut-être quelques itinéraires?" Je leur dis toujours : « Écoutez, vous pouvez les trouver sous forme de pages, et parce que Next.js pré-récupérera automatiquement celles qui sont connectées, vous finissez par obtenir votre application d'une seule page, mais elle est mieux optimisée en ce qui concerne cette peinture initiale , ce point d'entrée initial.

Guillermo : C'était l'approche initiale de fractionnement du code, mais elle est devenue beaucoup plus sophistiquée au fil du temps. Google a contribué à une très belle optimisation appelée Module and No Module, qui donnera un JS différentiel aux navigateurs modernes, et un JS hérité lourd de polyfields aux autres navigateurs, et cette optimisation 100% automatisée et génère des économies massives. Nous l'avons donné à l'un de nos clients que nous hébergeons sur Vercel appelé Parnaby's, je crois si je ne me trompe pas, c'était quelque chose de très, très significatif. C'était peut-être 30 % d'économies sur la taille du code, et c'était simplement parce qu'ils avaient mis à niveau Next.js vers une version qui optimisait mieux les bundles JS.

Guillermo : C'est un peu le point que nous avons abordé plus tôt, c'est-à-dire que vous choisissez Next.js et qu'il ne fait que s'améliorer et s'optimiser avec le temps, il continuera à optimiser les choses en votre nom. Ce sont, encore une fois, des pré-configurations avec lesquelles vous n'auriez jamais à vous soucier ou dont vous ne seriez jamais dérangé, et dont vous ne voudriez même pas faire la recherche, pour être honnête. Comme si je n'étais évidemment pas très impliqué là-dedans, mais je regarde certaines des discussions internes et ils discutaient de tous ces polychamps qui n'avaient d'importance que pour Internet Explorer X et Soho, je me disais : "Je ne veux même pas savoir , mettons à niveau Next.js et profitons de tous ces avantages.

Drew : Il y a parfois de grands avantages à s'en tenir aux valeurs par défaut et à la configuration la plus courante des choses, ce qui semble être vraiment l'approche Next.js. Je me souviens quand j'ai commencé à écrire PHP au début des années 2000, et tout le monde utilisait PHP et MySQL, et à l'époque je venais juste de Windows donc je voulais utiliser PHP et Microsoft Sequel Server. Vous pouvez le faire, mais vous nagez à contre-courant pendant tout le trajet. Ensuite, dès que je suis passé à MySQL, tout l'écosystème a commencé à fonctionner pour moi et je n'ai pas eu besoin d'y penser.

Guillermo : Oui, tout s'enclenche, c'est une excellente observation. Nous voyons que tout le temps, comme l'écosystème Babel est si puissant maintenant que vous pourriez devenir, par exemple, un peu plus rapide en échangeant Babel contre autre chose, mais ensuite vous échangez cette incroyable compatibilité avec l'écosystème. C'est quelque chose que vous avez abordé plus tôt sur les performances, et comme pour beaucoup de gens, les performances de construction et les performances de génération statique sont un gros goulot d'étranglement, et c'est quelque chose que nous sommes très diligents pour améliorer progressivement les performances de nos outils.

Guillermo : Par exemple, l'une des choses que Next.js fait maintenant est de mettre à niveau sa valeur par défaut de Webpack 4 vers Webpack 5, ce qui présente des problèmes, et c'est pourquoi nous l'offrons d'abord aux utilisateurs en tant qu'opt- dans flag, mais plus tard, il deviendra la valeur par défaut. Webpack 5 apporte des améliorations de performances incroyables, mais nous ne sacrifions pas l'écosystème Webpack, nous nous sommes progressivement améliorés. Bien sûr, il y avait de très petites choses qui devaient être sacrifiées, mais c'est un avantage incroyable de l'écosystème JS aujourd'hui que beaucoup de gens passent sous silence, je pense, parce que peut-être qu'ils voient, "Oh, nous aurions pu faire X à Soho, c'était peut-être un peu plus rapide, ou peut-être que MPM à Soho prendrait moins de temps. Ils ramassent certains détails et ils passent à côté de la vue d'ensemble, à savoir que la valeur de l'écosystème est énorme.

Drew : La valeur d'avoir toute la configuration et la maintenance et cet aspect fait par un projet comme Next.js plutôt que de prendre cela sur soi en passant à autre chose est incroyable, car dès que vous vous éloignez de ces valeurs par défaut , vous assumez la charge de maintenir toutes les compatibilités et de le faire vous-même. L'une des choses qui m'intéresse vraiment avec Next.js est qu'il existe des options disponibles pour la génération de site statique ou le rendu côté serveur, ou peut-être un hybride des deux. Je pense qu'il y a eu quelques changements récents à ce sujet dans une mise à jour récente, pouvez-vous nous en dire un peu plus à ce sujet et quand vous pourriez choisir l'un ou l'autre ?

Guillermo : Oui, bien sûr. L'un des éléments clés de cette approche hybride combinée au système de pages que j'ai décrit précédemment est que vous pouvez avoir des pages entièrement statiques ou des pages rendues par le serveur. Une page entièrement statique présente l'incroyable avantage de ce que j'appelle le levage statique, c'est-à-dire que vous pouvez prendre cet actif et le placer automatiquement à la périphérie. En le mettant à la périphérie, je veux dire que vous pouvez le mettre en cache, vous pouvez le mettre en cache de manière préventive, vous pouvez le répliquer, vous pouvez faire en sorte que lorsqu'une demande arrive, elle ne touche jamais le serveur car nous savons à l'avance, " Hé, Slash Index est un statique.

Guillermo : C'est un avantage très, très intéressant lorsqu'il s'agit de servir un public mondial. Vous obtenez essentiellement un CDN automatique prêt à l'emploi, en particulier lorsque vous déployez les réseaux périphériques modernes comme Vercel ou AWS Amplify ou Netlify et ainsi de suite. Next.js part du principe que s'il peut être rendu statique, il devrait l'être. Lorsque vous démarrez un projet pour la première fois et que vous travaillez sur votre première page ou que vous démarrez les pneus du framework, autant rendre tout statique.

Guillermo : Même pour les besoins haut de gamme, par exemple, vercel.com, notre propre utilisation de Next.js est entièrement statique. C'est une combinaison de génération de site entièrement statique et statique, donc toutes nos pages marketing sont statiques, notre blog est généré statiquement à partir d'une source de données dynamique, puis notre tableau de bord qui contient beaucoup de données dynamiques, mais nous pouvons le fournir sous forme de coquilles ou de squelettes , toutes les pages associées à l'affichage de vos déploiements, à l'affichage de vos projets, à l'affichage de vos journaux, etc., etc., sont toutes essentiellement des pages statiques avec JavaScript côté client.

Guillermo : Cela nous sert incroyablement bien, car tout ce dont nous avons besoin d'une performance de premier volet très rapide est déjà pré-rendu, tout ce qui a besoin de référencement, déjà pré-rendu, et tout ce qui est extrêmement dynamique, nous n'avons qu'à nous soucier de la sécurité, car exemple, du point de vue du côté client qui utilise les mêmes appels d'API que, par exemple, notre CLI utilisé ou nos intégrations utilisent, et cetera, et cetera. Un site Web entièrement statique, très peu coûteux à exploiter, incroyablement évolutif, etc.

Guillermo : Maintenant, une chose dont nous avions besoin avec notre blog était que nous voulions mettre à jour les données très rapidement. Nous voulions corriger une faute de frappe très rapidement et ne pas attendre qu'une construction entière se produise, et c'est un avantage très important de Next.js, que lorsque vous passez d'un statique à un dynamique, il vous donne également ces solutions intermédiaires. . Pour notre blog, nous avons utilisé la génération statique incrémentielle, donc nous pouvons essentiellement reconstruire une page à la fois lorsque le contenu sous-jacent change.

Guillermo : Imaginez que nous n'avions pas que quelques centaines d'articles de blog et que de nombreux articles de blog soient générés en permanence et mis à jour en permanence, comme je l'ai mentionné à l'un de nos clients, le Washington Post, dans ce cas, vous devez y aller. plus vers le SSR complet, en particulier lorsque vous commencez à personnaliser le contenu pour chaque utilisateur. Ce voyage de complexité que je viens de décrire a commencé à partir d'une page de marketing, puis d'un blog de quelques milliers de pages, puis de dizaines de milliers ou de millions de pages. C'est le voyage Next.js que vous pouvez parcourir avec votre propre entreprise.

Guillermo : Ensuite, vous commencez en tant que développeur à choisir entre peut-être moins de responsabilité et plus de responsabilité, car lorsque vous optez pour l'utilisation de SSR, vous exécutez maintenant du code sur le serveur, vous exécutez du code sur le cloud, il y a plus de responsabilité avec plus de pouvoir. Le fait que vous puissiez décider où vous utilisez chaque type d'outil est, je pense, un avantage très, très intéressant de Next.

Drew : Pour ce qui est des aspects pratiques de la combinaison de la génération de site statique et du rendu côté serveur, comment cela fonctionne-t-il en termes d'élément serveur ? Avez-vous besoin d'une plateforme dédiée comme Vercel pour y parvenir, ou est-ce quelque chose qui peut être fait plus directement et plus simplement ?

Guillermo : Next.js vous donne un serveur de développement, donc vous téléchargez Next et vous exécutez votre Next Dev, et c'est le serveur de développement. Le serveur de développement est évidemment incroyablement optimisé pour le développement, comme il dispose de la dernière technologie de rafraîchissement rapide que Facebook a publiée, où… En fait, Facebook ne l'a pas publié, Facebook l'utilise en interne pour obtenir le remplacement de module chaud le meilleur, le plus performant et le plus fiable. , de sorte que vous tapez essentiellement et que les changements se reflètent sur l'écran, c'est donc le serveur de développement.

Guillermo : Ensuite, Next vous offre un serveur de production appelé Next Start, et Next Start possède toutes les capacités du framework pour l'auto-hébergement. La chose intéressante à propos de Vercel est que lorsque vous déployez Next to it, il est automatiquement optimisé et il est 100% sans serveur, ce qui signifie qu'il n'y a aucune responsabilité d'administration, de mise à l'échelle, d'encaissement et de validation d'encaissement, de purge, de réplication, de basculement global, etc. ainsi de suite que vous auriez à prendre en charge lorsque vous exécuterez Next Start vous-même.

Guillermo : C'est aussi le grand avantage de Next.js, donc par exemple, apple.com a plusieurs propriétés, sous-domaines et pages différents sur dotcom sur Next.js qu'ils hébergent eux-mêmes, en raison de besoins de sécurité et de confidentialité très, très avancés et rigoureux. . D'un autre côté, washingtonpost.com utilise Vercel, nous avons donc ce genre de large éventail d'utilisateurs, et nous sommes extrêmement heureux de tous les prendre en charge. À mon avis, la bonne chose à propos de la direction du sans serveur est qu'il peut vous offrir le meilleur des deux mondes en termes de performances optimales qui ne font que s'améliorer avec le temps, avec la meilleure expérience de développeur du genre "Hé, je n'ai pas à se soucier de toute sorte d'infrastructure.

Drew : Le Next.js est un projet open source développé par l'équipe de Vercel. Y a-t-il d'autres contributeurs en dehors de Vercel ?

Guillermo : Oui, donc Google Chrome étant le principal qui soumet activement les PR du serveur, aidez-nous à les optimiser et à le tester avec des partenaires, comme les très grands utilisateurs de Next.js qui font déjà partie de l'écosystème Google, par exemple, en raison de l'utilisation de lots et de nombreuses applications, ils doivent donc être impliqués étroitement en tant que partenaires. Facebook, nous entretenons une excellente relation avec l'équipe Facebook. Par exemple, l'actualisation rapide, nous avons été le premier framework React à l'obtenir, et ils nous ont aidés à nous guider à travers tout ce qu'ils ont appris sur l'utilisation de React et l'actualisation rapide sur Facebook.

Guillermo : Nous travaillons avec de nombreux partenaires qui ont de très grands déploiements d'applications Next.js dans la nature à partir de toutes sortes de cas d'utilisation différents, comme Imaginez le commerce électronique et le contenu. Ensuite, il y a juste beaucoup, beaucoup de contributeurs indépendants, des personnes qui utilisent Next.js personnellement, mais aussi des éducateurs et des membres d'équipes d'infrastructure frontale dans de grandes entreprises. C'est un effort communautaire très, très large.

Drew : Cela ressemble à l'inquiétude que quelqu'un pourrait avoir, que cela soit développé en grande partie par Vercel, qu'il puisse craindre qu'il soit en quelque sorte bloqué dans le déploiement sur cette plate-forme particulière, mais il semble tout comme ce n'est pas du tout le cas, et ils pourraient développer un site et le déployer sur Firebase ou Netlify ou…

Guillermo : Oui, absolument. J'aime beaucoup le comparer comme les Kubernetes de l'ère Front End d'une certaine manière, parce qu'en fin de compte, je suis fermement convaincu que… Kubernetes est quelque chose dont presque tout le monde a besoin lorsqu'il a besoin d'exécuter des processus Linux , comme si vous parliez d'opinion et que vous disiez que c'est une bonne technologie, ce n'est vraiment pas une opinion, mais il y a une opinion que nous oublions en quelque sorte. C'est comme à la fin de la journée, il est né de l'exécution d'un démon spécifique de programmes Linux emballés sous forme de conteneurs.

Guillermo : Next est dans une position similaire, parce que ce que nous considérons comme la primitive universelle du monde en tant que composant React, c'est évidemment une opinion, mais nous pensons que pour beaucoup d'entreprises, tout comme elles gravitent toutes vers Linux, nous sommes voir la même chose vers React et Vue, mais Vue a heureusement aussi Nuxt, qui est une solution très géniale, c'est équivalent en idéation et en principes à Next. Nous gravitons vers ces plateformes comme Next.js, comme Nuxt, comme Sapper pour l'écosystème Svelte.

Guillermo : Je pense que ces plates-formes devraient être ouvertes, car encore une fois, si tout le monde en a besoin, autant ne pas réinventer la roue dans l'ensemble de l'industrie, n'est-ce pas ? Nous accueillons très favorablement cette position, nous invitons les gens à la déployer, à la reconfigurer, à la reconstruire et à la redistribuer, etc.

Drew : Tout récemment, une nouvelle version de Next.js est sortie, je pense que la version 9.5. Quels changements importants y a-t-il eu dans cette version ?

Guillermo : La plus impressionnante est, comme je le disais plus tôt, que beaucoup de choses commencent par devenir statiques puis deviennent plus dynamiques à mesure que les choses évoluent. C'était d'ailleurs l'aventure de WordPress. Au début, WordPress était basé sur une approche de base de données de fichiers statiques, puis a grandi pour nécessiter une base de données, un peu comme ce que vous avez décrit avec la façon dont PHP a évolué pour devenir de plus en plus MySQL. Ce qui est bien avec Next.js 9.5, c'est qu'il fait de la génération statique incrémentielle une fonctionnalité prête pour la production, nous l'avons donc retirée de l'indicateur instable.

Guillermo : Cette fonctionnalité vous permet de passer du statique au dynamique sans renoncer à tous les avantages statiques, et sans avoir à faire le plein pour la dynamique rendue par le serveur, ce qui prolonge la durée de vie utile de votre type de statique. La façon dont nous l'utilisons chez Vercel, par exemple, comme je l'ai mentionné, c'est comme si notre blog était entièrement pré-rendu au moment de la construction, mais ensuite, par exemple, nous sommes en fait dans quelques minutes sur le point de faire une annonce majeure, et quand nous bloguons à ce sujet, nous voulons pouvoir le modifier, le réparer, le prévisualiser, etc. sans avoir à publier une version de cinq à 10 minutes à chaque fois que nous modifions une lettre d'un article de blog.

Guillermo : Avec la génération statique incrémentielle, vous pouvez reconstruire une page à la fois. Ce qui pouvait prendre des minutes, voire des secondes, selon la taille de votre site, prend désormais des millisecondes. Encore une fois, vous n'avez pas eu à renoncer à l'un des avantages de statique. C'est peut-être la chose qui m'excite le plus qui est devenue stable sur Next.js 9.5, et plus précisément parce que la communauté JS et la communauté React et la communauté du framework et la communauté générée par le site statique ont parlé de cette licorne de faire un incrémentiel statique pour 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 : C'est fascinant. 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. Avez-vous des mots d'adieu?

Guillermo: No, thank you for having me.