Smashing Podcast Episodul 23 cu Guillermo Rauch: Ce este Next.js?

Astăzi, vorbim despre Next.js. Ce este și unde s-ar putea încadra în fluxul nostru de lucru de dezvoltare web? Am vorbit cu co-creatorul Guillermo Rauch pentru a afla.

Afișați note

• Guillermo Rauch pe Twitter
• Next.js

Actualizare săptămânală

• „Stăpânirea elementelor de recuzită și a tipurilor de elemente în reacție”
  de David Adeneye
• „Decizii de design inspirate cu Bradbury Thompson: Arta designului grafic”
  de Andy Clarke
• „Configurarea unui API folosind Flask, Cloud SQL Google și App Engine”
  de Wole Oyekanmi
• „Forme și validare în reacția ionică”
  de Jerry Navi
• „Cum să vă ajutați clienții să obțină mai multe backlink-uri prin design”
  de Suzanne Scacca

Transcriere

Drew McLellan: El este fondatorul și CEO-ul Vercel, o platformă cloud pentru site-uri statice care se potrivește unui flux de lucru Jamstack. El este și co-creatorul Next.js. El a fondat anterior LearnBoost și CloudUp și este binecunoscut ca creatorul mai multor biblioteci cu sursă deschisă noduri populare, cum ar fi Socket.io, Mongoose și SlackIn. Înainte de asta, el a fost un dezvoltator de bază pe MooTools, așa că știm că se pricepe la JavaScript ca pe dosul mâinii. Știați că odată a primit o comisie regală de la Regele Spaniei pentru a crea o sculptură de gheață din salată iceberg? Prietenii mei zdrobitori, vă rog bun venit lui Guillermo Rauch. Salut Guillermo, ce mai faci?

Guillermo Rauch: Sunt foarte bine, mulțumesc că m-ai primit.

Drew: Am vrut să vă vorbesc astăzi despre întreaga lume Next.js, deoarece este ceva despre care, evident, sunteți foarte bine informat, fiind implicat ca co-creator chiar de la început. Next.js este unul dintre acele nume de proiecte care a fost pe radarul meu în timp ce lucram în spațiul Jamstack, dar nu este ceva la care de fapt m-am uitat personal sau cu care am lucrat prea îndeaproape înainte. Pentru oamenii care sunt ca mine, care poate nu sunt conștienți de ce este Next.js, poate ați putea să ne oferiți câteva informații despre ce este și ce probleme încearcă să rezolve.

Guillermo: Next.js este un membru foarte interesant al universului Jamstack, deoarece Next.js a început să fie de fapt un cadru complet concentrat pe SSR. A început să fie foarte mult adoptat în afara spațiului Jamstack, unde oamenii construiau lucruri foarte mari, în special atunci când doreau să aibă conținut generat de utilizatori sau conținut dinamic sau rețele sociale sau comerț electronic și știau că vor SSR deoarece setul lor de date era foarte mare sau foarte dinamică. Cred că a căzut sub radar pentru mulți oameni din lumea Jamstack, dar mai târziu Next.js a dobândit capacitățile de optimizare statică.

Guillermo: Pe de o parte, de exemplu, dacă nu ați face preluarea datelor la nivelul superior al paginii dvs. cu Next.js, pagina dvs. React ar fi... De asemenea, apropo, pentru cei care nu cunosc pe deplin, Next.js este pur și simplu cadru React pentru producție, dar are această capacitate de a face unele randări. Apoi, când intrați în capabilitățile de optimizare statică, dacă nu ați defini preluarea datelor la nivelul superior al paginii dvs., aceasta se va exporta automat ca HTML în loc să încercați să faceți ceva cu randarea serverului.

Guillermo: Apoi, mai târziu, a câștigat și capacitatea de generare de site-uri statice, ceea ce înseamnă că puteți defini un cârlig de date special, dar acel cârlig de date primește date în timpul construirii. Next.js a devenit un cadru hibrid, dinamic și static foarte puternic, iar acum a crescut mult și în spațiul Jamstack.

Drew: Oamenii ar putea spune că React este deja un cadru, cu siguranță îl auzi descris în acest fel. Ce înseamnă de fapt să fii un cadru pentru React?

