Smashing Podcast Episodio 23 con Guillermo Rauch: cos'è Next.js?

Oggi parliamo di Next.js. Che cos'è e dove potrebbe inserirsi nel nostro flusso di lavoro di sviluppo web? Ho parlato con il co-creatore Guillermo Rauch per scoprirlo.

Mostra note

• Guillermo Rauch su Twitter
• Next.js

Aggiornamento settimanale

• "Padroneggiare oggetti di scena e PropType in reazione"
  di David Adeneye
• "Decisioni di design ispirate con Bradbury Thompson: l'arte del design grafico"
  di Andy Clarke
• "Configurazione di un'API utilizzando Flask, Cloud SQL di Google e App Engine"
  di Wole Oyekanmi
• "Forme e convalida nella reazione ionica"
  di Jerry Navi
• "Come aiutare i tuoi clienti a ottenere più backlink attraverso il design"
  di Susanna Scacca

Trascrizione

Drew McLellan: È il fondatore e CEO di Vercel, una piattaforma cloud per siti statici che si adatta a un flusso di lavoro Jamstack. È anche il co-creatore di Next.js. In precedenza ha fondato LearnBoost e CloudUp ed è noto come creatore di numerose librerie open source di nodi popolari come Socket.io, Mongoose e SlackIn. In precedenza, era uno sviluppatore principale di MooTools, quindi sappiamo che sa come aggirare JavaScript come il palmo della sua mano. Sapevi che una volta ha ricevuto una commissione reale dal re di Spagna per creare una scultura di ghiaccio con lattuga iceberg? Miei formidabili amici, vi prego di dare il benvenuto a Guillermo Rauch. Ciao Guillermo, come stai?

Guillermo Rauch: Sto rompendo maledettamente bene, grazie per avermi ospitato.

Drew: Volevo parlarti oggi dell'intero mondo di Next.js, perché è qualcosa di cui ovviamente sei personalmente molto ben informato, essendo stato coinvolto come co-creatore fin dall'inizio. Next.js è uno di quei nomi di progetti che è stato sul mio radar mentre lavoravo nello spazio Jamstack, ma non è qualcosa che in realtà ho esaminato personalmente o con cui ho lavorato troppo da vicino prima. Per le persone come me, che forse non sono a conoscenza di cosa sia Next.js, forse potresti darci un po' di background su cosa sia e quali problemi cerca di risolvere.

Guillermo: Next.js è un membro molto interessante dell'universo Jamstack, perché Next.js ha iniziato a essere un framework completamente incentrato sull'SSR. Ha iniziato a ricevere molta adozione al di fuori dello spazio Jamstack, dove le persone stavano costruendo cose molto grandi in particolare quando volevano avere contenuti generati dagli utenti o contenuti dinamici o social network o e-commerce, e sapevano che volevano SSR perché il loro set di dati era molto grande o molto dinamico. Penso che sia caduto sotto il radar per molte persone nel mondo Jamstack, ma in seguito Next.js ha acquisito le capacità per l'ottimizzazione statica.

Guillermo: Da un lato, ad esempio, se non eseguissi il recupero dei dati al livello più alto della tua pagina con Next.js, la tua pagina React sarebbe... Inoltre, per coloro che non sono completamente al corrente, Next.js è semplicemente il framework React per la produzione, ma ha questa capacità di eseguire alcuni rendering. Quindi, quando accedi alle funzionalità di ottimizzazione statica, se non vuoi definire il recupero dei dati al livello superiore della tua pagina, viene automaticamente esportato come HTML invece di provare a fare qualsiasi cosa con il rendering del server.

Guillermo: Successivamente, ha anche acquisito la capacità per la generazione di siti statici, il che significa che è possibile definire uno speciale hook di dati, ma tale hook di dati ottiene i dati in fase di compilazione. Next.js è diventato un framework dinamico e statico ibrido, molto potente, e ora è cresciuto molto anche nello spazio Jamstack.

Drew: La gente potrebbe dire che React è già un framework, sicuramente lo senti descritto in questo modo. Cosa significa effettivamente essere un framework per React?

