Smashing Podcast Folge 23 mit Guillermo Rauch: Was ist Next.js?

Heute sprechen wir über Next.js. Was ist das und wo könnte es in unseren Webentwicklungs-Workflow passen? Ich habe mit Co-Schöpfer Guillermo Rauch gesprochen, um das herauszufinden.

Notizen anzeigen

• Guillermo Rauch auf Twitter
• Next.js

Wöchentliches Update

• „Requisiten und PropTypes in React beherrschen“
  von David Adeneye
• „Inspirierte Designentscheidungen mit Bradbury Thompson: Die Kunst des Grafikdesigns“
  von Andy Clarke
• „Einrichten einer API mit Flask, Googles Cloud SQL und App Engine“
  von Wole Oyekanmi
• „Formen und Validierung in der Ionenreaktion“
  von Jerry Navi
• „Wie Sie Ihren Kunden helfen, durch Design mehr Backlinks zu erhalten“
  von Susanne Scacca

Abschrift

Drew McLellan: Er ist der Gründer und CEO von Vercel, einer Cloud-Plattform für statische Websites, die sich in einen Jamstack-Workflow einfügt. Er ist auch der Mitschöpfer von Next.js. Zuvor gründete er LearnBoost und CloudUp und ist bekannt als Schöpfer mehrerer beliebter Open-Source-Knotenbibliotheken wie Socket.io, Mongoose und SlackIn. Davor war er Kernentwickler bei MooTools, daher wissen wir, dass er sich mit JavaScript wie seine Westentasche auskennt. Wussten Sie, dass er einst vom König von Spanien einen königlichen Auftrag erhielt, eine Eisskulptur aus Eisbergsalat zu schaffen? Meine großartigen Freunde, bitte heißen Sie Guillermo Rauch willkommen. Hallo Guillermo, wie geht es dir?

Guillermo Rauch: Mir geht es verdammt gut, danke, dass du mich hast.

Drew: Ich wollte heute mit dir über die ganze Welt von Next.js sprechen, da du dich offensichtlich persönlich sehr gut damit auskennst, da du von Anfang an als Co-Creator dabei warst. Next.js ist einer dieser Projektnamen, die ich während meiner Arbeit im Jamstack-Bereich auf dem Schirm hatte, aber es ist nichts, was ich mir persönlich angesehen oder mit dem ich zuvor zu genau gearbeitet habe. Für Leute wie mich, die vielleicht nicht wissen, was Next.js ist, könnten Sie uns vielleicht ein wenig Hintergrundwissen darüber geben, was es ist und welche Probleme es zu lösen versucht.

Guillermo: Next.js ist ein sehr interessantes Mitglied des Jamstack-Universums, weil Next.js tatsächlich angefangen hat, ein vollständig auf SSR ausgerichtetes Framework zu sein. Es begann, außerhalb des Jamstack-Bereichs, wo die Leute sehr große Dinge bauten, viel Akzeptanz zu finden, speziell wenn sie benutzergenerierte Inhalte oder dynamische Inhalte oder soziale Netzwerke oder E-Commerce haben wollten, und sie wussten, dass sie SSR wollten, weil ihr Datensatz war sehr groß oder sehr dynamisch. Ich denke, dass es für viele Leute in der Jamstack-Welt unter dem Radar gelandet ist, aber später hat Next.js die Fähigkeiten zur statischen Optimierung erhalten.

Guillermo: Einerseits zum Beispiel, wenn Sie mit Next.js keine Daten auf der obersten Ebene Ihrer Seite abrufen würden, wäre Ihre React-Seite … Übrigens, für diejenigen, die sich nicht ganz auskennen, Next.js ist einfach ein React-Framework für die Produktion, hat aber diese Fähigkeit, einige Renderings durchzuführen. Wenn Sie dann die statischen Optimierungsfunktionen aufrufen und das Abrufen von Daten nicht auf der obersten Ebene Ihrer Seite definieren würden, werden diese automatisch als HTML exportiert, anstatt zu versuchen, irgendetwas mit dem Server-Rendering zu tun.

Guillermo: Später hat es dann auch die Fähigkeit zur statischen Site-Generierung erhalten, was bedeutet, dass Sie einen speziellen Daten-Hook definieren können, aber dieser Daten-Hook erhält Daten zur Erstellungszeit. Next.js wurde zu einem hybriden, sehr leistungsfähigen dynamischen und statischen Framework, und jetzt wächst es auch im Jamstack-Bereich stark.

Drew: Man könnte sagen, dass React bereits ein Framework ist, man hört es sicherlich so beschrieben. Was bedeutet es eigentlich, ein Framework für React zu sein?

Guillermo: Das ist eine großartige Beobachtung, denn ich weise die Leute immer darauf hin, dass React auf Facebook und React außerhalb von Facebook völlig unterschiedliche Bestien sind. React bei Facebook wird tatsächlich zusammen mit Server-Rendering verwendet, aber selbst ihr Server-Rendering verwendet beispielsweise kein Node.js, sondern eine hochspezialisierte virtuelle Maschine namens Hermes, die mit ihrer Art von Produktions-Hack und PHP-Stack kommuniziert und antwortet all diese fortschrittlichen und exotischen Facebook-Anforderungen.