Guillermo: Este o observație grozavă, pentru că întotdeauna le subliniez oamenilor că React at Facebook și React în afara Facebook sunt animale complet diferite. React at Facebook este de fapt folosit împreună cu randarea serverului, dar chiar și redarea serverului lor, de exemplu, nu folosește Node.js, folosește o mașină virtuală foarte specializată numită Hermes care comunică cu tipul lor de hack de producție și stiva PHP și răspunde. toate acestea avansate și exotice de care Facebook are nevoie.

Guillermo: Când deschid sursa React, este aproape ca și cum ar fi deschis o componentă. Întotdeauna îl numesc ca și cum am achizitionat motorul, dar nu îți dau mașina. Ceea ce s-a întâmplat este că oamenii au vrut cu adevărat să meargă să conducă cu el, au vrut să ajungă în locuri cu React. În comunitate, oamenii au început să creeze mașini și aveau să încorporeze React ca motor, ceea ce urmărea în primul rând șoferul, dezvoltatorul, făcând din React partea fundamentală a mașinii. Au început să apară lucruri precum Next.js și Gatsby și React Static și multe alte cadre care au rezolvat nevoia de genul „De fapt, vreau să creez pagini și aplicații complet încărcate”.

Guillermo: În timp ce React semăna mai mult cu componenta și motorul pentru anumite widget-uri din pagină, acesta a fost cu siguranță cazul pentru Facebook. Ei vor recunoaște în mod larg și public că l-au inventat pentru lucruri precum lotul de notificări, widgetul de chat, componenta flux de știri, iar acele componente erau rute React care au fost încorporate în conținutul aplicației existente de producție cu o mulțime de linii de cod. și chiar și alte biblioteci și cadre JS.

Guillermo: Ce înseamnă să creezi un cadru pentru React, înseamnă că faci din React partea fundamentală a poveștii, sperăm și asta este ceva ce vom încerca să facem cu Next.js, curba de învățare se referă în primul rând la React cu ceva adăugat suprafață pentru Next.js, în special în ceea ce privește preluarea și rutarea datelor. Facem, de asemenea, o mulțime de optimizări ale producției, așa că atunci când obțineți React, când obțineți aplicația Create React, care este un fel, îmi place să o numesc o mașină bootstrapped pe care ți-o oferă Facebook, poate că nevoile de producție nu sunt într-adevăr îndeplinite . Sau dacă încercați să o faceți singur, configurând Webpack și configurând Babel și configurând randarea serverului și generarea statică, este, de asemenea, greu să puneți împreună o mașină de la zero. Next.js vă va oferi această configurație zero și, de asemenea, un set de setări implicite optimizate pentru producție în jurul construirii unor lucruri mari cu React.

Drew: Așa că este ca și cum aproape că pune un fel de ecosistem în jurul aplicației dvs. React cu o colecție de instrumente preconfigurate pentru a vă permite să...

Guillermo: Corect.

Drew: Porniți la sol și faceți generarea statică a site-ului sau randarea sau rutarea serverului.

Guillermo: Corect, și ai folosit acolo un cuvânt care este foarte, foarte cheie pentru toate acestea, care este pre-configurat. Avem norocul să atragem atenția Google Chrome în calitate de colaborator la Next.js. Unul dintre liderii acestui proiect, lucrul ei este că atunci când lucrau la framework-uri intern la Google, s-au confruntat cu multe probleme cu care se confruntă comunitatea și sursa deschisă astăzi. Au existat multe inițiative concurente la Google cu privire la modul de scalare și de a crea aplicații web cu adevărat performante.

Guillermo: Te-ai alătura ca Googler și ți s-ar oferi un cadru prin care ai crea aplicații foarte gata de producție, foarte performante. Shubie a făcut parte din multe dintre aceste inițiative și ceea ce a descoperit este că există două ingrediente cheie pentru ca un cadru să aibă succes la scară. Una este preconfigurarea, adică veniți la muncă, veți începe o aplicație nou-nouță, ar trebui să vi se ofere ceva care este deja gata de funcționare și care îndeplinește multe dintre cerințele de producție care sunt cunoscute la acel moment dat. la timp.

Guillermo: Pe de altă parte, celălalt pas cu adevărat important spre care lucrăm este conformarea. Vi se poate oferi cel mai optimizat cadru preconfigurat gata de producție, dar dacă mergeți mai departe și, de exemplu, începeți să introduceți o mulțime de dependențe grele sau scripturi de la terți sau folosiți machete foarte ineficiente care durează mult timp pentru a picta și așa mai departe și așa mai departe, atunci vei face ca pre-configurarea să se piardă. Combinând preconfigurarea cu conformitatea de-a lungul timpului, dezvoltatorul nu numai că are un punct de plecare excelent, dar este și ghidat către succes în timp.