Guillermo: Questa è un'ottima osservazione, perché faccio sempre notare alle persone che React su Facebook e React al di fuori di Facebook sono bestie completamente diverse. React at Facebook in realtà viene utilizzato insieme al rendering del server, ma anche il rendering del server, ad esempio, non utilizza Node.js, utilizza una macchina virtuale altamente specializzata chiamata Hermes che comunica con il loro tipo di hack di produzione e stack PHP e risponde tutte queste esigenze avanzate ed esotiche di Facebook.

Guillermo: Quando open source React, è quasi come fare open source per un componente. Lo chiamo sempre come aprire l'approvvigionamento del motore, ma non darti l'auto. Quello che è successo è che le persone volevano davvero andare a guidare con esso, volevano andare in posti con React. Nella comunità, le persone hanno iniziato a creare auto e avrebbero incorporato React come motore, che era ciò che il pilota e lo sviluppatore cercavano in primo luogo, rendendo React la parte fondamentale dell'auto. Cose come Next.js e Gatsby e React Static e molti altri framework hanno iniziato ad apparire che stavano risolvendo la necessità di tipo "Voglio davvero creare pagine e applicazioni completamente caricate".

Guillermo: Mentre React era più simile al componente e al motore per widget specifici all'interno della pagina, questo era certamente il caso di Facebook. Ammetteranno ampiamente e pubblicamente di averlo inventato per cose come il batch di notifica, il widget di chat, il componente del feed di notizie e quei componenti erano percorsi React incorporati nei contenuti dell'app esistente di produzione con molte, molte righe di codice e persino altre librerie e framework JS.

Guillermo: Cosa significa creare un framework per React, significa rendere React la parte fondamentale della storia, si spera e questo è qualcosa che proveremo a fare con Next.js, la curva di apprendimento riguarda principalmente React con alcune aggiunte surface per Next.js, in particolare per quanto riguarda il recupero e l'instradamento dei dati. Facciamo anche molte ottimizzazioni della produzione, quindi quando ottieni React, quando ottieni l'app Create React, che è un po' come, mi piace chiamarla un'auto con bootstrap che ti dà Facebook, forse le esigenze di produzione non sono davvero soddisfatte . Oppure, se provi a farlo da solo configurando Webpack e configurando Babel e configurando il rendering del server e la generazione statica, è anche difficile mettere insieme un'auto da zero. Next.js ti fornirà questa configurazione zero e anche un set di impostazioni predefinite ottimizzate per la produzione per la costruzione di intere grandi cose con React.

Drew: Quindi è come se mettesse quasi una sorta di ecosistema attorno alla tua app React con una raccolta di strumenti preconfigurati per consentirti di-

Guillermo: Esatto.

Drew: mettiti al lavoro ed esegui la generazione di siti statici o il rendering o il routing del server.

Guillermo: Esatto, e hai usato una parola che è molto, molto chiave per tutto questo, che è preconfigurata. Siamo abbastanza fortunati da attirare l'attenzione di Google Chrome come collaboratore di Next.js. Una delle leader di questo progetto, la sua cosa è che quando stavano lavorando su framework internamente a Google, hanno dovuto affrontare molti degli stessi problemi che la community e l'open source devono affrontare oggi. C'erano molte diverse iniziative concorrenti in Google su come ridimensionare e creare app Web davvero performanti fuori dagli schemi.

Guillermo: Ti uniresti come Googler e ti verrebbe fornito un framework con il quale creeresti applicazioni pronte per la produzione davvero grandi e ad altissime prestazioni. Shubie faceva parte di molte di queste iniziative, e quello che ha scoperto è che ci sono due ingredienti chiave per fare in modo che un framework abbia successo su larga scala. Uno è la pre-configurazione, il che significa che vieni al lavoro, avvierai un'app nuova di zecca, dovresti ricevere qualcosa che è già pronto per l'uso e soddisfa molte delle esigenze di produzione che sono note a quel punto in tempo.

Guillermo: D'altra parte, l'altro passo davvero importante verso il quale stiamo lavorando è la conformità. Puoi ricevere il framework preconfigurato per la produzione più altamente ottimizzato, ma se vai avanti e, ad esempio, inizi a introdurre molte dipendenze pesanti o script di terze parti o usi layout molto inefficienti che richiedono molto tempo per la pittura e così via e così via, allora farai in modo che quella pre-configurazione vada sprecata. Combinando la preconfigurazione con la conformità nel tempo, lo sviluppatore non solo ha un ottimo punto di partenza, ma è anche guidato al successo nel tempo.