Guillermo: Wenn sie React als Open Source anbieten, ist das fast so, als würde man eine Komponente als Open Source beziehen. Ich nenne es immer Open-Sourcing des Motors, aber nicht das Auto geben. Was passiert ist, ist, dass die Leute wirklich damit fahren wollten, sie wollten mit React an Orte kommen. In der Community fingen die Leute an, Autos zu bauen, und sie betteten React als Motor ein, was der Fahrer, der Entwickler, in erster Linie wollte, um React zum grundlegenden Teil des Autos zu machen. Dinge wie Next.js und Gatsby und React Static und viele andere Frameworks tauchten auf, die die Notwendigkeit von „Ich möchte eigentlich voll geladene Seiten und Anwendungen erstellen“ lösten.

Guillermo: Während React eher die Komponente und die Engine für bestimmte Widgets innerhalb der Seite war, war dies bei Facebook sicherlich der Fall. Sie werden allgemein und öffentlich zugeben, dass sie es für Dinge wie den Benachrichtigungsstapel, das Chat-Widget, die Newsfeed-Komponente erfunden haben, und diese Komponenten waren React-Routen, die mit vielen, vielen Codezeilen in den Inhalt der bestehenden Produktions-App eingebettet wurden und sogar andere JS-Bibliotheken und Frameworks.

Guillermo: Was es bedeutet, ein Framework für React zu erstellen, bedeutet, dass Sie React zum grundlegenden Teil der Geschichte machen, hoffentlich und das ist etwas, was wir mit Next.js versuchen werden, die Lernkurve dreht sich hauptsächlich um React mit einigen Ergänzungen Oberfläche für Next.js, insbesondere rund um das Abrufen und Weiterleiten von Daten. Wir führen auch viele Produktionsoptimierungen durch. Wenn Sie also React erhalten, wenn Sie die Create React-App erhalten, die so etwas wie ein Bootstrap-Auto ist, das Facebook Ihnen gibt, werden die Anforderungen für die Produktion möglicherweise nicht wirklich erfüllt . Oder wenn Sie versuchen, es selbst zu tun, indem Sie Webpack konfigurieren und Babel konfigurieren und Server-Rendering und statische Generierung konfigurieren, ist es auch schwierig, ein Auto von Grund auf neu zusammenzustellen. Next.js bietet Ihnen diese Nullkonfiguration und auch produktionsoptimierte Standardeinstellungen, um ganze große Dinge mit React zu erstellen.

Drew: Es ist also fast so, als würde es eine Art Ökosystem um Ihre React-App legen, mit einer Sammlung vorkonfigurierter Tools, mit denen Sie Folgendes tun können:

Guillermo: Richtig.

Drew: Schlagen Sie voll durch und erstellen Sie statische Sites oder Server-Rendering oder -Routing.

Guillermo: Richtig, und Sie haben dort ein Wort verwendet, das sehr, sehr wichtig für all das ist, das vorkonfiguriert ist. Wir haben das Glück, Google Chrome als Mitwirkenden an Next.js auf uns aufmerksam zu machen. Eine der Leiterinnen dieses Projekts, ihr Ding ist, dass sie, als sie intern bei Google an Frameworks arbeiteten, mit vielen der gleichen Probleme konfrontiert waren, mit denen die Community und Open Source heute konfrontiert sind. Bei Google gab es viele verschiedene konkurrierende Initiativen zur Skalierung und Erstellung wirklich leistungsfähiger Web-Apps.

Guillermo: Sie würden als Googler einsteigen und Sie würden ein Framework erhalten, mit dem Sie wirklich große, produktionsreife, sehr leistungsstarke Anwendungen erstellen würden. Shubie war an vielen dieser Initiativen beteiligt, und sie fand heraus, dass es zwei Hauptbestandteile gibt, um ein Framework in großem Maßstab erfolgreich zu machen. Eine davon ist die Vorkonfiguration, d. h. Sie kommen zur Arbeit, Sie starten eine brandneue App, Sie sollten etwas erhalten, das bereits einsatzbereit ist und viele der zu diesem Zeitpunkt bekannten Produktionsanforderungen erfüllt rechtzeitig.

Guillermo: Andererseits ist der andere wirklich wichtige Schritt, auf den wir hinarbeiten, die Konformität. Sie können das am besten optimierte, produktionsfertig vorkonfigurierte Framework erhalten, aber wenn Sie fortfahren und beispielsweise anfangen, viele schwere Abhängigkeiten oder Skripte von Drittanbietern einzuführen oder sehr ineffiziente Layouts verwenden, deren Erstellung viel Zeit in Anspruch nimmt, und so weiter und so weiter, dann werden Sie diese Vorkonfiguration irgendwie verschwenden. Durch das Mischen von Vorkonfiguration mit Konformität im Laufe der Zeit hat der Entwickler nicht nur einen großartigen Ausgangspunkt, sondern wird auch im Laufe der Zeit zum Erfolg geführt.