Drew: Se pare că o caracteristică a Next.js, că este destul de obișnuit, stratul UI este React, folosește script de tip, folosește Webpack și toate acestea sunt alegeri pe care le-a făcut proiectul și asta obțineți. Corectați-mă dacă greșesc, dar nu ați putut schimba React cu Vue, de exemplu, în Next.js.

Guillermo: Acesta este un punct bun, în care luarea deciziilor tehnice întâlnește un fel de artă. Pe de o parte, aș dori foarte mult să susțin că Next este foarte lipsit de păreri, iar motivul pentru aceasta este că, dacă accesați în mod specific github.com/vercel/nextjs și directorul de exemple, veți vedea că există aproape un explozie combinatorică de tehnologii pe care le puteți folosi împreună cu Next.js. Veți vedea bazat pe foc, veți vedea Graphic UL, veți vedea Apollo, veți vedea Redux, veți vedea MobX, în spațiul CSS există și mai multe opțiuni.

Guillermo: Avem un port CSS implicit care este încorporat, dar apoi puteți folosi două variante ale acestuia, una cu import, una cu etichete de stil pe care le numim Style JSX, care seamănă foarte mult cu abordarea platformei web a Shadow CSS. Motivul pentru care mă refer la lipsit de păreri este că vrem ca Next.js să rămână foarte aproape de „bare metal” al web-ului și să nu introducă o mulțime de primitivi cu care, dacă web-ul de la 10 ani de astăzi ar fi incompatibil. Apoi, dacă te uiți la exemple, vei vedea că există toate aceste alte tehnologii pe care le poți conecta.

Guillermo: Nivelul de bază al opiniei este că există React și nu o veți putea înlocui, cel puțin în curând. Apoi, există conceptul că ar trebui să poți crea pagini și asta a fost un fel de ceva nou când l-am lansat prima dată, adică toată lumea încearcă să creeze aplicații cu o singură pagină. Ceea ce ne-am dat seama este ca și cum internetul este alcătuit din site-uri web cu o mulțime de pagini care creează puncte de intrare distincte prin motoarele de căutare, prin Twitter, prin Facebook, prin rețelele sociale, prin e-mail-uri însoțitoare, așa cum ai îndruma întotdeauna persoana către un punct de intrare, și acea persoană care trece prin acel punct de intrare nu ar trebui să fie nevoită să descarce povara întregii aplicații.

Guillermo: Apoi, acea cale ne-a condus la implementarea redării serverului, apoi generarea statică pentru mai multe pagini, etc., etc. Celălalt nivel de bază de opinie este Următorul ar trebui să fie un cadru care funcționează pentru web, nu împotriva web. Apoi, pe deasupra, React lipsea primitivele de preluare și rutare a datelor, iar noi le-am adăugat. Există un nivel de opinie cu care trebuie să se ocupe de cum toată lumea are nevoie de un router, așa că ar putea la fel de bine să aibă un router încorporat implicit.

Drew: Marele avantaj al acestor valori implicite este că elimină o mare parte din complexitatea alegerii, că este doar acolo, este configurat și poți să începi să-l folosești fără a fi nevoie să te gândești prea mult, pentru că cred că toți avem -

Guillermo: Exact.

Drew: Am fost în situații în care există prea multe opțiuni privind componentele de utilizat și poate fi copleșitor și poate împiedica să fii productiv.

Guillermo: Exact.

Drew: Pentru ce fel de proiecte vedeți oamenii care folosesc Next.js? Este practic pentru orice situație în care ați putea construi o aplicație React de producție sau este mai potrivită pentru anumite tipuri de site-uri cu conținut intens? Contează în acest sens?

Guillermo: Da, deci aceasta a fost o dezbatere veche despre web, este web-ul pentru aplicații, este web-ul pentru site-uri, este un hibrid? Care este rolul JavaScript, etc., etc.? Este cam greu să dau un răspuns direct, dar părerea mea este că web-ul a fost întotdeauna dezvoltat pentru a fi un hibrid de conținut care evoluează pentru a fi din ce în ce mai dinamic și mai personal pentru utilizator. Chiar și atunci când spui ca un site web de conținut, site-urile web cu conținut de vârf ale lumii au baze de coduri care sunt foarte comparabile cu aplicațiile.