Drew: Sembra che una caratteristica di Next.js, che sia piuttosto supponente, il livello dell'interfaccia utente sia React, usa uno script di tipo, usa Webpack e quelle sono tutte scelte che il progetto ha fatto ed è quello che ottieni. Correggimi se sbaglio, ma non è possibile sostituire React con Vue, ad esempio, all'interno di Next.js.

Guillermo: Questo è un buon punto, dove il processo decisionale tecnico incontra una sorta di arte. Da un lato, mi piacerebbe davvero affermare che Next è molto libero da opinioni, e il motivo è che se vai specificamente su github.com/vercel/nextjs e nella directory degli esempi, vedrai che c'è quasi come un esplosione combinatoria di tecnologie che puoi utilizzare insieme a Next.js. Vedrai basato sul fuoco, vedrai Graphic UL, vedrai Apollo, vedrai Redux, vedrai MobX, nello spazio CSS ci sono ancora più opzioni.

Guillermo: Abbiamo una porta CSS predefinita incorporata, ma puoi usarne due versioni, una con import, una con tag di stile che chiamiamo Style JSX, che assomiglia molto all'approccio della piattaforma web a Shadow CSS. Il motivo per cui intendo discreti è che vogliamo che Next.js rimanga molto vicino al "bare metal" del web e non introduca molte primitive con cui se il web tra 10 anni da oggi sarebbe incompatibile. Quindi, se guardi gli esempi, vedrai che ci sono tutte queste altre tecnologie che puoi collegare.

Guillermo: Il livello base di opinione è che c'è React e non sarai in grado di sostituirlo, almeno a breve. Poi c'è il concetto che dovresti essere in grado di creare pagine, e questa era una cosa nuova quando l'abbiamo lanciato per la prima volta, ovvero tutti stavano cercando di creare applicazioni a pagina singola. Quello che ci siamo resi conto è che Internet è fatto di siti Web con molte pagine che creano punti di ingresso distinti tramite motori di ricerca, Twitter, Facebook, social network, compagni di posta elettronica, come se guidi sempre la persona verso un punto di ingresso, e quella persona che arriva attraverso quel punto di ingresso non dovrebbe dover scaricare l'onere dell'intera applicazione.

Guillermo: Poi quel percorso ci ha portato all'implementazione del rendering del server, quindi alla generazione statica per più pagine, eccetera, ecc. Quell'altro livello di opinione di base è Next dovrebbe essere un framework che funziona per il web, non contro il web. Inoltre, a React mancava il recupero dei dati e le primitive di routing, e le abbiamo aggiunte. C'è un livello di opinione che deve affrontare come se tutti avessero bisogno di un router, quindi potrebbe anche avere un router integrato per impostazione predefinita.

Drew: Il grande vantaggio di avere quelle impostazioni predefinite è che toglie molta complessità di scelta, che è solo lì, è configurato e puoi semplicemente iniziare a usarlo senza dover pensare troppo, perché penso che abbiamo tutti -

Guillermo: Esattamente.

Drew: Mi sono trovato in situazioni in cui ci sono troppe scelte su quali componenti utilizzare, e può essere opprimente e ostacolare la produttività.

Guillermo: Esattamente.

Drew: Per quale tipo di progetti vedi le persone che usano Next.js? È praticamente per qualsiasi situazione in cui potresti creare un'app React di produzione o è più adatta a particolari tipi di siti con contenuti pesanti? Importa in questo senso?

Guillermo: Sì, quindi questo è stato un dibattito secolare sul Web, il Web è per le app, il Web per i siti, è un ibrido? Qual è il ruolo di JavaScript, eccetera, eccetera? È un po' difficile dare una risposta diretta, ma la mia opinione è che il web si è sempre evoluto per essere un ibrido di contenuti che si sta evolvendo per essere sempre più dinamico e personale per l'utente. Anche quando dici come un sito Web di contenuti, i siti Web di contenuti di fascia alta del mondo hanno basi di codice molto simili alle app.

