Fermer

août 31, 2020

Qu'estce que Next.js?


Nous parlons de Next.js. Qu'est-ce que c'est et où pourrait-il s'intégrer dans notre flux de travail de développement Web? Drew McLellan s’entretient avec le co-créateur Guillermo Rauch pour le savoir.

Aujourd'hui, nous parlons de Next.js. Qu'est-ce que c'est 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 notes

Mise à jour hebdomadaire

Transcription

 Photo de Guillermo Rauch 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 le co-créateur de Next.js. Il a précédemment fondé LearnBoost et CloudUp, et est bien connu en tant que créateur de plusieurs bibliothèques open source de nœuds populaires telles que Socket.io, Mongoose et SlackIn. Auparavant, il était un 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 freaking good freaking good, merci de m'avoir invité.

Drew: Je voulais vous parler aujourd'hui du monde entier de Next. js, car c'est évidemment quelque chose que vous connaissez 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 projets qui ont été sur mon radar lorsque je travaillais dans l'espace Jamstack, mais ce n'est pas quelque chose que j'ai personnellement regardé ou avec lequel j'ai travaillé de trop près auparavant. Pour les gens qui sont comme moi, qui ne sont peut-être pas conscients de 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 essaie de résoudre.

Guillermo: Suivant .js est un membre très intéressant de l'univers Jamstack, car Next.js a en fait commencé à être un framework entièrement orienté SSR. Cela a commencé à être adopté en dehors de l'espace Jamstack où les gens construisaient de très grands objets, 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 la 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 le faites pas faites la récupération de données au niveau supérieur de votre page avec Next.js, votre page React serait… De plus, pour ceux qui ne sont pas tout à fait au courant, Next.js est simplement le 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 l'extraction de données au niveau supérieur de votre page, elles sont automatiquement exportées au format HTML au lieu d'essayer de faire quoi que ce soit avec le rendu du serveur.

Guillermo: Puis plus tard sur, il a également acquis la capacité de génération de site statique, ce qui signifie que vous pouvez définir un hook de données spécial, mais ce hook 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 s'est beaucoup développé dans l'espace Jamstack également.

Drew: Les gens pourraient dire que React est déjà un framework, vous l'entendez certainement décrit de cette façon. Que signifie réellement être un cadre 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 at 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 sorte de hack de production et de pile PHP et de réponses tous ces besoins avancés et exotiques de Facebook.

Guillermo: Quand ils open source React, c'est presque comme l'open sourcing d'un composant. J'appelle toujours cela comme une source ouverte de 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 dans des endroits avec React. Dans la communauté, les gens ont commencé à créer des voitures et ils intégraient React en tant que moteur, ce que le pilote, le développeur recherchait en premier lieu, faisait 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 en fait créer des pages et des applications entièrement chargées».

Guillermo: Alors que React était en quelque sorte plus comme le composant et le moteur de widgets spécifiques dans 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 étaient intégrées dans le contenu de l'application existante de production avec beaucoup de lignes de code. et même d'autres bibliothèques et frameworks JS.

Guillermo: Ce que signifie créer un framework pour React, cela signifie que vous faites de React la partie fondamentale de l'histoire, j'espère et c'est quelque chose que nous allons essayer de faire avec Next.js, la courbe d'apprentissage concerne principalement React avec une surface supplémentaire 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, ce qui est un peu comme, j'aime l'appeler une voiture bootstrap 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 zéro. Next.js vous donnera cette configuration zéro et un ensemble de paramètres par défaut optimisés pour la production autour de la construction de gros objets avec React.

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

Guillermo: Correct.

Drew: Frappez le sol et effectuez une génération de site statique ou un rendu ou un routage de serveur.

Guillermo: Correct, et vous avez utilisé un mot qui est très, très essentiel à tout cela, qui est préconfiguré. Nous avons la chance d'attirer l'attention de Google Chrome en tant que contributeur à Next.js. L'une des chefs de file de ce projet, son truc, c'est que lorsqu'ils travaillaient sur des frameworks en interne chez Google, ils étaient confrontés aux 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 mettre à l'échelle et de créer des applications Web vraiment performantes prêtes à l'emploi.

Guillermo: Vous vous joindriez en tant que Googler et vous recevriez un cadre avec lequel vous créeriez vraiment grandes applications prêtes pour la production, très hautes performances. Shubie faisait partie de beaucoup de ces initiatives, et ce qu'elle a découvert, c'est qu'il y a deux ingrédients clés pour faire réussir un cadre à grande échelle. L'un est la pré-configuration, ce qui signifie que vous venez au travail, que 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 stade.