Guillermo: Un exemplu grozav aici este ca New York Times, vă vor oferi widget-uri încorporate cu instrumente de analiză a datelor și animație interactivă și vă vor recomanda ce poveste să citiți în continuare și au un model de abonament construit în care uneori vă oferă parte din conținut și uneori numără câte articole ați citit. Ca și cum v-aș spune asta când a fost inventat web-ul, cum ar fi Tim Berners-Lee: „Nu, asta e o nebunie, asta nu se poate pe web”, dar acesta este web-ul pe care îl avem astăzi.

Guillermo: Next.js răspunde la multe dintre aceste nevoi moderne complexe, ceea ce înseamnă că veți vedea o mulțime de utilizare a comerțului electronic, veți vedea o mulțime de conținut cu asta. Comerțul electronic înseamnă, apropo, nu doar ca cumpără articole, ci experiențe precum cele mai mari site-uri imobiliare de pe web, realtor.com, zillow.com, trulio.com, întreaga categorie este tot Next.js, apoi conținut site-uri. Tocmai am introdus washingtonpost.com ca client al Vercel și Next.js, avem apoi o a treia categorie care este mai emergentă, dar foarte interesantă, care sunt aplicații complete și conținut generat de utilizatori, cum ar fi tiktok.com și cam ca tine. ar crede că cazul de utilizare original al aplicației cu o singură pagină este destul de reprezentat acolo.

Guillermo: Next.js strălucește atunci când trebuie să ai o mulțime de conținut care trebuie să fie difuzat foarte, foarte repede, trebuie să fie optimizat SEO și, la sfârșitul zilei, este un amestec de dinamic și static.

Drew: Am vorbit anterior cu Marcy Sutton despre Gatsby, care pare să fie într-un spațiu similar. Este întotdeauna grozav să vezi mai multe soluții la o problemă și să ai de ales pentru un proiect la următorul. Ați spune că Next.js și Gatsby operează în același tip de spațiu cu probleme și cât de similare sau diferite sunt acestea?

Guillermo: Cred că există o suprapunere pentru unele cazuri de utilizare. De exemplu, blogul meu personal rauchg.com rulează pe Next.js, ar fi putut fi și un blog grozav Gatsby. Există acea suprapunere în spațiul mai mic al site-ului web static și prin mic nu vreau să spun că nu este relevant. O mulțime de dotcom care sunt super, super importante rulează pe web practic static, așa că asta este frumusețea Jamstack, după părerea mea. Deoarece Next.js vă poate optimiza static paginile și apoi puteți obține scoruri excelente Lighthouse prin asta, îl puteți folosi pentru cazuri de utilizare suprapuse.

Guillermo: Cred că linia este trasă atunci când începi să intri în nevoi mai dinamice și ai o mulțime de pagini, trebuie să le actualizezi la un moment dat. Deși Gatsby creează soluții pentru acestea, Next.js are deja soluții live gata de producție care funcționează cu orice tip de bază de date, orice tip de backend de date pentru, practic, „generarea” sau „imprimarea” o mulțime de pagini. Aici clienții de astăzi merg la Next.js în loc de Gatsby.

Drew: Una dintre problemele cu care toată lumea pare să se confrunte pe măsură ce soluția lor bazată pe JavaScript devine mai mare este performanța și modul în care lucrurile pot începe să devină destul de lente, aveți pachete de dimensiuni mari. În mod tradițional, lucruri precum împărțirea codului pot fi destul de complexe pentru a fi configurate corect. Văd că aceasta este una dintre caracteristicile care mi-au sărit în evidență ale Next.js, că pretinde că împărțirea codului este automată. Ce face Next.js în ceea ce privește împărțirea codului pentru ca acest lucru să funcționeze?

Guillermo: Observația ta este 100% corectă. Unul dintre cele mai mari lucruri cu web și una dintre cele mai mari greutăți de pe web este JavaScript și, la fel cum diferitele materiale au densități și greutăți diferite, indiferent de volumul fizic real, JavaScript tinde să fie un element foarte dens și greu. Chiar și cantități mici de JavaScript în comparație cu, de exemplu, imaginile care pot fi procesate asincron și în afara firului principal, JavaScript tinde să fie deosebit de deranjant.

