Jeeeeeekyll? No, Hugo!

Sat, 24 May 2025 00:00:00 +0000

Mentre descrivevo come ero passato da Wordpress a Jekyll, sapevo già che avrei dovuto cambiare di nuovo.

Da un punto di vista tecnico, Jekyll è una piattaforma fantastica: è facile da programmare, ha una documentazione ineccepibile e funziona perfettamente durante la fase di sviluppo, quando il numero di pagine e di post di test è limitato. Ma, come ho sperimentato in prima persona, una volta che Jekyll si trova a dover gestire un sito vero con centinaia di post, le prestazioni calano drasticamente e i tempi di risposta aumentano in modo intollerabile (e piuttosto imbarazzante).

A fine anni ‘90 era normale aspettare diversi secondi prima di visualizzare una pagina web.¹ Ma oggi siamo abituati a pagine che si caricano immediatamente, e una attesa di tre, quattro secondi è inaccettabile.

Un prezzo troppo alto da pagare

Prima di iniziare a lavorare sul nuovo sito sapevo bene che Jekyll era lento, ma questa lentezza si riferiva sempre alla fase di generazione del sito, una operazione che si esegue di rado e può essere facilmente automatizzata. E in effetti è proprio così: durante lo sviluppo, con poche decine di post, rigeneravo il sito in 10-20 secondi, una cosa seccante ma non drammatica; ora ci vogliono 15 minuti per rigenerare l’intero melabit.com.

Quello che non sapevo era che anche il sito generato avrebbe sofferto dello stessa problema, come è diventato evidente non appena ho terminato la fase di sviluppo e ho iniziato a lavorare con tutti i post.

In quel momento ero ancora convinto che l’ottimizzazione del codice e delle immagini e un caching aggressivo avrebbe potuto attenuare il problema. E comunque ero andato troppo avanti per fermarmi. Ma dopo poco mi sono accorto che questa strategia non era sufficiente, e che ci voleva un ripensamento radicale. E ho cominciato a guardarmi attorno.

Alternative

I generatori di siti statici sono come le distribuzioni di Linux: abbondano e quasi sempre non si capisce il senso della loro esistenza. In questo momento, Jamstack ne elenca 366, mentre Static Site Generators arriva a quasi 500. La maggior parte è stata abbandonata, magari perché nessuno le utilizzava o perché lo sviluppatore non era interessato a continuarne lo sviluppo. Diciamo che quelle interessanti sono una decina o poco più.

Fra queste ho considerato (brevemente, lo ammetto) Bridgetown, che deriva da Jekyll e quindi, a prima vista, sembrava una evoluzione naturale. Ma poi mi sono accorto che lo usano in pochi, che i plugin sono scarsi e i temi ancora meno. E poi, se Bridgetown discende da Jekyll, non è che soffre dello stesso problema di lentezza? Meglio stare alla larga e tenersi l’originale.

Altro candidato era Middleman, sviluppato in Ruby come Jekyll, Ma Middleman è destinato a generare il classico sito web, e ci vuole una estensione specifica per fargli supportare le funzioni tipiche di un blog (liste di articoli, tassonomie, feed, commenti). E poi il linguaggio di templating è ERB (Embedded Ruby), che in sé è una scelta sensata dato che è integrato nello stesso Ruby, ma che per me significava dover reimparare tutto da zero.

Ve la faccio breve: alla fine dei conti l’unico candidato serio era… il solito Hugo.

Alla ricerca della velocità

Di Hugo avevo già scritto molti anni fa, trovandolo interessante, ma azzoppato da una documentazione che definire scarsa era un complimento.²

Però la qualità non è in discussione, non a caso Hugo, proprio come Jekyll, finisce sistematicamente in cima a tutte le classifiche che si prefiggono di valutare la qualità dei vari generatori di siti statici.

E poi Hugo ha un vero asso nella manica: è veloce, anzi è velocissimo.

Non so dire se Hugo sia davvero il più veloce framework al mondo per la costruzione di siti web, come sostiene lo slogan in cima alla sua home page. Ma ho verificato in prima persona che Hugo è in grado di generare questo sito in meno di un minuto, cioè 15 volte più rapidamente di Jekyll. E, quello che più conta, anche il sito generato risulta essere veloce e reattivo, proprio come ci si aspetta da un sito web moderno. Questo fa passare tutto il resto in secondo piano.

Hugo

E allora da oggi melabit.com passa ad Hugo, con una nuova grafica³ e cercando di mantenere tutte le funzioni della versione basata su Jekyll. Prima fra tutte il sistema di commenti basato su Comma, che dopo il trapianto ha funzionato praticamente al primo colpo.

I permalink sono cambiati e ora distinguono esplicitamente la lingua del post, che è una cosa più razionale. Anche il feed è cambiato, per ora è il vecchio RSS, prima o poi verificherò se è possibile aggiungere ATOM.