Drew: Es scheint ein Merkmal von Next.js zu sein, dass es ziemlich eigensinnig ist, die UI-Schicht ist React, es verwendet Type Script, verwendet Webpack, und das sind alles Entscheidungen, die das Projekt getroffen hat, und das ist, was Sie bekommen. Korrigieren Sie mich, wenn ich falsch liege, aber Sie konnten React beispielsweise nicht in Next.js gegen Vue austauschen.

Guillermo: Das ist ein guter Punkt, an dem die technische Entscheidungsfindung auf eine Art Kunst trifft. Einerseits möchte ich wirklich behaupten, dass Next sehr unparteiisch ist, und der Grund dafür ist, dass Sie, wenn Sie speziell zu github.com/vercel/nextjs und dem Beispielverzeichnis gehen, sehen werden, dass es dort fast so etwas wie a gibt kombinatorische Explosion von Technologien, die Sie zusammen mit Next.js verwenden können. Sie sehen feuerbasiert, Sie sehen Graphic UL, Sie sehen Apollo, Sie sehen Redux, Sie sehen MobX, im CSS-Bereich gibt es noch mehr Optionen.

Guillermo: Wir haben einen standardmäßigen CSS-Port, der eingebettet ist, aber dann können Sie zwei Varianten davon verwenden, eine mit Import, eine mit Style-Tags, die wir Style JSX nennen, was dem Webplattform-Ansatz für Shadow CSS sehr ähnlich ist. Der Grund, den ich damit meine, ist, dass wir wollen, dass Next.js sehr nahe am „Bare Metal“ des Webs bleibt und nicht viele Primitive einführt, mit denen das Web von heute in 10 Jahren nicht kompatibel wäre. Wenn Sie sich dann die Beispiele ansehen, werden Sie sehen, dass es all diese anderen Technologien gibt, die Sie anschließen können.

Guillermo: Die grundlegende Meinung ist, dass es React gibt und dass Sie es nicht ersetzen können, zumindest nicht in absehbarer Zeit. Dann ist da noch das Konzept, dass Sie in der Lage sein sollten, Seiten zu erstellen, und das war so etwas wie eine neue Sache, als wir es zum ersten Mal starteten, nämlich dass jeder versucht, Single-Page-Anwendungen zu erstellen. Wir haben festgestellt, dass das Internet aus Websites mit vielen Seiten besteht, die unterschiedliche Einstiegspunkte über Suchmaschinen, über Twitter, über Facebook, über soziale Netzwerke, über E-Mail-Begleiter schaffen, als würde man die Person immer zu einem Einstiegspunkt führen, und die Person, die diesen Einstiegspunkt passiert, sollte nicht die Last der gesamten Anwendung herunterladen müssen.

Guillermo: Dann führte uns dieser Weg zur Implementierung des Server-Renderings, dann zur statischen Generierung für mehrere Seiten und so weiter und so weiter. Diese andere grundlegende Meinungsebene ist Next sollte ein Framework sein, das für das Web arbeitet, nicht gegen das Web. Darüber hinaus fehlte React das Abrufen von Daten und das Routing von Primitiven, und wir haben diese hinzugefügt. Es gibt eine Meinungsebene, mit der man sich auseinandersetzen muss, als ob jeder einen Router braucht, also könnte man genauso gut einen Router standardmäßig eingebaut haben.

Drew: Der große Vorteil, diese Standardeinstellungen zu haben, ist, dass es viel von der Komplexität der Auswahl wegnimmt, dass es einfach da ist, es konfiguriert ist und Sie einfach anfangen können, es zu verwenden, ohne zu viel nachdenken zu müssen, denn ich denke, wir haben alle -

Guillermo: Genau.

Drew: Ich war in Situationen, in denen es viel zu viele Möglichkeiten gibt, welche Komponenten verwendet werden sollen, und es kann überwältigend sein und der Produktivität im Wege stehen.

Guillermo: Genau.

Drew: Für welche Art von Projekten siehst du Leute, die Next.js verwenden? Ist es im Grunde für jede Situation geeignet, in der Sie eine Produktions-React-App erstellen könnten, oder ist es eher für bestimmte Arten von inhaltsintensiven Websites geeignet? Spielt es in diesem Sinne eine Rolle?

Guillermo: Ja, das war also eine uralte Debatte über das Web, ist das Web für Apps, ist das Web für Websites, ist es ein Hybrid? Welche Rolle spielt JavaScript usw.? Es ist ziemlich schwierig, eine klare Antwort zu geben, aber meiner Meinung nach hat sich das Web immer zu einer Mischung aus Inhalten entwickelt, die sich entwickeln, um immer dynamischer und persönlicher für den Benutzer zu sein. Selbst wenn Sie sagen, wie eine Content-Website, haben die High-End-Content-Websites der Welt Codebasen, die mit Apps sehr vergleichbar sind.