Guillermo: Next.js a investit o cantitate enormă de efort în optimizarea automată a pachetelor dvs. Prima care a fost prima mea intuiție când mi-a venit prima idee pentru Next.js a fost că vei defini, de exemplu, 10 rute. În lumea Next.js, creați un director de pagini și plasați fișierele acolo Index.js, About.js, Settings.js, Dashboard.js, Termsofservice.js, Signup.js, Login.js. Acestea devin puncte de intrare în aplicația dvs. pe care le puteți partaja prin toate tipurile de media.

Guillermo: Când le introduceți, vrem să vă oferim JS care este relevant pentru pagina respectivă în primul rând, și apoi poate un pachet comun, astfel încât navigațiile ulterioare în sistem să fie foarte rapide. De asemenea, Next.js, care este foarte, foarte frumos, preia automat restul paginilor care sunt conectate la acel punct de intrare, astfel încât să pară o aplicație cu o singură pagină. Mulți oameni spun: „De ce să nu folosești aplicația Create React dacă știu că am poate câteva rute?” Întotdeauna le spun: „Uite, le poți găsi ca pagini și, deoarece Next.js le va prelua automat pe cele care sunt conectate, ajungi să obții aplicația ta pe o singură pagină, dar este mai bine optimizată în ceea ce privește acea vopsea inițială. , acel punct de intrare inițial.”

Guillermo: Aceasta a fost abordarea inițială a împărțirii codului, dar apoi a devenit mult mai sofisticată în timp. Google a contribuit la o optimizare foarte frumoasă numită Module and No Module, care va oferi JS diferențial browserelor moderne și JS moștenit, care este greoi cu câmpuri polivalente pentru alte browsere, iar această optimizare este 100% automatizată și produce economii masive. L-am dat unuia dintre clienții noștri pe care îl găzduim pe Vercel numit Parnaby's, cred că dacă nu mă înșel, a fost ceva foarte, foarte semnificativ. A fost poate economii de 30% în dimensiunile codului și asta doar pentru că au făcut upgrade Next.js la o versiune care a optimizat mai bine pachetele JS.

Guillermo: Cam acesta a fost punctul pe care îl discutam mai devreme, adică tu alegi Next.js și doar devine mai bun și mai optim în timp, va continua să optimizeze lucrurile în numele tău. Acestea sunt, din nou, preconfigurari cu care nu ai avea de-a face niciodata sau cu care nu ai fi deranjat, si a caror cercetare nici nu vrei sa o faci niciodata, sincer sa fiu. De parcă nu eram, evident, foarte implicat în asta, dar mă uit la unele dintre discuțiile interne și discutau despre toate aceste policâmpuri care contau doar pentru Internet Explorer X și Soho, am spus: „Nici nu vreau să știu. , haideți să facem upgrade Next.js și să obținem toate aceste beneficii.”

Drew: Există uneori beneficii mari acolo, dacă rămâneți cu valorile implicite și rămâneți cu cea mai comună configurație a lucrurilor, care pare să fie într-adevăr abordarea Next.js. Îmi amintesc când am început să scriu PHP la începutul anilor 2000 și toată lumea folosea PHP și MySQL, iar la acea vreme tocmai veneam de la Windows, așa că am vrut să folosesc PHP și Microsoft Sequel Server. Poți să o faci, dar înoți împotriva curentului pe tot drumul. Apoi, de îndată ce tocmai am trecut la MySQL, întregul ecosistem tocmai a început să funcționeze pentru mine și nu a trebuit să mă gândesc la asta.

Guillermo: Da, totul face doar clic, aceasta este o observație grozavă. Vedem că tot timpul, cum ecosistemul Babel este atât de puternic acum, încât ai putea deveni, de exemplu, puțin mai rapid schimbând Babel cu altceva, dar apoi schimbi acea compatibilitate incredibilă cu ecosistemul. Acesta este un lucru pe care l-ați atins mai devreme de performanță și, ca pentru mulți oameni, performanța de construire și performanța generației statice reprezintă un blocaj mare, iar acesta este ceva cu care suntem foarte sârguincioși în îmbunătățirea performanței instrumentelor noastre treptat.