Guillermo: D'un autre côté, l'autre étape vraiment importante vers laquelle nous travaillons est la conformité. Vous pouvez obtenir le cadre préconfiguré le plus optimisé pour la production, mais si vous continuez 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 et ainsi de suite. et ainsi de suite, alors vous allez gaspiller cette pré-configuration. En mélangeant la pré-configuration et la conformité au fil du temps, le développeur a non seulement 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 que c'est assez opiniâtre, la couche d'interface utilisateur est React, elle utilise un script de type, utilise Webpack, et ce sont tous les choix que le projet a faits et c'est ce que vous obtenez. Corrigez-moi si je me trompe, mais vous ne pouvez pas remplacer React par 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 n'a pas d'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 Fire-based, 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 versions, une avec l'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 beaucoup de primitives avec lesquelles le Web à partir de 10 ans serait incompatible avec. 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 n'allez pas être capable de le remplacer, au moins de si tô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 nouvelle chose 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 que nous avons réalisé, c'est que l'Internet est composé de sites Web avec de nombreuses 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 vous guidez 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 le fardeau de l'intégralité de l'application.

Guillermo: Ensuite, ce chemin nous a conduit à implémenter le rendu serveur, puis la génération statique pour plusieurs pages, et cetera, et cetera. 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, React manquait de primitives de récupération et de routage de données, et nous les avons ajoutées. Il y a un certain niveau d'opinion à gérer 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 que cela enlève beaucoup de la complexité du choix, qu'il est juste là, il est configuré, et vous pouvez simplement commencer à l'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 accablant et nuire à la productivité.

Guillermo: Exactement.

Drew: ] Pour quel genre de projets voyez-vous des personnes utilisant Next.js? S'agit-il essentiellement de toute situation dans laquelle vous pourriez créer une application React de production, ou est-elle plus adaptée à des types particuliers de sites à contenu lourd? Est-ce important dans ce sens?

Guillermo: Oui, c'est donc un débat séculaire sur le Web, le Web est-il pour les applications, est-ce que le Web est pour les sites, est-ce un hybride? Quel est le rôle de JavaScript, et cetera, et cetera? C’est un peu difficile de donner une réponse directe, mais je pense que le Web a toujours évolué pour être un hybride de contenu qui évolue pour devenir 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 vous avez intégré des widgets 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 une partie du contenu et compte parfois le nombre d'articles que vous avez lus. Comme si je vous disais cela lorsque le Web a été inventé, comme Tim Berners-Lee serait comme: «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 cela. 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, toute cette catégorie est tout Next.js, puis le contenu des sites. Nous venons d'intégrer 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, à savoir les applications complètes et le contenu généré par les utilisateurs, comme tiktok.com, et un peu comme vous penserait que le cas d'utilisation de l'application d'une seule page d'origine est aussi bien représenté ici.

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, a pour ê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 formidable 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 fonctionnent dans le même type d’espace problématique, et à quel point 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 un super blog Gatsby également. 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. Parce 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 ligne est tracée lorsque vous commencez à être plus dynamique besoins et vous avez beaucoup de pages, vous avez besoin de les mettre à jour en même temps. Bien que Gatsby crée des solutions pour ceux-ci, Next.js a déjà des solutions live 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» des lots et beaucoup de pages. C'est là que les clients se tournent aujourd'hui vers Next.js au lieu de Gatsby.

Drew: L'un des problèmes que tout le monde semble rencontrer à mesure que leur solution JavaScript s'agrandit est la performance et la façon dont les choses peuvent commencer à devenir assez lentes , vous avez de gros lots. Traditionnellement, des choses comme le fractionnement de code peuvent être assez complexes à configurer correctement. Je vois que c’est l’une des fonctionnalités qui m’ont sauté aux yeux de Next.js, qui prétend que le fractionnement du code est automatique. Que fait Next.js en termes de division 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, par exemple, à des images qui peuvent être traitées de manière asynchrone et hors du thread principal, JavaScript a tendance à être particulièrement gênant.

Guillermo: Next.js a investi énormément d'efforts dans optimiser automatiquement vos offres groupées. La première qui a été ma première intuition lorsque j'ai eu l'idée de Next.js était que vous alliez définir, par exemple, 10 itinéraires. 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. Celles-ci deviennent des points d’entrée vers votre application que vous pouvez partager via toutes sortes de médias.

