🖳
Je suis en train de coder un SSG (static site generator) pour pouvoir générer mes sites toute seule.
Jusqu’ici j’utilisais Jekyll. Ce site est réalisé avec, par exemple. Un SSG permet de compiler des pages, essentiellement en Markdown, pour en faire un site web. Jekyll utilise le moteur de templates Liquid pour créer des itérations d’éléments et les insérer dans la page. Son fonctionnement est lui-même codé en Ruby.
Cela fait plusieurs années et une dizaine de sites que je me sers de Jekyll. Je n’ai rien de particulier à lui reprocher, avec l’expérience, j’ai appris à contourner les spécificités qui m’embêtent et à lui faire faire ce que je veux (dans la limite de son usage). Jekyll est un peu en perte de vitesse et sa documentation de moins en moins alimentée.
Ça fait aussi plusieurs années que je cherche des solutions alternatives. Mon but est de créer des outils personnels, qui répondent spécifiquement à mes besoins, sans features inutiles pour moi et sans avoir à faire des manips bizarres pour contourner leur usage initial. La première étape, c’est la fabrication de mon propre SSG. Mais le plus important ça sera de fabriquer mon propre CMS (Content Management System). C’est cet outil qui permettra aux gens pour qui je fais des sites de pouvoir les alimenter sans avoir à écrire eux-même en markdown. Le markdown c’est pas difficile, mais c’est pas non plus inné. Faut avoir envie d’apprendre et je ne peux pas demander ça à mes “client·es”.
Le début de ce post en markdown
Je pourrais proposer de fabriquer un bon vieux site en PHP avec une grosse base de données et des centaines de requêtes serveurs, ça je sais déjà faire. Ça marche et ça permet de fabriquer des systèmes de recherche, de sélection et d’affichage complexes. Mais pour la plupart des commandes qu’on me passe, c’est démesuré par rapport à la simplicité et à l’économie d’un site statique. Ça demande aussi de posséder un espace d’hébergement payant, avec base de données, alors qu’un site statique permet d’envisager des solutions d’hébergement gratuites et de ne payer qu’un nom de domaine. Les personnes ou les associations pour qui je code ont souvent des budgets serrés.
Il faut donc que j’apprenne à coder un SSG et un CMS. Ce sont deux choses que je ne sais pas encore faire, même si je sais les fonctions que ces deux programmes doivent effectuer.
C’est très difficile de trouver des ressources là-dessus sur internet. Je ne trouve que des articles pour choisir le meilleur SSG ou le meilleur CMS parmi la tonne récensée en ligne. Beaucoup de devs ont l’air de se satisfaire de ces solutions pré-existantes. On s’en fout que ça soit chez Amazon après tout. Ou qu’il n’y ait aucune transparence sur la boîte qui développe ça. Je vois même des gens se faire engueuler sur des forums où ils annoncent qu’ils vont construire leurs propres outils. On leur répond que “ça ne sert à rien”, que “c’est une perte de temps”, que “c’est comme réinventer la roue”.
Ce n’est pas du tout réinventer la roue. C’est fabriquer sa propre roue avec les matériaux qu’on a sous la main. Le principe du SSG existe déjà, je ne le réinvente pas, j’ai envie de faire le mien.
Ça peut être simplement pour comprendre un fonctionnement, dans un but d’auto-pédagogie. Je suis intriguée par la roue et je veux comprendre comment c’est fait.
Ça peut être pour avoir le choix de ses propres besoins, pour éviter de faire entrer son site dans un cadre de formats prédéfinis selon des usages moyens, ou d’avoir tout une batterie d’outils dont on ne se servira pas. Il ne neige jamais chez moi et je n’ai pas besoin d’avoir une roue adaptée à la montagne.
Ça peut être aussi pour acquérir son indépendance totale. Si le gars qui me vend des roues est un connard, je peux avoir envie de fabriquer ma propre roue pour ne plus avoir à faire à lui.
Et je ne vois pas ce qu’il y aurait de mal à vouloir réinventer la roue, de toute manière. Ni de perdre son temps. Bref. J’arrête là avec les histoires de roues.
C’est surtout mon indépendance qui me tient à coeur. Pour le site de Carlos par exemple, j’avais choisi au départ d’y associer le CMS Forestry. J’avais spécifiquement choisi celui-là parce que c’était un CMS léger, tout en ligne, qui ne me demandait pas beaucoup d’intégration. Ça faisait partie de l’économie du projet : Le budget était serré et on préférait se concentrer sur le design du site. Un an après, Forestry a cessé d’exister, TinaCMS a repris la boîte et le fonctionnement du CMS s’est complètement transformé. Il a fallu travailler à nouveau sur le site, passer plusieurs jours à lire la doc et à intégrer le CMS, à gérer les spécificités du projet et à m’énerver sur le build des pages sur Github Pages. TinaCMS est un très bon CMS, mais sa doc est lacunaire et demande une expertise que j’ai dû acquérir. Je n’ai pas voulu faire payer Carlos à nouveau. Un an plus tard, des mises à jour d’un plugin Github dont TinaCMS dépend m’ont encore obligé à retravailler là-dessus pendant une journée.
Bien sûr, si je fabrique mon propre CMS, il faudra aussi l’entretenir, l’améliorer et le maintenir à flot. Mais il s’agira de travailler sur mon propre outil et donc de récupérer mon investissement de temps.
Grâce à Naveera Ashraf, j’ai enfin trouvé deux très bons articles qui me permettent de commencer la programmation de mon SSG en Python. Ça fait longtemps que je veux mettre le nez dans du Python, alors je saute sur l’occasion. En deux heures, j’ai un petit système qui marche. Les instructions de Naveera s’arrêtent là et je vais devoir continuer toute seule, mais ses explications m’ont donné la confiance pour le faire.
Pour le CMS par contre, je suis toujours bredouille. Alors que c’est la pièce maîtresse du projet. Il faut que j’arrive à construire un programme qui lise et écrive des fichiers et surtout, qui compile le site et ensuite le déploie sur GithubPages. Je vais continuer à chercher, dans d’autres endroits.
Je vais déjà m’occuper du SSG, on verra après. Mais quand tout ça sera fait, je serai libre (et fière).