Guillermo: De exemplu, unul dintre lucrurile pe care Next.js le face acum este că își actualizează implicit de la Webpack 4 la Webpack 5, care are câteva lucruri defectuoase, și de aceea îl oferim mai întâi oamenilor ca opțiune. în flag, dar mai târziu va deveni implicit. Webpack 5 aduce îmbunătățiri incredibile de performanță, dar nu sacrificăm ecosistemul Webpack, ci am îmbunătățit treptat. Sigur, au fost câteva lucruri foarte mici care trebuiau sacrificate, dar acesta este un beneficiu incredibil al ecosistemului JS astăzi pe care mulți oameni îl trec cu vederea, cred, pentru că poate văd: „Oh, am fi putut face X. în Soho, poate a fost puțin mai rapid, sau poate MPM în Soho ar dura mai puțin timp.” Ei adună câteva detalii și le scapă imaginea de ansamblu, adică valoarea ecosistemului este enormă.

Drew: Valoarea de a avea toată configurația și întreținerea și acea parte a acesteia realizată de un proiect precum Next.js, mai degrabă decât să vă asumați asta pentru dvs., schimbând pentru a folosi altceva, este incredibilă, pentru că de îndată ce vă îndepărtați de acele valori implicite , vă asumați sarcina de a menține toate compatibilitățile și de a o face singur. Unul dintre lucrurile care m-au interesat cu adevărat cu Next.js este că există opțiuni disponibile pentru generarea statică a site-ului sau randarea pe server, sau poate un hibrid dintre cele două. Cred că au avut loc câteva modificări recente la aceasta într-o actualizare recentă, ne puteți spune puțin despre asta și când ați putea alege una sau alta?

Guillermo: Da, cu siguranță. Una dintre componentele cheie ale acestei abordări hibride combinată cu sistemul de pagini pe care l-am descris mai devreme este că puteți avea pagini care sunt complet statice sau pagini pe care serverul le-a randat. O pagină care este complet statică are avantajul incredibil al ceea ce eu numesc ridicare statică, adică poți lua acel activ și îl poți pune automat la margine. Punându-l la margine, vreau să spun că îl poți stoca în cache, îl poți stoca preventiv, îl poți replica, îl poți face astfel încât, atunci când vine o solicitare, să nu atingă serverul pentru că știm dinainte, ” Hei, Slash Index este un static.”

Guillermo: Acesta este un beneficiu foarte, foarte interesant când vine vorba de deservirea publicului global. Practic, obțineți un CDN automat din cutie, mai ales când implementați rețelele moderne de margine precum Vercel sau AWS Amplify sau Netlify și așa mai departe. Next.js are această premisă: dacă poate fi static, ar trebui să fie static. Când începeți pentru prima dată un proiect și lucrați la prima pagină sau dați cu piciorul în cauciucurile cadrului, ar putea la fel de bine să faceți totul static.

Guillermo: Chiar și pentru nevoi de vârf, de exemplu, vercel.com, propria noastră utilizare a Next.js este complet statică. Este o combinație de generare complet statică și statică a site-ului, așa că toate paginile noastre de marketing sunt statice, blogul nostru este generat static dintr-o sursă de date dinamice și apoi tabloul de bord care conține o mulțime de date dinamice, dar le putem livra sub formă de cochilii sau schelete. , toate paginile asociate cu vizualizarea implementărilor dvs., vizualizarea proiectelor dvs., vizualizarea jurnalelor dvs. etc. etc., toate sunt practic pagini statice cu JavaScript pe partea clientului.

Guillermo: Asta ne servește incredibil de bine pentru că tot ceea ce avem nevoie de o performanță foarte rapidă în primul panou este deja pre-rendat, tot ceea ce are nevoie de SEO, deja pre-rendat și tot ceea ce este extrem de dinamic, trebuie să ne facem doar griji de securitate, pentru de exemplu, din perspectiva părții client care utilizează aceleași apeluri API pe care, de exemplu, CLI-ul nostru le-a folosit sau integrările noastre, etc., etc. Un site web complet static, foarte ieftin de operat, incredibil de scalabil și așa mai departe.

Guillermo: Acum, un lucru special de care aveam nevoie cu blogul nostru era că doream să actualizăm datele foarte repede. Am vrut să remediam o greșeală de tipar foarte repede și să nu așteptăm să se întâmple o construcție întreagă, iar acesta este un beneficiu foarte important al Next.js, că, pe măsură ce treceți de la un static la unul dinamic, vă oferă și acestea între soluții. . Pentru blogul nostru am folosit generarea statică incrementală, astfel încât, în esență, putem reconstrui o pagină la un moment dat când conținutul de bază se schimbă.

