/carnet /phd (brouillon)

Fabriques de publication : Jekyll

Quatrième analyse d’une série sur les fabriques de publication : Jekyll.

Introduction et liste des fabriques

Jekyll est un générateur de site statique, emblématique d’une façon de concevoir et de fabriquer des sites web.

Description

Mais qu’est-ce donc qu’un générateur de site statique (Camden et Rinaldi, 2017) – ou static site generator en anglais ? Sous ce terme quelque peu trompeur se cache une profonde reconfiguration des modes de conception et de fabrication des objets numériques que sont les sites web (Taillandier, 2016). Jekyll est un générateur de site statique parmi tant d’autres, mais emblématique d’une (nouvelle ?) façon d’envisager la production de publications comme les sites web.

Jekyll est un programme, écrit en Ruby, qui génère un site web, donc des fichiers HTML et CSS, à partir de différents fichiers : un fichier de configuration général qui indique les instructions pour le site dans son ensemble ; des fichiers de contenu dans l’un des formats de balisage que Jekyll est capable de comprendre, Markdown dans la majorité des usages, comprenant des informations d’entête comme le titre ou l’auteur ; des gabarits aux formats HTML avec la syntaxe Liquid pour définir les modèles des pages web. En soit rien de bien exotique, cela correspond à des frameworks utilisés depuis longtemps dans le domaine du développement web, ou comme nous l’avons déjà vu à Pandoc qui fait à peu de choses près le même type de transformation. La différence essentielle ici étant que Jekyll gère une publication complexe : un ensemble de documents organisés avec des éléments récurrents, des spécificités en fonction des types de pages, la possibilité de varier les gabarits, etc.

Jekyll est relativement simple à comprendre (Phelan, 2017) et à utiliser. Deux éléments facilitent son usage, y compris pour des personnes éloignées du développement informatique : le fait que Markdown soit le langage de balisage léger utilisé par défaut, et le fait que le choix du langage de templating soit Liquid. Jekyll dispose d’une documentation très complète, et sa popularité a généré de nombreux forums dédiés et d’innombrables billets de blog sur le sujet. Malgré tout, Jekyll est un programme qui s’utilise avec un terminal pour lancer des commandes – générer le site ou le prévisualiser, avec ou sans options. Aujourd’hui des interfaces se branchent via des systèmes de gestion de version, permettant d’écrire, d’enregistrer et de publier des pages et des sites web sans ligne de commande.

Histoire

Jekyll est créé en 2008 par Tom Preston-Werner (Preston-Werner, 2008), qui est entre autre l’un des fondateurs de GitHub, la plateforme d’hébergement de code – inutile de préciser que Tom Preston-Werner est riche. Jekyll est né d’un désir de simplicité à une époque où des systèmes de gestion de contenu (ou CMS pour Content Management System) comme WordPress dominaient largement les usages – et le marché. Pour comprendre comment et pourquoi Jekyll a vu le jour, il faut comprendre quelle communauté a permis son arrivée : des développeurs. Ce générateur de site statique gère les contenus comme du code, d’une certaine façon il simplifie la gestion d’un site web puisque tout est accessible à partir d’un éditeur de code/texte. Il aplatît ce que les CMS classiques gèrent avec des langages dynamiques et des bases de données. Parker Moore sera le développeur principal de Jekyll pendant cinq années (Autrand, 2016), assurant l’évolution et la maintenance de ce programme, mais aussi et surtout réussissant à fédérer une communauté autour de ce générateur de site statique.