Guillermo: Ein großartiges Beispiel hier ist die New York Times, sie geben Ihnen eingebettete Widgets mit Datenanalyse-Tools und interaktiven Animationen, und sie empfehlen, welche Geschichte Sie als nächstes lesen sollten, und sie haben ein Abonnementmodell eingebaut, das Sie manchmal gibt Teil des Inhalts und zählt manchmal, wie viele Artikel Sie gelesen haben. Wenn ich Ihnen das gesagt hätte, als das Internet erfunden wurde, würde Tim Berners-Lee sagen: „Nein, das ist verrückt, das ist im Internet nicht möglich“, aber das ist das Internet, das wir heute haben.

Guillermo: Next.js erfüllt viele dieser komplexen modernen Anforderungen, was bedeutet, dass Sie viel E-Commerce-Nutzung sehen werden, Sie werden damit viele Inhalte sehen. E-Commerce bedeutet übrigens nicht nur Artikel kaufen, sondern Erfahrungen wie die größten Immobilien-Websites im Internet, realtor.com, zillow.com, trulio.com, diese gesamte Kategorie besteht ausschließlich aus Next.js, dann Inhalt Websites. Wir haben gerade washingtonpost.com als Kunden von Vercel und Next.js aufgenommen, wir haben dann eine dritte Kategorie, die aufstrebender, aber sehr interessant ist, nämlich vollständige Apps und benutzergenerierte Inhalte, wie tiktok.com, und so ähnlich wie Sie würde denken, dass der Anwendungsfall der ursprünglichen Single-Page-Anwendung dort ebenfalls ziemlich vertreten ist.

Guillermo: Next.js glänzt irgendwie, wenn Sie viele Inhalte haben müssen, die sehr, sehr schnell bereitgestellt werden müssen, die SEO-optimiert werden müssen, und am Ende des Tages ist es eine Mischung aus dynamisch und statisch.

Drew: Ich habe zuvor mit Marcy Sutton über Gatsby gesprochen, der sich in einer ähnlichen Richtung zu bewegen scheint. Es ist immer toll, mehr als eine Lösung für ein Problem zu sehen und die Wahl zwischen einem Projekt und dem nächsten zu haben. Würden Sie sagen, dass Next.js und Gatsby in der gleichen Problemzone operieren und wie ähnlich oder unähnlich sie sind?

Guillermo: Ich denke, dass es bei einigen Anwendungsfällen Überschneidungen gibt. Zum Beispiel läuft mein persönlicher Blog rauchg.com auf Next.js, es hätte auch einfach ein toller Gatsby-Blog werden können. Es gibt diese Überschneidung in den kleineren statischen Website-Bereichen, und mit klein meine ich nicht nicht relevant. Viele Dotcoms, die super, super wichtig sind, laufen im Grunde genommen im statischen Web, das ist meiner Meinung nach das Schöne an Jamstack. Da Next.js Ihre Seiten statisch optimieren kann und Sie dadurch hervorragende Lighthouse-Ergebnisse erzielen können, können Sie es für sich überschneidende Anwendungsfälle verwenden.

Guillermo: Ich denke, die Grenze wird gezogen, wenn Sie anfangen, sich mit dynamischeren Anforderungen zu befassen, und Sie viele Seiten haben, die Sie auf einmal aktualisieren müssen. Obwohl Gatsby Lösungen für diese erstellt, hat Next.js bereits produktionsreife Live-Lösungen, die mit jeder Art von Datenbank, jeder Art von Daten-Backend funktionieren, um im Grunde viele, viele Seiten zu „generieren“ oder zu „drucken“. Hier gehen Kunden heute zu Next.js statt zu Gatsby.

Drew: Eines der Probleme, auf das jeder zu stoßen scheint, wenn seine JavaScript-basierte Lösung größer wird, ist die Leistung und wie die Dinge ziemlich langsam werden können, Sie haben große Paketgrößen. Traditionell können Dinge wie Code-Splitting ziemlich komplex sein, um richtig konfiguriert zu werden. Ich sehe, das ist eines der Features, die mir bei Next.js aufgefallen sind, dass es behauptet, dass die Codeaufteilung automatisch erfolgt. Was tut Next.js in Bezug auf Code-Splitting, damit das funktioniert?

Guillermo: Ihre Beobachtung ist zu 100 % richtig. Eines der größten Dinge im Web und eines der größten Gewichte im Web ist JavaScript, und genau wie verschiedene Materialien unabhängig vom tatsächlichen physischen Volumen unterschiedliche Dichten und Gewichte haben, neigt JavaScript dazu, ein sehr dichtes, schweres Element zu sein. Auch kleine JavaScript-Mengen im Vergleich zu beispielsweise Bildern, die asynchron und abseits des Haupt-Threads verarbeitet werden können, neigen dazu, JavaScript besonders zu stören.