Guillermo: Imaginați-vă că nu aveam doar câteva sute de postări pe blog și că aveam o mulțime de postări de blog generate tot timpul și actualizate tot timpul, așa cum am menționat unul dintre clienții noștri, Washington Post, în acest caz trebuie să mergeți mai mult către SSR complet, mai ales când începeți să personalizați conținutul pentru fiecare utilizator. Acea călătorie a complexității pe care tocmai am descris-o a început de la am o pagină de marketing, până la un blog care are câteva mii de pagini, până la zeci de mii sau milioane de pagini. Aceasta este călătoria Next.js pe care o poți parcurge cu propria ta afacere.

Guillermo: Apoi începi ca dezvoltator să alegi între probabil mai puțină responsabilitate și mai multă responsabilitate, pentru că atunci când optezi pentru utilizarea SSR, acum executați cod pe server, executați cod pe cloud, există mai multă responsabilitate cu mai multă putere. Faptul că poți decide unde folosești fiecare tip de instrument este cred că un beneficiu foarte, foarte interesant al Next.

Drew: Doar în ceea ce privește aspectele practice ale combinării generării site-ului static și redării pe partea serverului, cum funcționează asta în ceea ce privește elementul server? Ai nevoie de o platformă dedicată precum Vercel pentru a putea realiza asta sau este ceva care poate fi făcut mai simplu și mai simplu?

Guillermo: Next.js vă oferă un server de dezvoltare, așa că descărcați Next și rulați Next Dev, iar acesta este serverul de dezvoltare. Serverul de dezvoltare este, evident, incredibil de optimizat pentru dezvoltare, ca și cum are cea mai recentă tehnologie de reîmprospătare rapidă lansată de Facebook, unde... De fapt, Facebook nu a lansat-o, Facebook îl folosește intern pentru a obține cea mai bună, mai performantă și mai fiabilă înlocuire a modulului cald. , astfel încât practic tastați și modificările se reflectă pe ecran, deci acesta este serverul de dezvoltare.

Guillermo: Apoi Next vă oferă un server de producție numit Next Start, iar Next Start are toate capabilitățile cadrului pentru auto-găzduire. Lucrul interesant despre Vercel este că atunci când implementați Alături de el, acesta devine automat optimizat și este 100% fără server, ceea ce înseamnă că nu există nicio responsabilitate pentru administrare, scalare, încasări și validare încasării, purjare, replicare, failover global și așa mai departe și așa mai departe, încât ar trebui să vă asumați atunci când rulați dvs. Next Start.

Guillermo: Acesta este, de asemenea, marele beneficiu al Next.js, așa că, de exemplu, apple.com are mai multe proprietăți, subdomenii și pagini diferite pe dotcom pe Next.js pe care le găzduiesc, datorită nevoilor foarte, foarte avansate și stricte de securitate și confidențialitate. . Pe de altă parte, washingtonpost.com folosește Vercel, așa că avem acest tip de gamă largă de utilizatori și suntem extrem de bucuroși să îi sprijinim pe toți. Lucrul frumos despre unde se îndreaptă serverless, după părerea mea, este că vă poate oferi tot ce este mai bun din ambele lumi în ceea ce privește cea mai optimă performanță care se îmbunătățește doar în timp, cu cea mai bună experiență de dezvoltator de genul „Hei, nu am să vă faceți griji pentru orice fel de infrastructură.”

Drew: Next.js este un proiect open source care este dezvoltat de echipa de la Vercel. Există și alți colaboratori în afara Vercel?

Guillermo: Da, deci Google Chrome fiind principalul care trimite activ PR-uri de server, ne ajută cu optimizări și testări cu parteneri, cum ar fi utilizatorii foarte mari Next.js care fac deja parte din ecosistemul Google, de exemplu, din cauza utilizării multor și o mulțime de aplicații, așa că trebuie să fie implicați îndeaproape ca parteneri. Facebook, menținem o relație excelentă cu echipa Facebook. De exemplu, reîmprospătare rapidă, am fost primul cadru React care a obținut asta și ne-au ajutat să ne ghidăm prin toate lucrurile pe care le-au învățat despre utilizarea React și reîmprospătarea rapidă la Facebook.