Jekyll a été rapidement intégré à GitHub comme l’outil de création de sites web, le fameux service GitHub Pages – nous pourrions d’ailleurs nous demander si Jekyll n’a pas été créé pour disposer d’un CMS versionnable. Ce point est important dans l’histoire de Jekyll et des générateurs de site statique, puisqu’en proposant cette solution par défaut pour créer des pages web, avec un hébergement gratuit associé, GitHub a permis une adoption très large de Jekyll. Au début des années 2010, la mode, chez les développeurs, était d’avoir son site web sur GitHub et généré et hébergé avec GitHub Pages – le service a récemment été revu en terme de communication. Et sans vouloir m’avancer cela a également permis l’émergence du développement continu (Shahin, Ali Babar et Zhu, 2017) avec des plateformes comme GitHub ou GitLab : ce processus qui consiste à déployer automatiquement du code depuis un dépôt Git – je reviendrai sur cette pratique dans d’autres fabriques.

En terme de popularité il faut noter qu’en France, par exemple, la communauté Jamstatic s’est d’abord appelée Jekyll-fr. Si le nom a été rapidement modifié pour englober le mouvement JAMstack dans son ensemble, ce premier essai est symptomatique de l’engouement qu’a suscité Jekyll.

Depuis quelques années et après un succès mérité, Jekyll est désormais détrôné par d’autres générateurs de site statique pour différentes raisons : performance (le fameux temps de build dont il est question plus bas), langages de programmation plébiscités, mode. Aujourd’hui Hugo, Eleventy (de son petit nom 11ty) ou Gatsby sont probablement plus représentatifs du paysage des générateurs de site statique ou de la JAMstack, paysage qui évolue vite.

Specimen

Le nombre de sites produits avec Jekyll doit être tout simplement gigantesque. Plutôt que de prendre des exemples parmi des sites web relativement classiques (comme quaternum.net, généré avec Jekyll), le plus simple est probablement de consulter la page showcase de Jekyll, ou de découvrir les près de deux cent thèmes Jekyll sur JAMstack Themes.

Critique

Jekyll n’est pas le premier générateur de site statique, ni celui qui est le plus utilisé. Mais il est représentatif d’un mouvement, que certain·e·s pourraient qualifier de retour, et c’est vrai que les scripts maison pour générer quelques pages HTML existent depuis les débuts du web. Ce qui m’intéresse c’est de comprendre quel changement de paradigme impose Jekyll, et notamment parce qu’il est simple à utiliser avec beaucoup de fonctionnalités existantes par défaut.

L’expression – ou concept – générateur de site statique est trompeuse car des outils comme Jekyll ne font que générer des fichiers HTML, ce qui n’induit pas qu’un site ainsi produit serait moins dynamique qu’un autre produit avec WordPress. La différence réside dans la fabrication qui se fait en deux temps, et donc les nouvelles contraintes qu’impose ce fonctionnement. Pour gérer les interactions il faut soit utiliser des services extérieurs, soit ajouter d’autres briques logicielles. Il s’agit du A de JAMstack, pour API – je ne m’étends pas sur cette question mais interrogeons-nous sur l’ordre des couches de cette stack (Hoizey, 2020).

Jekyll introduit une dimension asynchrone que les CMS classiques comme WordPress ou Drupal (ou même Spip ou Dotclear) tendaient à faire disparaître, ou plutôt à invisibiliser. En rendant la publication asynchrone, les étapes d’édition d’un site web réapparaissent. Envisager à nouveau un découpage des phases de fabrication d’un site web est crucial, puisqu’il (re)devient possible de séparer des temps qui correspondent à la création et à la gestion d’une publication. Jekyll permet par exemple de travailler sur sa machine, sans être connecté sur un serveur, et de disposer d’un environnement d’écriture et d’édition distinct d’un environnement de publication – beaucoup plus simple à installer et paramétrer qu’avec des CMS dynamiques comme WordPress. Par ailleurs, Jekyll ne traite que des fichiers en plein texte – ou texte brut –, ce qui signifie que les sources du site peuvent être déplacées facilement, sans les contraintes d’une base de données. D’ailleurs nous pourrions émettre l’hypothèse que Jekyll ou d’autres générateurs de site statique ont influencé des flat CMS comme Kirby ou Grav. Et puisqu’il s’agit de fichiers en plein texte, ils peuvent être versionnés (Fauchié, 2020).