Guillermo: Next.js hat enorm viel Arbeit in die automatische Optimierung Ihrer Bundles investiert. Die erste, die meine erste Intuition war, als ich zum ersten Mal auf die Idee für Next.js kam, war, dass Sie zum Beispiel 10 Routen definieren werden. In der Next.js-Welt erstellen Sie ein Seitenverzeichnis und legen Ihre Dateien dort ab: Index.js, About.js, Settings.js, Dashboard.js, Termsofservice.js, Signup.js, Login.js. Diese werden zu Einstiegspunkten für Ihre Anwendung, die Sie über alle Arten von Medien teilen können.

Guillermo: Wenn Sie diese eingeben, möchten wir Ihnen in erster Linie JS geben, das für diese Seite relevant ist, und dann vielleicht ein gemeinsames Bündel, damit die nachfolgende Navigation innerhalb des Systems sehr schnell ist. Next.js, das sehr, sehr nett ist, ruft auch automatisch den Rest der Seiten vorab ab, die mit diesem Einstiegspunkt verbunden sind, sodass es sich wie eine Single-Page-Anwendung anfühlt. Viele Leute sagen: „Warum verwende ich nicht einfach die Create React-App, wenn ich weiß, dass ich vielleicht ein paar Routen habe?“ Ich sage ihnen immer: „Sehen Sie, Sie können diese Seiten als Seiten finden, und da Next.js automatisch verbundene Seiten vorab abruft, erhalten Sie am Ende Ihre Single-Page-Anwendung, die jedoch in Bezug auf diese anfängliche Farbe besser optimiert ist , dieser erste Einstiegspunkt.“

Guillermo: Das war der ursprüngliche Code-Splitting-Ansatz, aber im Laufe der Zeit wurde er viel ausgefeilter. Google hat eine sehr schöne Optimierung namens Module und No Module beigesteuert, die modernen Browsern differentielles JS und anderen Browsern älteres JS mit vielen Polyfeldern bietet, und diese Optimierung ist zu 100 % automatisiert und führt zu massiven Einsparungen. Wir haben es einem unserer Kunden namens Parnaby's gegeben, den wir bei Vercel hosten. Ich glaube, wenn ich mich nicht irre, war es etwas sehr, sehr Bedeutendes. Es waren vielleicht 30 % Einsparungen bei der Codegröße, und das nur, weil sie Next.js auf eine Version aktualisiert haben, die JS-Bundles besser optimierte.

Guillermo: Das war so ein Punkt, den wir vorhin besprochen haben, nämlich dass Sie Next.js wählen und es mit der Zeit immer besser und optimaler wird, es wird die Dinge in Ihrem Namen weiter optimieren. Das sind wiederum Vorkonfigurationen, mit denen Sie sich nie befassen oder belästigen müssten und deren Recherche Sie ehrlich gesagt nicht einmal durchführen möchten. Als wäre ich offensichtlich nicht sehr involviert, aber wenn ich mir einige der internen Diskussionen anschaue und sie all diese Polyfelder diskutierten, die nur für Internet Explorer X und Soho wichtig waren, dachte ich: „Ich will es gar nicht wissen , lass uns einfach Next.js aktualisieren und all diese Vorteile nutzen.“

Drew: Es gibt manchmal große Vorteile, wenn man sich an die Standardeinstellungen hält und an der gängigsten Konfiguration festhält, was wirklich der Next.js-Ansatz zu sein scheint. Ich erinnere mich, als ich in den frühen 2000er Jahren anfing, PHP zu schreiben, und jeder PHP und MySQL verwendete, und zu der Zeit, als ich gerade von Windows kam, wollte ich PHP und Microsoft Sequel Server verwenden. Du kannst es schaffen, aber du schwimmst die ganze Zeit gegen den Strom. Sobald ich dann auf MySQL umgestiegen war, fing das gesamte Ökosystem an, für mich zu arbeiten, und ich musste nicht darüber nachdenken.

Guillermo: Ja, alles passt einfach, das ist so eine tolle Beobachtung. Wir sehen das die ganze Zeit, wie das Babel-Ökosystem jetzt so mächtig ist, dass Sie zum Beispiel ein bisschen schneller werden könnten, indem Sie Babel gegen etwas anderes austauschen, aber dann tauschen Sie diese unglaubliche Ökosystem-Kompatibilität ein. Dies ist etwas, was Sie vorhin über die Leistung angesprochen haben, und wie für viele Leute ist die Build-Leistung und die Leistung bei der statischen Generierung ein großer Engpass, und dies ist etwas, bei dem wir sehr fleißig daran arbeiten, die Leistung unserer Tools schrittweise zu verbessern.

