Blog à fonctionnalité minimale (Minimum viable blog)

• Le blog personnel est mis en place comme une page statique sur un domaine déjà possédé, avec pour objectif une implémentation minimale qui permette à la fois l’ajout de contenu et un SEO de base
• L’implémentation suit un enchaînement simple : un petit template.html, markdown2, un render.py généré sur demande à O1, puis la rédaction des articles en Markdown
• Le modèle n’utilise que les bases du HTML/CSS, comme system-ui, une largeur maximale de 70ch, color-scheme: light dark, viewport et UTF-8
• render.py convertit ./posts/{post}/eng.md en HTML, ajuste les chemins d’images, puis génère ./blog/{post}.html et index.html
• L’exemple montre qu’il est possible d’exploiter un blog uniquement avec du rendu statique et de l’hébergement, sans Jekyll, Ghost ni WordPress

---

Exigences minimales d’un blog et implémentation réelle

• Le point de départ reposait sur quatre exigences
  • utiliser un domaine déjà possédé
  • suivre les standards web modernes et disposer d’un SEO correct
  • rendre l’ajout de nouveau contenu très facile
  • construire toutes les pages de manière statique
• Le flux d’implémentation réel est simple
  • écrire un petit template.html
  • exécuter pip install markdown2
  • demander à O1 un script render.py
  • écrire les articles, les rendre, puis les héberger
• Aucun moteur de blog existant comme Jekyll, Ghost ou WordPress n’est utilisé

Modèle et script de rendu

• template.html contient uniquement la structure de base d’un document HTML et un minimum de CSS
  • color-scheme: light dark définit les modes clair/sombre
  • le style du corps utilise system-ui, sans-serif, une largeur maximale de 70ch, une hauteur de ligne de 1.5 et une taille de police de 1.25em
  • il utilise un lien d’accueil avec id="head-link" et l’emplacement réservé {{ content }}
• render.py convertit les articles Markdown en HTML avec markdown2
  • le répertoire d’entrée est ./posts et le répertoire de sortie est ./blog
  • chaque article est lu depuis ./posts/{post_directory}/eng.md
  • le premier en-tête # est utilisé comme titre de l’article
  • le Markdown est converti avec les options fenced-code-blocks et header-ids
  • les chemins d’images dans <img src=" sont réécrits en se basant sur /posts/{post_code}/
  • {{ content }} du modèle est remplacé par le HTML converti, et la chaîne du titre est elle aussi remplacée par le titre de l’article
• La page d’index est également générée dans le même script
  • greetings.md est d’abord converti en HTML
  • les titres de chaque article sont lus pour ajouter une liste de liens vers /blog/{post_code}.html
  • le résultat final est enregistré dans index.html
• L’article a été rédigé manuellement le 2025-03-31

[ifmkl]

Moi aussi, j’exploite actuellement mon blog exactement de cette façon. J’utilise un SSG que j’ai créé pour répondre à mes besoins personnels. J’y ai ajouté des fonctionnalités personnalisées, notamment pour gérer les images de miniature, les catégories et les tags. Les images jointes sont automatiquement converties en webp et référencées comme telles, ce qui me donne une vitesse de rendu très satisfaisante.

[winterjung]

Oh, donc vous ajoutez ce genre de fonctionnalités personnalisées en écrivant directement le code au fur et à mesure ? Moi aussi, j’essaie toujours de faire les choses en DIY, mais j’hésite à chaque fois à cause des fonctions d’extension et des plugins proposés par les frameworks de blog SSG que j’utilisais déjà.

[ifmkl]

Il suffit de se débarrasser du superflu, et le reste n’est pas vraiment si difficile. Même avec ssg, si vous le demandez à une IA, elle écrit tout le code, et si vous lui demandez d’ajouter des fonctionnalités, elle peut en fait toutes les ajouter aussi, haha.

[ndrgrd]

Quand on choisit juste une jolie police, ça devient assez agréable à lire.

[GN⁺]

Avis de Hacker News