Le versionnement n’est pas un détail. La vague des générateurs de site statique, puis celle de la JAMstack, a pour origine des pratiques de développement. La gestion de versions, et Git en particulier, est de plus en plus utilisée dans les processus de conception, de production et de maintenance de la programmation. Proposer des systèmes de gestion de contenu qui prennent en compte Git est quelque chose qui vient de la communauté des développeurs, mais qui a aussi du sens pour des personnes amenées à écrire, quelque soit le type de contenu (GitHub, 2018).

Jekyll peut être augmenté avec des extensions, écrites en Ruby. J’utilise deux extensions très utiles qui illustrent ce fonctionnement : jekyll-microtypo, créée par Boris Schapira, permet d’affiner la typographie principalement pour les contraintes francophones ; jekyll-scholar, créée par Sylvester Keil, permet de créer des citations bibliographiques et des bibliographies à partir de fichiers BibTeX. Le fait d’ajouter des éléments à Jekyll peut devenir un problème, comme la question de la compatibilité entre Jekyll et l’extension, ou le ralentissement provoqué par l’extension. Comparons rapidement cette méthode avec deux autres générateurs de site statique qui ont fait des choix très différents : 11ty est basé sur le langage de programmation JavaScript et l’environnement Node.js, le royaume des extensions et des dépendances (pour le meilleur et pour le pire) ; Hugo ne comporte pas d’extension, si une fonctionnalité est jugée pertinente elle sera ajoutée dans le programme ou gérée autrement – les shortcodes sont par exemple un moyen d’augmenter les possibilités du générateur de site statique en accord avec le programme.

Avec ces éléments nous voyons poindre une autre dimension très intéressante : la modularité. Si des CMS comme WordPress intègrent déjà le versionnement, il n’est pas possible de sortir cette fonctionnalité du système. Markdown pour la structuration du texte, YAML pour les métadonnées, Jekyll pour la génération des fichiers HTML/CSS, Git pour versionner le texte, il s’agit là d’un fonctionnement modulaire.

D’un point de vue technique Jekyll peut être jugé comme lent, ou plutôt comme étant moins rapide que d’autres. C’est ce qui est appelé le temps de build – pour temps de génération des fichiers HTML et CSS le cas échéant. Certains générateurs de site statique ont été conçus en réaction à la relative lenteur de Jekyll, et c’est ainsi que Hugo a fait son apparition, permettant de générer des sites complexes et de taille importante en moins d’une seconde là où Jekyll met plusieurs secondes ou dizaines de secondes. Cela ne me semble pas être l’enjeu déterminant mais il faut bien reconnaître que ce temps de build a des conséquences importantes, comme le temps de calcul d’une machine ou la possibilité de pouvoir prévisualiser une page sans avoir à attendre.

D’autres langages de balisage pouvaient être utilisés dans Jekyll, comme Textile, désormais seul Markdown est supporté. D’ailleurs c’est Kramdown, également écrit en Ruby, qui est le convertisseur utilisé. J’ai découvert récemment qu’il était possible d’utiliser directement Pandoc comme convertisseur. Markdown est un format de balisage léger bien pratique, compréhensible par les humains et les programmes, il reste un peu trop léger. Un peu comme Pandoc, Jekyll permet d’étendre Markdown, notamment via des fonctions comme include ou via celles des extensions – par exemple pour citer avec jekyll-scholar il faut utiliser {% cite diaz_using_2018 %}. Ce qui enrichit contraint également, cette syntaxe dans la syntaxe peut ajouter en complexité pour une maintenance sur le long terme.

Pour terminer sur cette critique trop longue, notons que Jekyll a été et est encore un pont entre des personnes habituées à manipuler du code et des personnes habituées à manipuler des textes. Jekyll n’est pas une fin en soit, mais un moyen de faire converger des pratiques très différentes, notamment par le biais d’interfaces intermédiaires – j’en reparlerai.

