Il bello degli SSG - 1: la pastrugnabilità

Nell’ultimo post ho spiegato che per anni questo blog era stato realizzato con un ottimo CMS, Drupal, prima di passare a Jekyll. Nella conclusione, avevo voluto rispondere (excusatio non petita) ad uno spontaneo quesito: perché il figlio del ciabattino ha sempre le scarpe rotte? Ovvero: “se Drupal è davvero così buono, come mai il tuo blog invece è una schifezza?”.

Ma la mia risposta aveva qualcosa di paradossale: sostanzialmente, il mio blog… non era una cosa seria, serviva soprattutto per sperimentare soluzioni tecniche da adottare negli altri siti, quelli che la gente visita davvero. Ma ora che invece di fare gli esperimenti su Drupal, li faccio su Jekyll… allora tutto cambierà, e il mio blog diventerà una cosa seria!

Se ne deduce che smanettare su un CMS fa male alla creatività, mentre smanettare su un SSG forse è meno dannoso, e magari favorisce anche la digestione. Giusto?

Io dico di sì, per un paio di motivi:

Il primo: con i siti web statici, aggiornare un sito lavorando su una copia locale per poi caricare le modifiche sul server a lavoro ultimato è la prassi ordinaria. Anche il più scarso degli Static Site Generator comprende un micro-server che permette di visitare il “prototipo” via HTTP, mentre una volta bisognava accontentarsi di caricare il file index.html e sperare che una volta online non emergessero problemi. Fare la stessa cosa con un CMS è decisamente più complicato: bisogna installare un web server e un database sul proprio PC, o su una macchina virtuale, o ancora ricorrere a un secondo hosting.

Secondo motivo: la reversibilità delle modifiche. Qualsiasi modifica a un CMS convenzionale (Drupal incluso) coinvolge sia il database (inserimento di tabelle o colonne, registrazione delle impostazioni) che il file system (installazione di moduli/temi/librerie/plugin…). Solo l’inserimento di contenuti puramente testuali non coinvolge il file system. Per questo, registrare un’istantanea dello stato del sistema per poterlo ripristinare quando necessario è un’operazione complessa che va gestita manualmente. A meno di usare un database Sqlite… ma con Drupal anche usare PostgreSQL invece del solito MySQL è già un’acrobazia!

Viceversa, usando un SSG, tutto l’assetto del sito si trova in un albero del file system, come in qualsiasi progetto software, ed è semplicissimo da gestire con git, o con qualsiasi altro sistema di controllo delle versioni! Posso permettermi anche di aprire un nuovo ramo di sviluppo per cominciare a lavorare su un nuovo layout, e nel frattempo continuare a pubblicare nuovi post aggiornando il ramo master: a lavoro ultimato sarà immediato far convergere i due rami e rigenerare il sito con tutti i suoi post e il nuovo layout.

E ora, un buon limoncello.