Guillermo: Zum Beispiel aktualisiert Next.js jetzt unter anderem seinen Standard von Webpack 4 auf Webpack 5, das einige bahnbrechende Dinge enthält, und deshalb bieten wir es den Leuten zuerst als Option an. in Flag, aber später wird es zum Standard. Webpack 5 führt zu unglaublichen Leistungsverbesserungen, aber wir opfern das Webpack-Ökosystem nicht, wir haben es schrittweise verbessert. Sicher, es gab einige sehr kleine Dinge, die geopfert werden mussten, aber das ist ein unglaublicher Vorteil des heutigen JS-Ökosystems, den viele Leute beschönigen, denke ich, weil sie vielleicht sehen: „Oh, wir hätten X machen können in Soho war es vielleicht etwas schneller, oder vielleicht würde MPM in Soho weniger Zeit in Anspruch nehmen.“ Sie nehmen einige Details auf und verpassen das Gesamtbild, nämlich den enormen Wert des Ökosystems.

Drew: Es ist unglaublich, wie wertvoll es ist, die gesamte Konfiguration und Wartung von einem Projekt wie Next.js erledigen zu lassen, anstatt das auf sich zu nehmen, indem man auf etwas anderes umsteigt, denn sobald man sich von diesen Standardeinstellungen entfernt , übernehmen Sie die Last, alle Kompatibilitäten am Laufen zu halten und es selbst zu tun. Eines der Dinge, die mich bei Next.js wirklich interessiert haben, ist, dass es Optionen gibt, die entweder für die Generierung statischer Websites oder für das serverseitige Rendern oder vielleicht für eine Mischung aus beidem verfügbar sind. Ich denke, in einem kürzlichen Update gab es diesbezüglich einige Änderungen. Können Sie uns ein wenig darüber erzählen und wann Sie sich für das eine oder andere entscheiden?

Guillermo: Ja, sicher. Eine der Schlüsselkomponenten dieses hybriden Ansatzes in Kombination mit dem Seitensystem, das ich zuvor beschrieben habe, besteht darin, dass Sie Seiten haben können, die vollständig statisch sind, oder Seiten, die vom Server gerendert werden. Eine Seite, die vollständig statisch ist, hat den unglaublichen Vorteil dessen, was ich als statisches Heben bezeichne, d. h. Sie können dieses Asset nehmen und es automatisch an den Rand stellen. Indem Sie es an den Rand stellen, ich meine, Sie können es zwischenspeichern, Sie können es präventiv zwischenspeichern, Sie können es replizieren, Sie können es so gestalten, dass eine eingehende Anfrage niemals den Server berührt, weil wir es im Voraus wissen. Hey, Slash Index ist eine Statik.“

Guillermo: Das ist ein sehr, sehr interessanter Vorteil, wenn es darum geht, ein globales Publikum zu bedienen. Sie erhalten im Grunde ein automatisches CDN, insbesondere wenn Sie moderne Edge-Netzwerke wie Vercel oder AWS Amplify oder Netlify usw. bereitstellen. Next.js hat diese Prämisse: Wenn es statisch gemacht werden kann, sollte es statisch sein. Wenn Sie zum ersten Mal ein Projekt starten und an Ihrer ersten Seite arbeiten oder die Reifen des Frameworks treten, können Sie genauso gut alles statisch machen.

Guillermo: Selbst für High-End-Anforderungen, wie zum Beispiel vercel.com, ist unsere eigene Verwendung von Next.js vollständig statisch. Es ist eine Kombination aus vollständig statischer und statischer Site-Generierung, also sind alle unsere Marketingseiten statisch, unser Blog wird statisch aus einer dynamischen Datenquelle generiert und dann unser Dashboard, das viele dynamische Daten enthält, aber wir können es als Hüllen oder Skelette liefern , alle Seiten, die mit dem Anzeigen Ihrer Bereitstellungen, Anzeigen Ihrer Projekte, Anzeigen Ihrer Protokolle usw. verbunden sind, sind im Grunde alle statische Seiten mit clientseitigem JavaScript.

Guillermo: Das dient uns unglaublich gut, weil alles, wo wir eine sehr schnelle Leistung im ersten Fenster brauchen, bereits vorgerendert ist, alles, was SEO benötigt, bereits vorgerendert und alles, was extrem dynamisch ist, wir müssen uns nur um die Sicherheit kümmern, denn B. aus der Sicht der Client-Seite, die dieselben API-Aufrufe verwendet, die beispielsweise unsere CLI verwendet oder unsere Integrationen verwenden, und so weiter, und so weiter. Eine vollständig statische Website, sehr günstig im Betrieb, unglaublich skalierbar und so weiter und so weiter.

Guillermo: Eine Sache, die wir bei unserem Blog besonders brauchten, war, dass wir die Daten sehr schnell aktualisieren wollten. Wir wollten einen Tippfehler sehr schnell beheben und nicht warten, bis ein ganzer Build fertig ist, und das ist ein sehr bedeutender Vorteil von Next.js, dass es Ihnen beim Übergang von einem statischen zu einem dynamischen auch diese Zwischenlösungen bietet . Für unseren Blog haben wir die inkrementelle statische Generierung verwendet, sodass wir im Wesentlichen eine Seite nach der anderen neu erstellen können, wenn sich der zugrunde liegende Inhalt ändert.