Vers d’autres fabriques

Certaines des prochaines fabriques utilisent des générateurs de site statique, j’y reviendrai donc plus longuement. Avant cela citons tout de même Ed, une utilisation de Jekyll pour la réédition numérique de textes littéraires. Même si Ed est présenté comme un thème, nous pouvons considérer que c’est un peu plus que cela : certaines extensions sont plébiscitées comme jekyll-scholar, et il y a une modélisation de l’information qui dépasse le simple thème. Un exemple d’application de Ed. est MARXdown, le nom est suffisamment explicite pour ne pas avoir besoin de préciser l’objet de ce site web – Hypothesis est également utilisé dans ce cas précis. D’autres applications de Jekyll en milieu universitaire existent (Diaz, 2018).

Références

  • GitHub (éd.). (2018). Empowering Non-Developers to Use Git - Git Merge 2018. Consulté à l'adresse https://www.youtube.com/watch?v=pY5i0Io86UQ&feature=youtu.be
  • Autrand, A. (2016, 11 mars). Interview with Parker Moore from Jekyll [Blog]. Netlify. Consulté à l'adresse https://www.netlify.com/blog/2016/03/11/interview-with-parker-moore-from-jekyll/
  • Camden, R. et Rinaldi, B. (2017). Working with Static Sites. O’Reilly. Consulté à l'adresse http://shop.oreilly.com/product/0636920051879.do
  • Diaz, C. (2018). Using Static Site Generators for Scholarly Publications and Open Educational Resources. The Code4Lib Journal, (42). Consulté à l'adresse https://journal.code4lib.org/articles/13861
  • Fauchié, A. (2014, 26 avril). LaTeX et Jekyll : deux workflows de publication [Blog]. quaternum.net. Consulté à l'adresse https://www.quaternum.net/2014/04/26/latex-et-jekyll/
  • Fauchié, A. (2018). Vers un système modulaire de publication: mémoire de Master Publication numérique, Enssib, sous la direction d’Anthony Masure et Marcello Vitali-Rosati (Mémoire, École nationale supérieure des sciences de l’information et des bibliothèques). Consulté à l'adresse https://memoire.quaternum.net
  • Fauchié, A. (2020, 9 janvier). Version : concept [Blog]. quaternum.net. Fauchié, Antoine. Consulté à l'adresse https://www.quaternum.net/2020/01/09/version-concept/
  • Hoizey, N. (2020, 5 mai). JAMstack Is Fast Only If You Make It So [Blog]. Nicolas Hoizey. Consulté à l'adresse https://nicolas-hoizey.com/articles/2020/05/05/jamstack-is-fast-only-if-you-make-it-so/
  • Perret, A. (2018, 17 décembre). Dr Jekyll & Mr TeX [Blog]. Arthur Perret. Consulté à l'adresse https://arthurperret.fr/2018/12/17/dr-jekyll-et-mr-tex/
  • Phelan, J. (2017, 17 janvier). Comment marche Jekyll ? [Blog]. Jamstatic. Consulté à l'adresse https://jamstatic.fr/2017/01/17/comment-fonctionne-jekyll/
  • Preston-Werner, T. (2008, 17 novembre). Blogging Like a Hacker [Blog]. Tom Preston-Werner. Consulté à l'adresse https://tom.preston-werner.com/2008/11/17/blogging-like-a-hacker.html
  • Shahin, M., Ali Babar, M. et Zhu, L. (2017). Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices. IEEE Access, 5, 3909‑3943. doi:10.1109/ACCESS.2017.2685629
  • Taillandier, F. (2016, 8 mars). La mouvance statique. Frank Taillandier. Consulté à l'adresse https://frank.taillandier.me/2016/03/08/les-gestionnaires-de-contenu-statique/