Gatsby JS contro Next.js - Quale generatore di siti statici scegliere?

I siti statici, per quanto portino molti vantaggi, hanno anche difetti.Uno svantaggio notevole dei siti statici è che generalmente non aiutano gli editor a comprendere come sarà il risultato finale durante la produzione di contenuto.Una delle funzionalità più importanti introdotta da Gatsby è proprio il sistema di preview, pensato per permettere di aggiornare il CMS e vedere istantaneamente i risultati su un sito di staging visibile solo agli editor.Anche Next.js offre un sistema di preview, ma invece di usare un sito duplicato, permette di vedere le modifiche in tempo reale sul sito di produzione, senza che le modifiche ancora non pubblicate possano essere spiate dagli utenti reali. Guardiamo insieme i pro e i contro dei due sistemi.

Lavorare con Javascript è sempre una corsa contro il tempo: non possiamo mai sapere se alcune delle librerie scelte saranno mantenute per lungo tempo oppure se qualcosa di più nuovo e performante apparirà all’orizzonte dopo un paio di settimane.Qui a Cantiere Creativo abbiamo avuto questo esatto problema durante la scelta del generatore di siti statici (Static Site Generator, oppure “SSG”) da affiancare a DatoCMS. Inizialmente, ci siamo indirizzati verso Gatsby, specialmente quando avevamo bisogno di un sostanzioso front-end. L’arrivo di Next.js ha un po’ sparigliato le carte.La nostra esperienza però non è sufficiente per comparare i due SSG senza tenere in considerazione i diversi casi d’uso.Prima di tutto, valuteremo i due generatori di siti statici dal punto di vista di uno sviluppatore, analizzando come si programmano e quali vantaggi abbiamo sviluppando su uno o sull’altro.In seconda battuta, terremo conto dei pro e dei contro delle due soluzioni dal punto di vista di un editor, quindi tenendo in considerazione aspetti come la possibilità di preview oppure il modo in cui gestisce i dati. Infine, ci concentreremo sull’esperienza dell’utente finale. Partiamo da Gatsby.js.Gatsby può essere divertente, facile e veloce da usare quando volete montare qualcosa in poco tempo, ma:

1. È complicato da sviluppare;
2. È solo statico!

Di seguito trovate il metodo con cui usiamo Gatsby.Recuperiamo i dati attraverso GraphQL che ci servono per generare le pagine. Questo succede nel file gatsby-node.js file, dove iteriamo sugli array locale e, per ogni locale, generiamo pagine in ogni lingua. Attenzione, perché ciò che chiamiamo “pagina” può confondervi. In Gatsby ci sono due cartelle: pages e templates. Le Pagine sono il risultato finale di quello che programmate, quindi se abbiamo una pagina chiamata about.js, essa mostrerà esattamente cosa abbiamo scritto al suo interno nel percorso `/about`. I template sono i file che specifichiamo quando creaiamo le pagine, così se recuperiamo dati dal nostro CMS e vogliamo creare, per esempio, la pagina /team/elon-musk, avremo un template chiamato team-member.js che passeremo nella funzione create durante la fase di build. La nuova pagina creata avrà lo stile del template. 

All'interno del template recupereremo tutto il contenuto della pagina, dal titolo, alle gallerie fino ai tag SEO.Dalla pagina chiamiamo invece il CMS e recuperiamo i dati che ci servono usando GraphQL tramite props.

Dopo alcuni mesi di lavoro con Gatsby, però, ci siamo ritrovati a combattere errori incomprensibili: la cache non veniva pulita correttamente e, soprattutto, dopo aver passato molti record attraverso GraphQL il tempo di build è passato da pochi secondi a svariati minuti!Quest'ultima parte non è direttamente colpa di GatsbyJS; il problema qui è GraphQL, che sfortunatamente è l'unico strumento che abbiamo per recuperare i dati che Gatsby ci permette di usare.Ora che abbiamo visto come funziona Gatsby, possiamo ricapitolare i pro e i contro in base alle tre figure interessate.Da un punto di vista degli sviluppatoriPro:

• Facile da configurare;
• Performante;
• La scelta migliore per siti web piccoli e semplici.

Contro:

• Si tratta di un SSG puro, quindi non consente pagine dinamiche (nativamente);
• Invalidare la cache è un problema.

Come editorePro:

• Facile cambiare i dati perché si lavora direttamente sul CMS;
• Puoi utilizzare qualsiasi CMS che supporta GraphQL, noi usiamo e consigliamo DatoCMS che è veloce, facile da usare e sempre aggiornato con tecnologie all'avanguardia.