• Ce billet de blog me rappelle ce graphique : https://molodtsov.me/2023/02/how-to-start-your-blog-in-2023/
  Quand je me suis enlisé dans le marais des générateurs de sites statiques (SSG), je passais l’essentiel de mon temps à écrire sur le SSG lui-même et à le bricoler, au lieu d’écrire les textes que je voulais vraiment écrire ou de faire ce que j’avais prévu
  Finalement, j’ai abandonné le SSG, installé WordPress et arrêté de m’en préoccuper ; ça a été très libérateur
  Si l’objectif est de bricoler et d’écrire sur ce processus, très bien ; si le bricolage n’empêche pas quelqu’un d’écrire, très bien aussi, mais ce n’était pas mon cas
  La dernière chose dont on a besoin au moment où l’on veut écrire, c’est d’une excuse pour remettre à plus tard

  • WordPress en 2025 combine deux caractéristiques dangereuses
    WordPress et tous ses plugins doivent être tenus à jour, sinon ils peuvent être compromis ; et le BDFL est quelqu’un qui peut, pour de petits motifs personnels, bloquer la distribution des mises à jour de sécurité ou l’accès permettant de les recevoir
    Un site statique n’a pas de failles de sécurité à corriger, donc même si un projet SSG s’effondre complètement à cause de problèmes liés au mainteneur, ce n’est pas très grave ; avec WordPress, en revanche, cela devient crucial
  • Même expérience de mon côté. Il y a longtemps, j’ai commencé avec DokuWiki, puis j’ai décidé d’essayer GitHub Pages ; après avoir tout migré, j’ai eu besoin de recherche, donc j’ai ajouté une recherche Google personnalisée
    Il fallait un moyen pour les visiteurs de laisser des commentaires, alors j’ai ajouté Disqus, et au final c’est devenu un fourre-tout mêlant plusieurs services et beaucoup de JavaScript
    Il y a quelques années, pour redevenir propriétaire de mes données et ne plus dépendre de services externes, j’ai exporté les commentaires Disqus, puis j’ai bricolé Serendipity avant de me fixer sur WordPress
    J’ai pu importer les commentaires et les pages Markdown, et il existait aussi un plugin qui publiait tout vers le Fediverse
    Je l’ai fait fonctionner avec SQLite et j’ai activé les mises à jour automatiques ; depuis, il ne demande pratiquement plus de maintenance
  • Du spam de blog ? :) L’URL est https://rakhim.org/honestly-undefined/19/
  • Je suis d’accord, mais je pense que dans 95 % des cas, WordPress est excessif
    Il demande trop de maintenance pour des fonctionnalités dont on n’a probablement pas besoin. Si on ne le tient pas à jour, il peut devenir une partie d’un botnet
    Pour la plupart des blogs, un générateur de site statique suffit, et même s’il faut faire de la maintenance, je peux la faire au moment qui me convient
  • Je suis assez satisfait de nikola : https://getnikola.com/
    Ce que je voulais vraiment, c’était une seule commande pour publier et un moyen simple de glisser-déposer des images dans les articles ; le premier point fonctionne bien, et le second est possible grâce à la publication de Jupyter Notebook
    Ce que je n’ai jamais voulu, c’est une approche où « envoyer du HTML au client » s’accompagne d’un fardeau comme une base de données

• C’est bien, mais j’ai l’impression qu’il manque deux petites fonctionnalités pour pouvoir appeler ça un blog
  D’abord, les articles doivent être triés par date, avec les plus récents en premier, et la date doit être affichée quelque part. Pour garder une configuration minimale, on peut utiliser les métadonnées du fichier de l’article, par exemple l’heure de création
  Ensuite, il faut évidemment un flux RSS. Avec le script existant et un modèle RSS minimal, il devrait être facile de créer un flux simple contenant seulement les liens et les titres

  • RSS, c’est bien, mais je ne pense pas que ce devrait être une condition nécessaire pour être reconnu comme un blog
    Être « suivi » n’est pas toujours une bonne chose et peut créer une pression pour s’adapter aux lecteurs. C’est précisément ce qui rend les réseaux sociaux nocifs
  • C’est pertinent
    Pour le point 1, je penche vers la génération automatique d’un fichier contenant les métadonnées dans un format comme TOML
    Pour le point 2, j’ajouterai certainement RSS, mais cela dépend du point 1 :-)