Guillermo: Un ottimo esempio qui è come il New York Times, ti daranno widget incorporati con strumenti di analisi dei dati e animazioni interattive, ti consiglieranno quale storia leggere dopo e hanno un modello di abbonamento integrato che a volte ti dà parte del contenuto e talvolta conta quanti articoli hai letto. Come se te lo dicessi quando è stato inventato il web, come Tim Berners-Lee sarebbe tipo "No, è pazzesco, non è possibile sul web", ma questo è il web che abbiamo oggi.

Guillermo: Next.js sta rispondendo a molte di queste complesse esigenze moderne, il che significa che vedrai molto utilizzo dell'e-commerce, vedrai molti contenuti con quello. E-commerce significa, tra l'altro, non solo come acquistare oggetti, ma esperienze come i più grandi siti Web immobiliari sul web, realtor.com, zillow.com, trulio.com, l'intera categoria è tutta Next.js, quindi contenuto siti. Abbiamo appena inserito washingtonpost.com come cliente di Vercel e Next.js, quindi abbiamo una terza categoria più emergente ma molto interessante, che è app complete e contenuti generati dagli utenti, come tiktok.com, e un po' come te penserebbe che il caso d'uso dell'applicazione a pagina singola originale sia abbastanza rappresentato lì.

Guillermo: Next.js brilla quando devi avere molti contenuti che devono essere serviti molto, molto rapidamente, devono essere ottimizzati SEO e, alla fine, è un mix di dinamico e statico.

Drew: In precedenza ho parlato con Marcy Sutton di Gatsby, che sembra trovarsi in uno spazio simile. È sempre bello vedere più di una soluzione a un problema e avere la possibilità di scegliere da un progetto all'altro. Diresti che Next.js e Gatsby operano nello stesso tipo di spazio problematico e quanto sono simili o dissimili?

Guillermo: Penso che ci sia una sovrapposizione per alcuni casi d'uso. Ad esempio, il mio blog personale rauchg.com funziona su Next.js, avrebbe potuto essere anche un ottimo blog Gatsby. C'è quella sovrapposizione nel tipo di spazio del sito Web statico più piccolo, e per piccolo non intendo non rilevante. Un sacco di dotcom che sono super, super importanti girano su un Web fondamentalmente statico, quindi questo è il bello di Jamstack secondo me. Poiché Next.js può ottimizzare staticamente le tue pagine e quindi puoi ottenere ottimi punteggi Lighthouse attraverso questo, puoi usarlo per casi d'uso sovrapposti.

Guillermo: Penso che il limite venga tracciato quando inizi ad entrare in bisogni più dinamici e hai molte pagine, hai la necessità di aggiornarle contemporaneamente. Sebbene Gatsby stia creando soluzioni per quelli, Next.js ha già soluzioni live pronte per la produzione che funzionano con qualsiasi tipo di database, qualsiasi tipo di back-end di dati per sostanzialmente "generare" o "stampare" un sacco di pagine. È qui che oggi i clienti vanno a Next.js invece che a Gatsby.

Drew: Uno dei problemi che tutti sembrano incontrare quando la loro soluzione basata su JavaScript diventa più grande sono le prestazioni e il modo in cui le cose possono iniziare a diventare piuttosto lente, hai grandi dimensioni del pacchetto. Tradizionalmente, cose come la suddivisione del codice possono essere piuttosto complesse da configurare correttamente. Vedo che è una delle caratteristiche che mi sono venute in mente di Next.js, che afferma che la divisione del codice è automatica. Cosa fa Next.js in termini di suddivisione del codice per farlo funzionare?

Guillermo: La tua osservazione è giusta al 100%. Una delle cose più importanti con il Web e uno dei maggiori pesi sul Web è JavaScript, e proprio come materiali diversi hanno densità e pesi diversi indipendentemente dal volume fisico effettivo, JavaScript tende ad essere un elemento molto denso e pesante. Anche piccole quantità di JavaScript rispetto, ad esempio, alle immagini che possono essere elaborate in modo asincrono e fuori dal thread principale, JavaScript tende a essere particolarmente fastidioso.