Guillermo: Stellen Sie sich vor, wir hätten nicht nur ein paar hundert Blog-Posts, sondern viele Blog-Posts, die ständig generiert und ständig aktualisiert werden, wie ich einen unserer Kunden, die Washington Post, erwähnt habe. In diesem Fall müssen Sie gehen mehr in Richtung vollständiger SSR, insbesondere wenn Sie beginnen, den Inhalt für jeden Benutzer anzupassen. Diese Reise der Komplexität, die ich gerade beschrieben habe, begann von „Ich habe eine Marketingseite“ über „Ich habe einen Blog mit ein paar tausend Seiten“ bis hin zu „Ich habe Zehntausende oder Millionen von Seiten“. Das ist die Next.js-Reise, die Sie mit Ihrem eigenen Unternehmen durchlaufen können.

Guillermo: Dann fangen Sie als Entwickler an, zwischen vielleicht weniger Verantwortung und mehr Verantwortung zu wählen, denn wenn Sie sich für die Verwendung von SSR entscheiden, führen Sie jetzt Code auf dem Server aus, Sie führen Code in der Cloud aus, es gibt mehr Verantwortung mehr Macht. Die Tatsache, dass Sie entscheiden können, wo Sie welche Art von Tool verwenden, ist meiner Meinung nach ein sehr, sehr interessanter Vorteil von Next.

Drew: Nur in Bezug auf die praktischen Aspekte der Kombination der statischen Site-Generierung und des serverseitigen Renderings, wie funktioniert das in Bezug auf das Serverelement? Benötigen Sie eine dedizierte Plattform wie Vercel, um dies zu erreichen, oder geht das direkter und einfacher?

Guillermo: Next.js gibt Ihnen einen Dev-Server, also laden Sie Next herunter und führen Ihr Next Dev aus, und das ist der Dev-Server. Der Dev-Server ist offensichtlich unglaublich für die Entwicklung optimiert, da er über die neueste Fast-Refresh-Technologie verfügt, die Facebook veröffentlicht hat, wo … Eigentlich hat Facebook sie nicht veröffentlicht, Facebook verwendet sie intern, um den besten und leistungsfähigsten und zuverlässigsten Hot-Modul-Ersatz zu erhalten , so dass Sie im Grunde tippen und die Änderungen auf dem Bildschirm widergespiegelt werden, das ist also der Dev-Server.

Guillermo: Dann bietet Ihnen Next einen Produktionsserver namens Next Start, und Next Start verfügt über alle Funktionen des Frameworks für das Selbsthosten. Das Interessante an Vercel ist, dass es bei der Bereitstellung von Next to it automatisch optimiert wird und zu 100 % serverlos ist, was bedeutet, dass keinerlei Verantwortung für Verwaltung, Skalierung, Einlösung und Einlösungsvalidierung, Bereinigung, Replikation, globales Failover usw. übernommen wird so her, dass Sie beim Ausführen von Next Start selbst übernehmen müssten.

Guillermo: Das ist auch der große Vorteil von Next.js, so hat beispielsweise apple.com mehrere verschiedene Eigenschaften, Subdomains und Seiten auf dotcom auf Next.js, die sie aufgrund sehr, sehr fortschrittlicher und strenger Sicherheits- und Datenschutzanforderungen selbst hosten . Auf der anderen Seite verwendet washingtonpost.com Vercel, also haben wir eine so breite Palette von Benutzern, und wir freuen uns sehr, sie alle zu unterstützen. Das Schöne an Serverless ist meiner Meinung nach, dass es Ihnen das Beste aus beiden Welten in Bezug auf die optimalste Leistung bieten kann, die mit der Zeit nur besser wird, mit der besten Entwicklererfahrung wie „Hey, habe ich nicht sich um irgendeine Art von Infrastruktur zu kümmern.“

Drew: The Next.js ist ein Open-Source-Projekt, das vom Team von Vercel entwickelt wird. Gibt es andere Mitwirkende außerhalb von Vercel?

Guillermo: Ja, also Google Chrome ist der Hauptserver, der aktiv Server-PRs einreicht, uns bei der Optimierung hilft und es mit Partnern testet, wie sehr große Next.js-Benutzer, die beispielsweise bereits Teil des Google-Ökosystems sind, weil sie viele verwenden und viele Apps, daher müssen sie eng als Partner eingebunden werden. Facebook, wir pflegen eine großartige Beziehung zum Facebook-Team. Zum Beispiel Fast Refresh, wir waren das erste React-Framework, das das geschafft hat, und sie haben uns geholfen, uns durch all die Dinge zu führen, die sie über die Verwendung von React und Fast Refresh bei Facebook gelernt haben.

