Da melabit a melabit: perché Jekyll?

– 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é!

Ci sarà da divertirsi.