Guillermo: Next.js ha investito un'enorme quantità di sforzi nell'ottimizzazione automatica dei tuoi bundle. La prima che è stata la mia prima intuizione quando mi è venuta l'idea per Next.js è stata la definizione, ad esempio, di 10 percorsi. Nel mondo Next.js crei una directory di pagine e invii i tuoi file Index.js, About.js, Settings.js, Dashboard.js, Termsofservice.js, Signup.js, Login.js. Questi diventano punti di accesso alla tua applicazione che puoi condividere attraverso tutti i tipi di media.

Guillermo: Quando inserisci quelli, vogliamo darti JS che è rilevante per quella pagina prima di tutto, e poi forse un pacchetto comune in modo che le successive navigazioni all'interno del sistema siano molto veloci. Next.js inoltre, che è molto, molto carino, pre-carica automaticamente il resto delle pagine collegate a quel punto di ingresso, in modo tale da sembrare un'applicazione a pagina singola. Molte persone dicono: "Perché non usare l'app Create React se so che ho forse un paio di percorsi?" Dico sempre loro: "Guarda, puoi trovarle come pagine e poiché Next.js preleverà automaticamente quelle collegate, finirai per ottenere la tua applicazione a pagina singola, ma è meglio ottimizzata per quanto riguarda quella vernice iniziale , quel punto di ingresso iniziale.

Guillermo: Quello era l'approccio iniziale alla divisione del codice, ma poi è diventato molto più sofisticato nel tempo. Google ha contribuito con un'ottimizzazione molto interessante chiamata Module and No Module, che darà JS differenziale ai browser moderni e JS legacy che è ricco di polyfield per altri browser, e questa ottimizzazione è automatizzata al 100% e produce enormi risparmi. L'abbiamo regalato a un nostro cliente che ospitiamo su Vercel chiamato Parnaby's, credo se non sbaglio è stato qualcosa di molto, molto significativo. Forse è stato un risparmio del 30% sulle dimensioni del codice, ed è stato solo perché hanno aggiornato Next.js a una versione che ottimizzava meglio i bundle JS.

Guillermo: Questo era un po' il punto su cui stavamo esaminando prima, ovvero tu scegli Next.js e nel tempo diventa solo migliore e più ottimale, continuerà a ottimizzare le cose per tuo conto. Quelle sono, ancora una volta, pre-configurazioni con cui non dovresti mai avere a che fare o con cui non dovresti essere disturbato, e la ricerca di cui non vorresti nemmeno fare, ad essere onesti. Come se non fossi ovviamente molto coinvolto in questo, ma guardo alcune delle discussioni interne e stavano discutendo di tutti questi policampi che contavano solo per Internet Explorer X e Soho, ero tipo "Non voglio nemmeno sapere , aggiorniamo semplicemente Next.js e otteniamo tutti questi vantaggi."

Drew: A volte ci sono grandi vantaggi nel mantenere le impostazioni predefinite e attenersi alla configurazione più comune delle cose, che sembra essere davvero l'approccio Next.js. Ricordo quando ho iniziato a scrivere PHP nei primi anni 2000, e tutti usavano PHP e MySQL, e all'epoca provenivo da Windows, quindi volevo usare PHP e Microsoft Sequel Server. Puoi farlo, ma stai nuotando controcorrente per tutto il tempo. Quindi, non appena sono passato a MySQL, l'intero ecosistema ha iniziato a funzionare per me e non avevo bisogno di pensarci.

Guillermo: Sì, tutto scatta, è un'ottima osservazione. Vediamo che tutto il tempo, come se l'ecosistema di Babele sia così potente ora che potresti diventare, ad esempio, un po' più veloce scambiando Babel con qualcos'altro, ma poi scambi quell'incredibile compatibilità dell'ecosistema. Questo è qualcosa che hai toccato in precedenza sulle prestazioni e, come per molte persone, le prestazioni di build e le prestazioni di generazione statica rappresentano un grosso collo di bottiglia, e questo è qualcosa su cui siamo molto diligenti nel migliorare le prestazioni dei nostri strumenti in modo incrementale.