Guillermo: Wir arbeiten mit vielen Partnern zusammen, die sehr große Bereitstellungen von Next.js-Apps in freier Wildbahn aus allen möglichen Anwendungsfällen haben, wie z. B. E-Commerce und Inhalte. Dann gibt es noch viele, viele unabhängige Mitwirkende, Leute, die Next.js persönlich verwenden, aber auch Pädagogen und Mitglieder von Front-Infrastrukturteams in großen Unternehmen. Es ist eine sehr, sehr breite Gemeinschaftsanstrengung.

Drew: Es klingt wie die Besorgnis, die jemand haben könnte, dass dies zu einem erheblichen Teil von Vercel entwickelt wird, dass sie befürchten könnten, dass sie sich irgendwie auf die Bereitstellung auf dieser bestimmten Plattform festlegen, aber es hört sich an ganz so, als wäre das überhaupt nicht der Fall, und sie könnten eine Website entwickeln und sie auf Firebase oder Netlify bereitstellen oder …

Guillermo: Ja, absolut. Ich vergleiche es gerne in gewisser Weise mit Kubernetes des Front-End-Zeitalters, denn am Ende des Tages bin ich fest davon überzeugt, dass … Kubernetes etwas ist, das so ziemlich fast jeder braucht, wenn er Linux-Prozesse ausführen muss , als ob Sie über Meinungsbildung sprachen und sagten, dass es eine gute Technologie ist, es ist sehr viel nicht eigensinnig, aber es gibt einige Meinungen, die wir irgendwie vergessen. Es ist, als wäre es am Ende des Tages aus der Ausführung bestimmter Dämonen von Linux-Programmen entstanden, die als Container verpackt sind.

Guillermo: Next ist in einer ähnlichen Position, weil das, was wir für das universelle Primitiv der Welt als React-Komponente halten, offensichtlich eigensinnig ist, aber wir denken, dass wir für viele Unternehmen, so wie sie alle zu Linux hingezogen sind, auch sind Dasselbe gilt für React und Vue, aber Vue hat glücklicherweise auch Nuxt, was eine sehr großartige Lösung ist, die von der Idee und den Prinzipien her gleichwertig mit Next ist. Wir tendieren zu diesen Plattformen wie Next.js, wie Nuxt, wie Sapper für das Svelte-Ökosystem.

Guillermo: Ich denke, das sollten offene Plattformen sein, denn wenn jeder das braucht, könnte man das Rad in der gesamten Branche genauso gut nicht neu erfinden, oder? Wir begrüßen diese Position sehr, wir begrüßen Menschen, die sie einsetzen und neu konfigurieren und neu aufbauen und neu verteilen und so weiter.

Drew: Erst kürzlich wurde eine neue Version von Next.js veröffentlicht, ich glaube Version 9.5. Welche wesentlichen Änderungen gab es in dieser Version?

Guillermo: Das Tollste ist, wie ich bereits sagte, dass viele Dinge statisch beginnen und dann dynamischer werden, wenn die Dinge wachsen. Das war übrigens das Wagnis für WordPress. WordPress basierte anfangs auf einem Ansatz mit statischen Dateidatenbanken und benötigte dann eine Datenbank, ähnlich wie Sie beschrieben haben, wie sich PHP immer mehr zu MySQL entwickelt hat. Das Schöne an Next.js 9.5 ist, dass es die inkrementelle statische Generierung zu einem produktionsbereiten Feature macht, also haben wir es aus dem Unstable-Flag genommen.

Guillermo: Diese Funktion ermöglicht es Ihnen, diese Reise von statisch zu dynamisch zu machen, ohne auf alle statischen Vorteile verzichten zu müssen und ohne sich voll und ganz auf vom Server gerenderte dynamische zu verlassen, sodass die Nutzungsdauer Ihrer Art von statischer Sprache verlängert wird. Die Art und Weise, wie wir es zum Beispiel bei Vercel verwenden, ist, wie ich bereits erwähnt habe, als ob unser Blog zur Erstellungszeit vollständig vorgerendert wird, aber dann zum Beispiel sind wir tatsächlich in ein paar Minuten dabei, eine wichtige Ankündigung zu machen, und wann Wir bloggen darüber, wir möchten in der Lage sein, es zu optimieren, zu reparieren, eine Vorschau anzuzeigen usw., ohne jedes Mal, wenn wir einen Buchstaben in einem Blogbeitrag ändern, einen fünf- bis zehnminütigen Build erstellen zu müssen.

Guillermo: Mit der inkrementellen statischen Generierung können Sie jeweils eine Seite neu erstellen. Was je nach Größe Ihrer Website Minuten oder sogar Sekunden dauern konnte, dauert jetzt Millisekunden. Auch hier mussten Sie auf keinen der Vorteile der statischen Aufladung verzichten. Das ist vielleicht das, worüber ich mich am meisten freue, dass es auf Next.js 9.5 stabil gelaufen ist, und insbesondere, weil die JS-Community und die React-Community und die Framework-Community und die Community für statische Sites über dieses Einhorn gesprochen haben, für das ein statisches Inkrement erstellt wird 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: Das ist faszinierend. 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. Hast du Abschiedsworte?

Guillermo: No, thank you for having me.