Contro:

• Non esiste una vera e propria modalità di anteprima, bensì una sorta di hack basato sulla modalità dev di React che ha anche un costo mensile;
• Avere molti dati rallenta molto il tempo di build. Avevamo un sito web con circa 1000 record (pagine e singole istanze) e ci sono voluti 8 minuti per concluderla.

Come utentePro:Siti web molto veloci.Contro:Parlando di siti web statici, è difficile segnalare contro che siano correlati a Gatsby.

La nostra nuova soluzione di riferimento si chiama Next.js che, prima di tutto, ci consente di decidere come recuperare i dati. Per questo motivo si ha solo una funzione getInitialProps () che permette di usare un 'fetch ()' per recuperate dati da un'API nel modo che si preferisce.

Recuperare dati da questa funzione vi consente di inviare contenuti alle pagine tramite props, proprio come Gatsby.getInitialProps può essere aggiunto solo al componente predefinito esportato da una pagina, aggiungerlo a qualsiasi altro componente non funzionerà.Il valore di questa soluzione è nella possibilità di non dover usare GraphQL ogni volta, perché Next.js lascia allo sviluppatore la scelta su come gestire i dati. In questo modo, se GraphQL si rivela un collo di bottiglia per il vostro progetto, potete passare ad altro.Un'altra grande caratteristica offerta da Next.js è che potete avere pagine sia statiche sia dinamiche. Invece di avere tutte le pagine statiche come Gatsby, si può decidere di avere pagine SSR che verranno gestite come qualsiasi altro linguaggio lato server.

Come sviluppatoriPro:

• Molto versatile perché permette di scegliere come recuperare i dati;
• Permette di far convivere pagine statiche e dinamiche;
• getStaticProps e getServerSideProps aiutano molto a gestire e recuperare i dati.

Contro:

• Più complesso di GatsbyJS, richiede più tempo di sviluppo e un livello di abilità superiore;
• Conoscenza di programmazione server-side richiesta (per pagine SSR);
• Obbligo di usare Vercel per gestire il deploy e la configurazione della build.

Come editorPros:

• Recupera i dati nel modo che si vuole, potendo utilizzare qualsiasi CMS (o altri sistemi personalizzati) purché sfrutti un'API;
• Editing dei contenuti in tempo reale basato sui cookie, non è necessario impostare un altro ambiente, ma basta inserire i dati nel CMS per vedere immediatamente come appare sul sito web prima di pubblicarlo.

Contro:

• Niente di particolare.

Come utentePro:

• Il sito web può essere mezzo statico e mezzo dinamico, così può rispondere a ogni bisogno.

Contro:

• La parte dinamica del sito web può rompersi, sebbene sia più raro rispetto ai siti totalmente dinamici. 

Non si tratta di uno scontro mortale fra i due generatori di siti, ma più una comparazione utile a capire quale soluzione è la migliore per il lavoro che dovrete fare.Dal punto di vista di uno sviluppatore, è più difficile lavorare con Next.js ma, paradossalmente, finisce per essere meno problematico.Come editor, Next.js è migliore per la presenza nativa di una modalità preview che mostra i dati esattamente come appariranno in produzione.

Poniamo di avere un blog molto ricco, con più di 100 pagine.Approccio staticoSe rendiamo tutte le pagine statiche, dobbiamo attendere che Gatsby le renderizzi tutte. Potremo navigare il sito web solo dopo la lunga build.Approccio dinamicoRendiamo solo gli ultimi dieci post statici e, grazie a Next.js, facciamo in modo che il server pensi agli altri. Il sito web richiederà meno di un minuto per la build perché le pagine statiche sono poche, rendendo il sito visibile in minor tempo. Quando qualcuno visiterà un vecchio post, il server renderizzerà quella pagina, come un normale sito dinamico. La differenza è che accadrà solo la prima volta; il secondo visitatore vedrà già la pagina staticizzata.

Entrambi i sistemi hanno pro e contro.Gatsby è più facile da imparare e produce siti web statici indistruttibili. Fornisce un sistema di preview (a pagamento, però) ed è piuttosto semplice. Di converso, non aspettatevi sia incredibilmente veloce in fase di build, perché l’attività può richiedere un sacco di tempo se avete più di 1000 record sul tuo CMS.Next.js ha un sistema di preview ottimo (e gratuito) e vi permette di introdurre elementi dinamici quando e dove necessari. Potete anche recuperare i dati nel modo che preferite. Next.js è però più difficile da programmare. Se vuoi utilizzarlo in maniera mista (statico + dinamico) o solo statico, richiede più conoscenze di programmazione.