Guillermo: Ad esempio, una delle cose che Next.js sta facendo ora è che sta aggiornando il suo valore predefinito da Webpack 4 a Webpack 5, che ha alcune cose di rottura, ed è per questo che lo stiamo prima offrendo alle persone come opzione in flag, ma in seguito diventerà l'impostazione predefinita. Webpack 5 apporta incredibili miglioramenti delle prestazioni, ma non stiamo sacrificando l'ecosistema Webpack, abbiamo migliorato in modo incrementale. Certo, c'erano alcune cose molto piccole che dovevano essere sacrificate, ma questo è un incredibile vantaggio dell'ecosistema JS oggi su cui molte persone stanno sorvolando, penso, perché forse vedono: "Oh, avremmo potuto fare X a Soho, forse era un po' più veloce, o forse MPM a Soho avrebbe impiegato meno tempo". Raccolgono alcuni dettagli e perdono il quadro più ampio, ovvero il valore dell'ecosistema è enorme.

Drew: Il valore di avere tutta la configurazione, la manutenzione e quel lato fatto da un progetto come Next.js piuttosto che prendersela con te passando a usare qualcos'altro è incredibile, perché non appena ti allontani da quelle impostazioni predefinite , ti stai assumendo l'onere di mantenere attive tutte le compatibilità e farlo da solo. Una delle cose che mi ha davvero interessato con Next.js è che ci sono opzioni disponibili per la generazione di siti statici o il rendering lato server, o forse un ibrido dei due. Penso che ci siano state alcune modifiche recenti a questo in un recente aggiornamento, puoi dirci qualcosa in merito e quando potresti scegliere l'una o l'altra?

Guillermo: Sì, certo. Uno dei componenti chiave di questo approccio ibrido combinato con il sistema di pagine che ho descritto in precedenza è che puoi avere pagine completamente statiche o pagine visualizzate dal server. Una pagina completamente statica ha l'incredibile vantaggio di ciò che chiamo sollevamento statico, ovvero puoi prendere quella risorsa e metterla automaticamente al limite. Mettendolo al limite, intendo dire che puoi memorizzarlo nella cache, puoi metterlo nella cache preventivamente, puoi replicarlo, puoi fare in modo che quando arriva una richiesta, non tocchi mai il server perché sappiamo in anticipo, " Ehi, Slash Index è statico.

Guillermo: Questo è un vantaggio molto, molto interessante quando si tratta di servire un pubblico globale. Fondamentalmente ottieni una CDN automatica pronta all'uso, soprattutto quando distribuisci le moderne reti perimetrali come Vercel o AWS Amplify o Netlify e così via. Next.js ha questa premessa per cui se può essere reso statico, dovrebbe essere statico. Quando inizi un progetto per la prima volta e stai lavorando sulla tua prima pagina o stai dando dei calci alle gomme del framework, potresti anche rendere tutto statico.

Guillermo: Anche per esigenze di fascia alta, ad esempio vercel.com, il nostro uso di Next.js è completamente statico. È una combinazione di generazione di siti completamente statici e statici, quindi tutte le nostre pagine di marketing sono statiche, il nostro blog è generato staticamente da un'origine dati dinamica e quindi la nostra dashboard che contiene molti dati dinamici, ma possiamo fornirli come shell o scheletri , tutte le pagine associate alla visualizzazione delle tue implementazioni, alla visualizzazione dei tuoi progetti, alla visualizzazione dei tuoi log, eccetera, eccetera, sono fondamentalmente tutte pagine statiche con JavaScript lato client.

Guillermo: Questo ci serve incredibilmente bene perché tutto ciò di cui abbiamo bisogno di prestazioni molto veloci nel primo riquadro è già pre-renderizzato, tutto ciò che ha bisogno di SEO, già pre-renderizzato e tutto ciò che è estremamente dinamico, dobbiamo solo preoccuparci della sicurezza, perché ad esempio, dal punto di vista del lato client che utilizza le stesse chiamate API utilizzate, ad esempio, dalla nostra CLI o dalle nostre integrazioni, ecc. Un sito web completamente statico, molto economico da gestire, incredibilmente scalabile e chi più ne ha più ne metta.

Guillermo: Ora, una cosa in particolare di cui avevamo bisogno con il nostro blog era che volevamo aggiornare i dati molto rapidamente. Volevamo correggere un errore di battitura molto rapidamente e non aspettare che si verificasse un'intera build, e questo è un vantaggio molto significativo di Next.js, che mentre si passa da una statica a una dinamica, ti offre anche queste soluzioni intermedie . Per il nostro blog abbiamo utilizzato la generazione statica incrementale, quindi essenzialmente possiamo ricostruire una pagina alla volta quando il contenuto sottostante cambia.