Guillermo: Lorsque vous les entrez, nous voulons vous donner d’abord et avant tout le JS qui est pertinent pour cette page, puis peut-être un bundle 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é-récupère 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: «Regardez, vous pouvez les trouver sous forme de pages, et comme Next.js prélèvera 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 de code, mais ensuite elle est devenue beaucoup plus sophistiquée avec le 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é qui contient beaucoup de polyfields pour d'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 que si je ne me trompe pas, c'était quelque chose de très, très significatif. Cela représentait peut-être 30% d'économies sur la taille du code, et c'était simplement parce qu'ils ont mis à niveau Next.js vers une version optimisant mieux les bundles JS.

Guillermo: C'était un peu le point que nous abordions plus tôt , c'est-à-dire que vous choisissez Next.js et que cela ne fait que s'améliorer et être optimal avec le temps, il continuera à optimiser les choses en votre nom. Ce sont, encore une fois, des pré-configurations que vous n’auriez jamais à gérer ou avec lesquelles vous ne seriez jamais dérangé, et dont vous ne voulez même pas faire la recherche, pour être honnête. Comme si je n'étais manifestement pas très impliqué dans cela, mais je regarde certaines des discussions internes et ils discutaient de tous ces polyfields qui n'avaient d'importance que pour Internet Explorer X et Soho, je me suis dit: «Je ne veux même pas savoir , mettons juste Next.js à niveau et obtenons tous ces avantages. »

Drew: Il y a parfois de grands avantages là-dedans à s'en tenir aux valeurs par défaut et à s'en tenir à la configuration la plus courante des choses, ce qui semble être vraiment le Approche Next.js. Je me souviens quand j'ai commencé à écrire PHP au début des années 2000, et que 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: Ouais, tout clique simplement, c'est une si bonne 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 pour autre chose, mais ensuite vous échangez cette incroyable compatibilité écosystémique. 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, une des choses que Next.js fait maintenant est de mettre à niveau sa valeur par défaut de Webpack 4 vers Webpack 5, qui a des choses qui cassent, et c'est pourquoi nous l'offrons d'abord aux gens en tant que indicateur d'acceptation, mais il deviendra plus tard 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 améliorés progressivement. 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 négligent, je pense, parce qu'ils voient peut-être: «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 quelques détails et ils ratent la vue d'ensemble, qui est la valeur de l'écosystème est énorme.

Drew: La valeur d'avoir toute la configuration et l'entretien et ce côté de cela fait par un projet comme Next. js plutôt que de prendre cela sur vous-même en passant à autre chose est incroyable, car dès que vous vous éloignez de ces valeurs par défaut, vous vous chargez de maintenir toutes les compatibilités et de le faire vous-même. L'une des choses qui m'intéressent 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 peut-être. Je pense qu'il y a eu des 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 a l'incroyable avantage de ce que j'appelle le levage statique, c'est-à-dire que vous pouvez prendre cet élément et le placer automatiquement en bordure. En le plaçant à 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 le savons à l'avance, " Hé, Slash Index est statique. »

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

Guillermo: Même pour des besoins haut de gamme, alors par exemple, vercel.com, notre propre utilisation de Next.js est totalement 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 les fournir sous forme de coquilles ou de squelettes. , toutes les pages associées à la visualisation de vos déploiements, à la visualisation de vos projets, à la visualisation de vos journaux, et cetera, et cetera, sont toutes essentiellement des pages statiques avec JavaScript côté client.

Guillermo: Cela nous sert incroyablement bien parce que tout là où nous avons besoin d'une performance de premier volet très rapide est déjà pré-rendu, tout ce qui nécessite du 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é, par exemple, du point de vue du 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 bon marché à exploiter, incroyablement évolutif et ainsi de suite.

Guillermo: Maintenant, une chose particulière 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 version complète se produise, et c'est un avantage très important de Next.js, car lorsque vous chevauchez d'une statique à une dynamique, il vous donne également ces solutions entre les solutions. . Pour notre blog, nous avons utilisé la génération statique incrémentielle, donc essentiellement nous pouvons reconstruire une page à la fois lorsque le contenu sous-jacent change.

Guillermo: Imaginez que nous n'avions pas seulement quelques centaines de billets de blog et que nous avions beaucoup de blog les messages sont générés tout le temps et mis à jour tout le temps, comme je l'ai mentionné l'un de nos clients, le Washington Post, dans ce cas, vous devez aller plus vers le SSR complet, surtout lorsque vous commencez à personnaliser le contenu pour chaque utilisateur. Ce voyage de complexité que je viens de décrire a commencé avec une page marketing, un blog de quelques milliers de pages, des dizaines de milliers ou des 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é à plus de responsabilité, car lorsque vous choisissez d'utiliser SSR, vous ' 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 puissance. Le fait que vous puissiez décider où vous utilisez chaque type d'outil est, à mon avis, un avantage très, très intéressant de Next.