Guillermo: Lucrăm cu o mulțime de parteneri care au implementări foarte mari ale aplicațiilor Next.js în sălbăticie din tot felul de cazuri de utilizare diferite, cum ar fi comerțul electronic și conținutul imaginați. Apoi, există o mulțime de colaboratori independenți, oameni care folosesc Next.js personal, dar și educatori și membri ai echipelor de infrastructură frontale la companii mari. Este un efort comunitar foarte, foarte larg.

Drew: Pare îngrijorarea pe care cineva o poate avea, că acest lucru este dezvoltat într-o mare parte de către Vercel, că ar putea avea îngrijorarea că vor fi oarecum blocați să se desfășoare pe platforma respectivă, dar sună ca și cum nu este deloc așa, și ar putea dezvolta un site și să-l implementeze pe Firebase sau Netlify sau...

Guillermo: Da, absolut. Îmi place să-l compar mult pentru Kubernetes din era Front End într-un fel, pentru că, la sfârșitul zilei, sunt ferm convins că... Kubernetes este ceva de care aproape toată lumea are nevoie atunci când trebuie să ruleze procese Linux , ca și cum ai vorbit despre opinie și spui că este o tehnologie bună, nu este foarte opinie, dar există unele opinii de care cam uităm. Este ca și cum, la sfârșitul zilei, a apărut din rularea unor demoni specifici de programe Linux ambalate ca containere.

Guillermo: Următorul este într-o poziție similară, pentru că ceea ce considerăm ca fiind primitivul universal al lumii ca componentă React, evident este o părere, dar credem că pentru multe întreprinderi, la fel cum toate gravitează spre Linux, suntem Văzând același lucru față de React și Vue, dar Vue are, din fericire, și Nuxt, care este o soluție foarte grozavă, este echivalentă în idee și principii ca Next. Gravităm către aceste platforme precum Next.js, precum Nuxt, precum Sapper pentru ecosistemul Svelte.

Guillermo: Cred că acestea ar trebui să fie platforme deschise, pentru că din nou, dacă toată lumea va avea nevoie de asta, ar putea la fel de bine să nu reinventeze roata în întreaga industrie, nu? Salutăm foarte mult această poziție, salutăm oamenii să o implementeze și să o reconfigureze și să o reconstruiască și să o redistribuie și așa mai departe.

Drew: Recent a fost lansată o nouă versiune a Next.js, cred că versiunea 9.5. Ce schimbări semnificative au existat în acea versiune?

Guillermo: Cel mai grozav este, așa cum spuneam mai devreme, multe lucruri încep statice și apoi devin mai dinamice pe măsură ce lucrurile cresc. Aceasta a fost afacerea pentru WordPress, de altfel. WordPress la început s-a bazat pe o abordare a bazei de date de fișiere statice, iar apoi a devenit nevoie de o bază de date, un fel ca ceea ce ați descris cu modul în care PHP a evoluat pentru a deveni din ce în ce mai MySQL. Ceea ce este frumos la Next.js 9.5 este că face generarea statică incrementală o caracteristică pregătită pentru producție, așa că am scos-o din flag-ul instabil.

Guillermo: Această caracteristică vă permite să faceți acea călătorie de la static la dinamic, fără a renunța la toate beneficiile statice și fără a fi nevoie să mergeți la maxim pentru dinamica redată de server, astfel încât să prelungească durata de viață utilă a tipului dvs. de static. Modul în care îl folosim la Vercel, de exemplu, așa cum am menționat, este ca și cum blogul nostru este complet pre-redat în timpul construirii, dar apoi, de exemplu, suntem de fapt în câteva minute pe cale să facem un anunț major și când Blogueăm despre asta, vrem să putem să-l modificăm, să-l reparăm, să-l previzualizează și cetera, fără a fi nevoie să emitem o versiune de cinci până la 10 minute de fiecare dată când schimbăm o literă dintr-o postare de blog.

Guillermo: Cu generarea statică incrementală, puteți reconstrui o pagină odată. Ceea ce ar putea dura minute sau chiar secunde, în funcție de cât de mare este site-ul dvs., durează acum milisecunde. Din nou, nu a trebuit să renunți la niciunul dintre beneficiile statice. Acesta este, probabil, lucrul de care sunt cel mai încântat, care a devenit stabil pe Next.js 9.5, și mai ales pentru că comunitatea JS și comunitatea React și comunitatea cadru și comunitatea generată de site-uri static au vorbit despre acest unicorn de a face un incremental static pentru 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: E 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. Ai cuvinte de despărțire?

Guillermo: No, thank you for having me.