Guillermo: Immagina che non avessimo solo un paio di centinaia di post sul blog e che molti post del blog venissero generati continuamente e aggiornati continuamente, come ho menzionato uno dei nostri clienti, Washington Post, in quel caso devi andare più verso SSR completo, soprattutto quando inizi a personalizzare il contenuto per ciascun utente. Quel viaggio di complessità che ho appena descritto è iniziato da ho una pagina di marketing, ho un blog che ha un paio di migliaia di pagine, ho decine di migliaia o milioni di pagine. Questo è il viaggio di Next.js che puoi attraversare con la tua attività.

Guillermo: Quindi inizi come sviluppatore a scegliere tra forse meno responsabilità e maggiori responsabilità, perché quando accetti di utilizzare SSR, ora stai eseguendo codice sul server, stai eseguendo codice sul cloud, c'è più responsabilità con più potenza. Il fatto che tu possa decidere dove utilizzare ogni tipo di strumento è un vantaggio molto, molto interessante di Next.

Drew: Solo in termini pratici di combinazione della generazione statica del sito e del rendering lato server, come funziona in termini di elemento server? Hai bisogno di una piattaforma dedicata come Vercel per poter raggiungere questo obiettivo, o è qualcosa che può essere fatto in modo più diretto e semplice?

Guillermo: Next.js ti offre un server di sviluppo, quindi scarichi Next ed esegui il tuo Next Dev, e quello è il server di sviluppo. Il server di sviluppo è ovviamente incredibilmente ottimizzato per lo sviluppo, poiché dispone dell'ultima tecnologia di aggiornamento rapido rilasciata da Facebook, dove ... In realtà, Facebook non l'ha rilasciata, Facebook lo utilizza internamente per ottenere la sostituzione del modulo caldo migliore, più performante e più affidabile , in modo tale che stai praticamente digitando e le modifiche si riflettono sullo schermo, quindi questo è il server di sviluppo.

Guillermo: Then Next ti offre un server di produzione chiamato Next Start e Next Start ha tutte le capacità del framework per il self-hosting. La cosa interessante di Vercel è che quando si distribuisce accanto ad esso, viene automaticamente ottimizzato ed è serverless al 100%, il che significa che non c'è alcuna responsabilità di amministrazione, ridimensionamento, incassi e convalida degli incassi, eliminazione, replica, failover globale e così via e così via che dovresti affrontare quando esegui tu stesso Next Start.

Guillermo: Questo è anche il grande vantaggio di Next.js, quindi, ad esempio, apple.com ha diverse proprietà, sottodomini e pagine su dotcom su Next.js che si auto-ospitano, a causa di esigenze di sicurezza e privacy molto, molto avanzate e rigorose . D'altra parte, washingtonpost.com utilizza Vercel, quindi abbiamo questo tipo di vasta gamma di utenti e siamo estremamente felici di supportarli tutti. La cosa bella di dove va il serverless secondo me è che può darti il ​​meglio di entrambi i mondi in termini di prestazioni ottimali che migliorano solo nel tempo, con la migliore esperienza di sviluppo del tipo "Ehi, non ho preoccuparsi di qualsiasi tipo di infrastruttura”.

Drew: The Next.js è un progetto open source sviluppato dal team di Vercel. Ci sono altri contributori al di fuori di Vercel?

Guillermo: Sì, quindi Google Chrome è il principale che invia attivamente PR del server, ci aiuta con le ottimizzazioni e testandolo con i partner, come gli utenti Next.js molto grandi che fanno già parte dell'ecosistema di Google, ad esempio, a causa dell'utilizzo di molti e molte app, quindi devono essere coinvolti da vicino come partner. Facebook, manteniamo un ottimo rapporto con il team di Facebook. Ad esempio, l'aggiornamento rapido, siamo stati il ​​primo framework React a ottenerlo e ci hanno aiutato a guidarci attraverso tutte le cose che hanno imparato usando React e l'aggiornamento rapido su Facebook.

Guillermo: Lavoriamo con molti partner che hanno implementazioni molto grandi di app Next.js in natura da tutti i tipi di casi d'uso diversi, come immaginare l'e-commerce e i contenuti. Poi ci sono moltissimi contributori indipendenti, persone che usano Next.js personalmente, ma anche educatori e membri dei team di front infrastructure nelle grandi aziende. È uno sforzo comunitario molto, molto ampio.