Drew: Juste dans les 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 plate-forme 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, vous téléchargez donc 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 d'actualisation rapide publiée par Facebook, 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

Guillermo: Then Next vous donne un serveur de production appelé Next Start, et Next Start a toutes les capacités de le cadre de 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é de l'administration, de la mise à l'échelle, de l'encaissement et de l'encaissement de la validation, de la purge, de la réplication, du basculement global, etc. ainsi de suite que vous auriez à prendre lorsque vous exécuterez vous-même Next Start.

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, ils s'auto-hébergent, en raison de besoins de sécurité et de confidentialité très, très avancés et stricts. D'autre part, washingtonpost.com utilise Vercel, nous avons donc ce type de large éventail d'utilisateurs, et nous sommes extrêmement heureux de les soutenir tous. La bonne chose à propos de la direction du sans serveur, à mon avis, c'est que cela 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 de s'inquiéter de toute sorte d'infrastructure. »

Drew: 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 RP de serveur, nous aide avec les optimisations et le testant avec des partenaires, comme les très grands utilisateurs de Next.js qui sont ils font déjà partie de l'écosystème Google, par exemple, en raison de l'utilisation de nombreuses applications, ils doivent donc être étroitement associés 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 à obtenir cela, 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 beaucoup de 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 imaginer 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 des équipes d'infrastructure avant dans les grandes entreprises. C'est un effort communautaire très, très large.

Drew: Cela ressemble à la préoccupation que quelqu'un pourrait avoir, que cela soit développé dans une partie importante par Vercel, qu'ils pourraient avoir la crainte qu'ils vont pour être en quelque sorte bloqués dans le déploiement sur cette plate-forme particulière, mais cela semble tout à fait comme si ce n'était pas du tout le cas, et ils pourraient développer un site et le déployer sur Firebase ou Netlify ou…

Guillermo: Ouais, absolument. J'aime beaucoup le comparer pour les Kubernetes de l'ère du 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 quand il doit exécuter des processus Linux , comme vous parliez d'opinions et vous dites que c'est une bonne technologie, ce n'est pas du tout avisé, 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, car ce que nous prenons pour être le primitif universel du world en tant que composant React, évidemment, il a des opinions, mais nous pensons que pour beaucoup d'entreprises, tout comme elles gravitent toutes vers Linux, nous voyons la même chose vers React et Vue, mais Vue a heureusement Nuxt aussi, ce qui est très solution géniale, elle est équivalente en idéation et en principes à Next. Nous gravitons vers ces plates-formes comme Next.js, comme Nuxt, comme Sapper pour l'écosystème Svelte.

Guillermo: Je pense que ce devraient être des plates-formes ouvertes, car encore une fois, si tout le monde en a besoin, eh bien ne pas réinventer la roue dans toute l'industrie, non? Nous nous félicitons vivement de cette position, nous invitons les gens à la déployer, à la reconfigurer, à la reconstruire et à la redistribuer et ainsi de suite.

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

Guillermo: Le plus impressionnant est, comme je le disais plus tôt, que beaucoup de choses commencent statiques et deviennent ensuite plus dynamiques à mesure que les choses évoluent. C'était l'aventure de WordPress, d'ailleurs. Au début, WordPress était basé sur une approche de base de données de fichiers statiques, puis a grandi en ayant besoin d'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. What’s nice about Next.js 9.5 is that it makes incremental static generation a production ready feature, so we took it out of the unstable flag.

Guillermo: This feature allows you to make that journey from static to dynamic without giving up on all the static benefits, and without having to go full for server-rendered dynamic, so it stretches the useful lifetime of your sort of static. The way we use it at Vercel, for example, as I mentioned, it’s like our blog gets fully pre-rendered at build time, but then for example, we’re actually in a couple minutes about to make a major announcement, and when we blog about it we want to be able to tweak it, fix it, preview it, et cetera without having to issue a five to 10-minute build every time we change one letter of one blog post.

Guillermo: With incremental static generation, you can rebuild one page at a time. What could take minutes or even seconds, depending on how big your site is, now takes milliseconds. Again, you didn’t have to give up on any of the benefits of static. That’s perhaps the thing I’m most excited about that went stable on Next.js 9.5, and specifically because the JS community and the React community and the framework community and static site generated community have been talking about this unicorn of making a static incremental for 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: That’s fascinating. 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. Do you have any parting words?

Guillermo: No, thank you for having me.

Smashing Editorial(il)




Source link

août 31, 2020