La funzione di ricerca per ora è basata su Google, e non funzionerà finché il sito non sarà indicizzato di nuovo. La paginazione va rivista, così come la logica che mostra il post in evidenza anche nella lista di tutti i post. Ma ci sarà tempo per sistemare questi dettagli.

Per formazione mentale mi piacerebbe entrare nei dettagli di come ho modificato Hugo e il tema grafico prescelto, ma temo di risultare noioso, soprattutto dopo tutti gli articoli, dettagliatissimi ma ormai praticamente inutili, scritti su Jekyll. Ci penserò un po’ su, nel frattempo se qualcuno è interessato a saperne di più può scriverlo nei commenti.

– Immagine generata da Google Gemini.

Però ci si poteva distrarre guardando le immagini comparire una riga alla volta sullo schermo… 😂 ↩︎
Rispetto ad allora non è cambiato molto. Uno dei pochi articoli che posso consigliare senza riserve è questo sulla gestione del contesto e delle variabili in Hugo. Una lettura molto tecnica, ma indispensabile per imparare le basi necessarie a modificare ed estendere Hugo. ↩︎
Che non mi fa impazzire, ma che per ora è il meglio che sono riuscito a fare. ↩︎

Da melabit a melabit: perché Jekyll?

Tue, 21 Jan 2025 18:00:00 +0000

– Fonte: Jametlene Reskp su Unsplash.

Come dicevo nell’ultimo post, lasciare la comfort zone di Wordpress non è stato per niente facile.

Fra doversi preoccupare solo di scrivere qualcosa di interessante, con tutto il resto gestito da una squadra di amministratori di sistema ed esperti di programmazione web, a dover fare tutto da solo c’è un abisso.

C’è voluto un bel po’ di tempo per configurare il nuovo sistema, aggiungere le funzionalità mancanti e risolvere i (tanti) problemi tecnici imprevisti. Tanto più che in parallelo continuavo a svolgere la mia normale attività lavorativa e, non dimentichiamo, dovevo pure scrivere un post ogni tanto.

Di conseguenza, la prima necessità era basare questo nuovo blog su una piattaforma stabile e affidabile, che non cambiasse pelle ogni settimana o, peggio, che scomparisse improvvisamente dalla circolazione perché lo sviluppatore si era stufato di giocare con il suo progetto.

Anche la disponibilità di una documentazione abbondante e ben fatta era fondamentale: avere guide chiare per configurare il sistema e trovare risposte rapide ai problemi (che sono inevitabili) è un aiuto enorme per non perdere giorni interi a impazzire dietro al codice.

Su queste basi la scelta era inevitabile, ed era identica a quella di tanti anni fa: Jekyll.

Perché Jekyll avrà pure tanti difetti, fra tutti la lentezza nella generazione del sito e la pesantezza del codice generato, ma esiste da ben 16 anni, viene ancora sviluppato con regolarità ma senza stravolgimenti (l’ultima release è di settembre 2024), e sul web si trovano guide su tutto ciò che può venire in mente quando si sviluppa un sito con questa piattaforma.

Del resto, non sarà certo un caso se GitHub ha scelto proprio Jekyll come piattaforma per generare un sito direttamente da un suo repository.

A suo tempo, Jekyll mi aveva tanto convinto da spingermi a scrivere tutti i 482 post del blog su wordpress.com in Markdown, con una intestazione in YAML come quella usata di Jekyll e con le immagini salvate in cartelle con lo stesso nome del post.

Su WordPress non serviva, perché tutto quello che dovevo (e potevo) fare era copiare il testo in un nuovo post, aggiungere le immagini e premere in bottone di pubblicazione (beh, in realtà è un po’ più complicato, ma ci siamo capiti).

Ma avere tutto bello e pronto nel formato giusto ha semplificato parecchio la transizione da WordPress a sito statico basato su Jekyll. Mi è bastato preparare la struttura di base, aggiungere i post e le immagini, e generare il sito per avere tutto bello e pronto (anche qui le cose sono leggermente più complicate, ma l’idea di base è quella).

Se non avessi conservato i testi originali, avrei potuto usare un plugin WordPress per esportare i post da WordPress in Jekyll (è proprio vero che esiste un plugin WordPress per qualunque cosa!). Ma il plugin non supporta i commenti, le immagini finiscono in una directory non standard e vanno spostate in quella corretta, bisogna correggere tutti i link… Alla fine, nel mio caso ci sarebbe voluto più tempo a sistemare tutto che a ripartire da zero.

Ora il lavoro di base è finito e tutte le funzioni principali del nuovo sito bene o male funzionano. A questo punto diventa più facile esplorare delle soluzioni alternative e, si spera, più performanti di Jekyll. In cima alla mia lista ci sono Bridgetown, che è un fork di Jekyll che vale la pena approfondire, e Middleman, che mi incuriosisce parecchio anche se non so bene il perché!