Drew: Sembra la preoccupazione che qualcuno potrebbe avere, che questo sia stato sviluppato in una parte significativa da Vercel, che potrebbero avere la preoccupazione di essere in qualche modo bloccati nell'implementazione su quella particolare piattaforma, ma sembra proprio come non è affatto così, e potrebbero sviluppare un sito e distribuirlo su Firebase o Netlify o...

Guillermo: Sì, assolutamente. Mi piace confrontarlo molto per come i Kubernetes dell'era del Front End in un certo senso, perché alla fine della giornata sono fermamente convinto che ... Kubernetes è qualcosa di cui praticamente quasi tutti hanno bisogno quando hanno bisogno di eseguire processi Linux , come se parlassi di opinioni e dici che è una buona tecnologia, non è assolutamente supponente, ma c'è qualche opinione di cui ci dimentichiamo. È come se alla fine della giornata fosse nato dall'esecuzione di un demone specifico di programmi Linux impacchettati come contenitori.

Guillermo: Next è in una posizione simile, perché ciò che consideriamo la primitiva universale del mondo come componente React, ovviamente è supponente, ma pensiamo che per molte aziende, proprio come gravitano tutte verso Linux, siamo vedere la stessa cosa nei confronti di React e Vue, ma fortunatamente Vue ha anche Nuxt, che è una soluzione davvero fantastica, è equivalente per ideazione e principi di Next. Stiamo gravitando verso queste piattaforme come Next.js, come Nuxt, come Sapper per l'ecosistema Svelte.

Guillermo: Penso che queste dovrebbero essere piattaforme aperte, perché ancora una volta, se tutti ne avranno bisogno, potrebbe anche non reinventare la ruota dell'intero settore, giusto? Accogliamo con favore questa posizione, accogliamo con favore le persone che la dispiegano e la riconfigurano, la ricostruiscono e la ridistribuiscono e così via.

Drew: Proprio di recente è stata rilasciata una nuova versione di Next.js, penso che la versione 9.5. Quali cambiamenti significativi ci sono stati in quella versione?

Guillermo: La cosa più impressionante è, come dicevo prima, molte cose iniziano statiche e poi diventano più dinamiche man mano che le cose crescono. Questa è stata l'impresa per WordPress, tra l'altro. All'inizio WordPress era basato su un approccio basato su un database di file statico, e poi ha avuto bisogno di un database, un po' come quello che hai descritto con il modo in cui PHP si è evoluto per diventare sempre più MySQL. La cosa bella di Next.js 9.5 è che rende la generazione statica incrementale una funzionalità pronta per la produzione, quindi l'abbiamo tolta dal flag unstable.

Guillermo: Questa funzione ti consente di compiere quel viaggio da statico a dinamico senza rinunciare a tutti i vantaggi statici e senza dover fare il pieno per il rendering dinamico del server, quindi allunga la vita utile del tuo tipo di statico. Il modo in cui lo usiamo in Vercel, ad esempio, come ho detto, è come se il nostro blog venisse completamente pre-renderizzato in fase di compilazione, ma poi, ad esempio, tra un paio di minuti stiamo per fare un annuncio importante e quando blog su di esso vogliamo essere in grado di modificarlo, risolverlo, visualizzarlo in anteprima, eccetera senza dover emettere una build da cinque a 10 minuti ogni volta che cambiamo una lettera di un post del blog.

Guillermo: Con la generazione statica incrementale, puoi ricostruire una pagina alla volta. Ciò che potrebbe richiedere minuti o addirittura secondi, a seconda di quanto è grande il tuo sito, ora richiede millisecondi. Ancora una volta, non dovevi rinunciare a nessuno dei vantaggi della statica. Questa è forse la cosa di cui sono più entusiasta che è diventata stabile su Next.js 9.5, e in particolare perché la comunità JS e la comunità React e la comunità del framework e la comunità generata dal sito statico hanno parlato di questo unicorno di creare un incremento statico per 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: È affascinante. 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. Hai qualche parola d'addio?

Guillermo: No, thank you for having me.