• J’ai toujours aimé les sites web indépendants, et le mien a commencé de façon similaire il y a environ 25 ans
  À l’époque, la seule technologie adaptée que je connaissais était Classic ASP, donc j’ai fait quelque chose de minimal et de simple, uniquement en ASP
  Aujourd’hui, il fonctionne comme un site généré statiquement en Common Lisp, et je pense que cette configuration deviendra mon installation de long terme : https://github.com/susam/susam.net/blob/main/site.lisp
  Commencer avec un simple ensemble de pages était une bonne manière de créer un site web minimum viable, mais avec le temps il m’a fallu des fonctionnalités comme un flux RSS, une liste de billets de blog par date, un index par tags, la prise en charge de contenus non-blog comme des outils, jeux et démos, ainsi que des commentaires sans tiers
  À chaque nouvelle exigence, le code source a grandi aussi : de quelques centaines de lignes, il est maintenant passé à environ 1 300 lignes de Common Lisp
  Malgré tout, je veux le garder à un niveau où je peux avoir tout le code en tête d’un coup et, en cas de bug, le raisonner et le corriger en moins de 10 minutes
  Ces temps-ci, je suis tenté d’ajouter une blogroll proposant la liste des articles de mes blogueurs préférés. Cela pourrait même remplacer un lecteur de flux, mais je vais faire attention à ce que ça ne grossisse pas jusqu’à devenir un truc qui lit aussi les e-mails

  • J’ai suivi presque le même chemin
    Le code source est ici : https://github.com/brilee/modern-descartes-v2/blob/master/ma...
    Il inclut un flux RSS, une liste de billets par date, un système de tags et un serveur de développement local avec surveillance des fichiers et recompilation
  • Mon parcours a été similaire aussi, et en fait je l’ai refait plusieurs fois
    La version actuelle tient dans un script Python de moins de 1 000 lignes : https://github.com/llimllib/obsidian_notes/blob/c93b9b5c46fe...
  • C’est exactement ça. La capacité de décider « je veux construire cet appareil » et de le coder soi-même vaut mieux que n’importe quel WYSIWYG
    J’ai créé des pages dérivées comme des ensembles d’articles, des index et des diaporamas, ainsi que des variantes de tags pour des personnes et des jeux vidéo
    On peut aussi contrôler entièrement l’apparence et le ressenti de widgets courants comme des galeries de vignettes ou des encadrés de citation
  • J’ai créé dans Lamb une fonctionnalité Flock, qui syndique des flux vers mon blog. Je l’ai surtout faite comme alternative à une approche multi-utilisateur : https://github.com/svandragt/lamb
    Cela peut servir de référence de haut niveau
  • RSS et les dates semblent clairement nécessaires
    À l’avenir, je pourrais aussi vouloir intégrer des shaders et des jeux web, mais j’espère que la complexité ne gonflera pas trop

• J’aimerais que les navigateurs prennent en charge nativement text/markdown et text/gemini
  Si un navigateur peut rendre des PDF, il ne devrait pas être si difficile d’y mettre un formateur simple pour du contenu Markdown/Gemini et une feuille de style définissable par l’utilisateur
  On peut déjà tenir un blog en text/plain, mais ce n’est pas vraiment de l’hypertexte et on y perd en SEO. Peut-être qu’il y aurait moyen de faire un peu de magie avec l’en-tête link
  Prendre en charge d’autres formats abaisserait la barrière à une publication propre et redonnerait le contrôle à l’utilisateur

  • Le rendu Markdown natif dans le navigateur serait appréciable, mais malheureusement cela me paraît peu probable
    Il faudrait d’abord que les navigateurs se mettent d’accord sur la variante de Markdown et les extensions à utiliser. Markdown est presque le CSV des formats texte : chacun l’utilise à sa façon
    Si c’est trop minimal, on se plaindra que c’est inutile ; si l’on choisit des extensions, on se plaindra que c’est boursouflé
    Même si l’on essaie de discuter prudemment des avantages et inconvénients à court et long terme, on risque de se faire couper par « ne laissons pas le mieux être l’ennemi du bien »
    Même en se mettant d’accord sur un ensemble précis de fonctionnalités, on peut se demander si cela en vaut vraiment la peine
    Lire des PDF directement dans le navigateur est suffisamment courant, mais les bénéfices de lire du Markdown directement ne profiteraient probablement qu’à une partie des développeurs logiciels dans le monde et à cinq personnes bizarres
    Donc je ne serais pas surpris de ne pas voir de rendu Markdown natif dans les navigateurs de mon vivant
  • Le rendu PDF dans les navigateurs a été fait en JavaScript, ou du moins l’a été à une époque
    Il existe aussi des bibliothèques XSLT utilisables quand on a besoin d’une version plus récente que le support natif du navigateur, ainsi que des bibliothèques pour divers formats comme jpegxl
  • Gemini a aussi son propre format ?

