Sabino Maggi
Come orientarsi fra le decine e decine di generatori di siti web statici esistenti? Quali scartare a priori e quali considerare per una prova più approfondita? In base a quali criteri selezionare i sistemi promettenti nel mare di quelli non adatti allo scopo o perfino del tutto inutili?
Aiuta parecchio elencare le caratteristiche irrinunciabili, come aiuta leggere le impressioni degli altri utilizzatori. Ma alla fin fine bisogna arrotolarsi le maniche, provare di persona i sistemi ritenuti più promettenti ed affidarsi anche al proprio intuito.
In questi mesi, nei ritagli di tempo, ho provato più generatori di siti web di quello che avrei voluto, quasi tutti quelli elencati nel post precedente. Ma sono stati pochi quelli che mi hanno colpito, nel bene o nel male.
Hyde al primo impatto mi è piaciuto molto per lo stile anni ‘70 del sito. Però dietro lo stile non c’è niente, né introduzione, né documentazione, nulla. Anche il sito corrispondente su GitHub Pages è decisamente povero e di alcune pagine ci sono solo i titoli. Meglio lasciar perdere.
DropPages e Calepin sono accomunati dal fatto di usare Dropbox per gestire il sito web. Non c’è nulla da installare, basta creare una cartella, all’interno di quella standard di Dropbox, che contenga i sorgenti in Markdown del sito. Una opportuna applicazione web accede a questa cartella, converte i documenti e le relative immagini in file html e li sincronizza con il sito vero e proprio, mantenuto sui server di ciascuna delle due applicazioni. Facilissimo, e con il beneficio di avere un backup continuo e automatico di tutto sul cloud. Ma perché dovrei consentire ad una applicazione web di accedere ai miei dati su Dropbox, e con quali garanzie per la sicurezza dei miei file? Lasciamo perdere anche qui.
Pico. Interessante, peccato che non sia mai riuscito a farlo funzionare in locale. Del resto la documentazione si riduce ad una sola paginetta html.
Anchor CMS. Un vero peccato, sembra veramente bello. Ma è stato un errore, in realtà non è altro che un CMS come tanti, con il suo bel database MySQL, proprio quello che volevo evitare.
Octopress, l’ho già scritto, è basato su Jekyll ma cerca di rimuoverne le parti più ostiche, più da programmatore. Ma lo sviluppo di Octopress è fermo da anni, e poi a me questa idea della semplificazione a tutti i costi non piace tanto. Però Octopress merita comunque una menzione d’onore.
Infine arriviamo a Ruhoh. Ruhoh è stato in cima alla lista dei preferiti per parecchio tempo. L’ho installato e provato senza problemi. La documentazione è dettagliata ed estesa, tranne (opinione personale) per quello che riguarda i temi grafici. Però, per creare la struttura del sito e le pagine che lo compongono, bisogna usare dei comandi specifici, ed anche un po’ confusi. Assolutamente no, voglio la libertà, voglio poter creare i documenti che compongono il sito tramite il Terminale, il Finder o anche in remoto, voglio poterli mettere dove preferisco all’interno della struttura del sito, riordinandoli finché non sono soddisfatto e lasciando al generatore il solo compito di convertirli in file html. Anche Ruhoh, purtroppo, non va bene per me. Attenzione che senza un gestore delle “gemme” di Ruby, Ruhoh è pure complicato da rimuovere.