• Avec html_content = html_content.replace('Minimum viable blog', title), est-ce que chaque occurrence de la chaîne Minimum viable blog dans l’article est remplacée par le titre de l’article actuel ? Ce n’est pas un bug ?

  • Oui, bien vu
    Le code dans l’article était le premier brouillon produit par O1, et cette chaîne a été remplacée par {{ title }}

• J’expérimente les blogs minimalistes depuis environ 15 ans, et j’ai appris quelques astuces
  Un simple const title = lines.match(/# (.+)/)[1] suffit, ce qui permet d’éviter le frontmatter
  Mes blogs n’ont jamais eu assez d’articles pour avoir besoin de pagination, de tags, de catégories ou de tri
  JSX est assez pratique comme pur builder de chaînes côté serveur si l’on utilise un hack douteux comme https://immaculata.dev/guides/enabling-jsx.html
  Maintenant, avec GitHub Pages, il est aussi devenu facile d’utiliser une étape de build arbitraire au lieu de Jekyll avec quelque chose comme https://immaculata.dev/guides/using-gh-pages.html
  highlight.js est presque le roi de la coloration syntaxique du code ultra simple, puisqu’il suffit d’ajouter trois lignes au HTML ; shiki est magnifique, mais lent

• C’est facile si l’on utilise un framework standard de blog statique comme Hugo/Zola + Cloudflare Pages
  Mon blog aussi est une configuration minimale de moins de 100 Ko et respecte tous les critères énumérés par l’auteur de l’article original
  J’utilise le thème Hugo Blog Awesome, j’ai suivi les recommandations des 512 Ko, vérifié la taille des pages, et supprimé les images ainsi que le JS inutile. Il n’y en avait pas beaucoup au départ
  Références : https://512kb.club, https://radar.cloudflare.com/scan

• J’ai tenu un « MVB » pendant un temps, mais le mien était encore plus simple
  J’avais simplement une page HTML, j’écrivais les articles dans des fichiers .txt et je mettais la page d’accueil à jour manuellement
  C’était assez verbeux, mais je pense que c’était tout de même plus simple que d’avoir affaire au web moderne
  Je suis ensuite passé à quelque chose de plus sophistiqué, et j’utilise maintenant Astro pour mon site personnel et mon blog ; c’est vraiment excellent
  Astro affirme sur sa landing page être la meilleure plateforme pour les « sites centrés sur le contenu » et, après 6 mois d’utilisation, je suis d’accord
  Il fournit des conventions claires et faciles à suivre pour presque tout ce qu’il faut afin de créer un blog, et élimine le superflu

  • Astro est vraiment impressionnant. Je ne comprends pas pourquoi il n’est pas plus populaire
  • Je me demande si tu utilises le thème de quelqu’un d’autre ou si tu l’as créé toi-même

• J’ai expérimenté sur quelques sites une approche avec Bun JS et du HTML dans des chaînes JavaScript
  Bun dispose d’un flag —hot qui régénère le HTML statique lors des modifications
  L’IDE IntelliJ détecte le commentaire // language=html au-dessus d’une chaîne, puis formate et colore syntaxiquement le HTML qu’elle contient
  En utilisant des fonctions JavaScript pures au lieu d’un langage de templates, on peut écrire directement la logique dont on a besoin sans chercher comment le faire dans ce langage de templates

• Lassé des sites web trop lourds et longs à charger, j’utilise une approche très similaire pour mon blog : https://blog.borrego.dev
  Source : https://github.com/agubelu/blog

  • J’aime beaucoup, et c’est joli. Comment ça rend sur mobile ?