Construire un site web sans framework ni multitude de bibliothèques

• Koding Kitty a adopté une stack centrée sur le HTML statique pour le site web d’une petite entreprise, afin d’exploiter les pages nécessaires et un blog sans gros CMS ni framework
• Les critères de choix étaient la vitesse, la facilité de développement, un hébergement peu coûteux et une faible complexité ; WordPress, le no-code, les frameworks et le Jamstack impliquaient trop de configuration et d’apprentissage par rapport aux besoins
• Le contenu est rédigé directement en HTML plutôt qu’en Markdown ou via un éditeur visuel, ce qui facilite la gestion d’articles mêlant texte et widgets HTML/CSS/JS
• Les structures répétitives et les blocs communs sont gérés avec des templates Jinja, et un script Python de 45 lignes enchaîne la détection des changements, le rendu HTML et l’appel à Tailwind CSS CLI
• Comme il s’agit d’un site statique, un hébergement bon marché suffit ; l’offre web hosting de Hetzner démarre à 2 EUR et a supporté un pic de trafic jusqu’à une apparition en première page de Hacker News

---

Pourquoi avoir choisi une stack simple

• La stack technique du site de Koding Kitty a été volontairement conçue de façon simple, non pour suivre la tendance récente du développement web léger, mais pour répondre aux besoins réels
• L’objectif était une configuration avec peu de friction pour les développeurs, et l’équipe estimait qu’une solution simple pouvait être meilleure pour le client qu’un assemblage complexe de frameworks et de bibliothèques
• Un design distinctif sans être excessif pouvait être réalisé de plusieurs façons, mais la configuration actuelle est un choix adapté au périmètre nécessaire

Exigences et critères initiaux

• Il a été décidé dès le départ de créer un site web statique
• Les fonctionnalités nécessaires se limitaient essentiellement à une page d’accueil, une vitrine et un blog, sans beaucoup plus
• Il y avait quatre critères
  • un site web rapide
  • un développement rapide
  • un hébergement peu coûteux
  • une complexité minimale

Options envisagées puis écartées

• WordPress et CMS similaires

  • L’équipe reconnaît que WordPress a joué un rôle majeur sur Internet
  • Mais c’était excessif pour des besoins modestes
  • Il n’était pas nécessaire de stocker le contenu dans une base de données, ni d’utiliser des plugins ou un éditeur visuel

• Outils no-code

  • Pour des développeurs web, utiliser des outils no-code semblait peu naturel
  • L’équipe voulait garder la pleine possession du contenu et manipuler le site comme elle le souhaitait
  • Elle jugeait qu’écrire du code était plus rapide que d’utiliser un éditeur WYSIWYG no-code
  • Le besoin d’apprentissage initial et continu restait également un frein

• Frameworks

  • L’équipe avait déjà de l’expérience avec des frameworks, mais ne voulait pas reprendre toute leur configuration
  • Cela pouvait ajouter trop de composants comme une base de données, de la configuration, des bibliothèques et des fonctions d’administration
  • Même s’il est possible de tout personnaliser, le résultat risquait finalement de ressembler à WordPress

• Jamstack et générateurs de sites statiques

  • Les générateurs de sites statiques semblaient bien correspondre aux besoins
  • Ils permettent de choisir un langage, de coder puis de produire rapidement un site statique via un bouton ou un script
  • Mais ils demandaient une configuration initiale ainsi qu’un apprentissage de départ et continu
  • L’équipe reconnaissait le confort d’écrire un blog en Markdown, mais a finalement choisi une solution plus simple dans l’ensemble

Composition de KittyStack

• La configuration de Koding Kitty s’articule autour des quatre exigences

• Site web rapide

  • Un site web statique est rapide

• Développement rapide

  • Le contenu est écrit en HTML, pas en Markdown ni dans un éditeur avancé
  • Les articles de Koding Kitty mêlent texte et widgets HTML/CSS/JS, donc écrire directement en HTML convenait bien

• Hébergement peu coûteux

  • Le coût d’hébergement d’un site statique varie selon le fournisseur et les fonctions supplémentaires nécessaires
  • Un site statique n’exige pas d’infrastructure matérielle importante, ce qui permet de choisir une configuration minimale
  • Hetzner webhosting démarre à 2 EUR
  • Le site de Koding Kitty a supporté un pic de trafic du niveau d’une apparition en première page de Hacker News

• Complexité minimale

  • Certaines pages et certains articles comportent des motifs répétitifs
  • Cela pourrait se faire par copier-coller, mais deviendrait difficile à maîtriser avec le temps
  • Il fallait des boucles et la possibilité d’inclure des blocs de code comme l’en-tête et le pied de page

Jinja et le flux de build

• Les structures répétitives et l’inclusion de fichiers communs sont gérées avec des templates Jinja
• Jinja fournit des boucles, l’inclusion de fichiers comme la barre de navigation et le pied de page, ainsi que d’autres fonctions de template
• L’équipe avait déjà utilisé dans le passé un framework basé sur Jinja, il n’était donc pas nécessaire d’apprendre un nouveau système

Une chaîne d’outils simple

• Les pages statiques finales sont générées par un script Python de 45 lignes
  • Ce nombre inclut les commentaires et les lignes vides
• Le flux de build se déroule ainsi
  • Le développeur modifie index.src.html
  • Watchdog.py détecte le changement de fichier
  • Le template Jinja est rendu en index.html
  • Tailwind CSS CLI est appelé pour générer styles.min.css
• Pendant le développement, Live Server sert les fichiers et recharge la page à chaque modification
• Au moment du déploiement, les fichiers sont téléversés manuellement via FTP

Les avantages d’un développement web moins complexe

• Le développement web peut rester simple sans sacrifier énormément de choses
• Limiter le nombre de choix peut au contraire donner davantage de liberté
• Pour beaucoup de clients, une solution plus rapide, plus simple et moins chère peut être utile
• Il faut examiner le web dans son ensemble pour déterminer s’il est possible d’obtenir le même résultat avec une stack technique moins complexe

[GN⁺]

Avis sur Hacker News

• J’ai fini par adopter la même approche pour mon portfolio photo. En passant du développement à la photo, l’avantage est de ne pas devoir dépendre de Squarespace comme beaucoup d’autres photographes
  Après avoir essayé plusieurs options basées sur un serveur, comme Ghost, Statamic, Phoenix/Vapor, ainsi que des générateurs de sites statiques plus classiques, j’ai finalement opté pour du HTML pur sans template, envoyé sur un serveur Hetzner avec rsync
  L’absence de template pour les éléments d’interface communs comme la navigation est un peu gênante, mais jusqu’ici je n’ai jamais eu de modification prenant plus de quelques minutes avec des regex, et la fois où une regex trop gourmande a effacé du contenu, git m’a sauvé
  Générer des variantes d’images selon la taille et le format est fastidieux, mais cela pousse à essayer de nouvelles mises en page au lieu de s’appuyer sur des layouts rigides comme ceux de Ghost. Et en plus, les images exportées pour le web depuis Capture One, mon éditeur RAW, me semblaient légèrement meilleures que celles produites par les bibliothèques ou outils CLI utilisés par la plupart des générateurs de sites statiques
  C’est plus lent, mais j’y vois quelque chose de plus proche de la fabrication d’un livre photo. Au début, cela demande plus de travail manuel, mais une fois terminé, c’est terminé, et il n’y a pas besoin de passer les 20 prochaines années à migrer entre différents CMS en cassant tout

  • On peut gérer une navigation précédent/suivant basique ainsi que des menus, en-têtes et pieds de page cohérents avec des server-side includes
  • Mon site photo personnel utilise Svelte + TailwindCSS, l’API Flickr et Netlify
    En pratique, c’est juste une poignée de fichiers HTML avec la puissance des templates en plus, les photos sont récupérées via l’API Flickr depuis un album dédié à ce site, et Netlify déploie automatiquement dès que je fais un git push
    Le coût total, hébergement compris, est de 0 dollar, et l’appli Flickr permet de gérer les photos depuis le téléphone. J’apprécie aussi de ne jamais avoir à toucher à un vrai serveur grâce à Netlify
  • Je serais curieux d’avoir ton retour sur l’expérience avec Vapor
    La méthode que j’ai utilisée récemment peut aussi aider (https://news.ycombinator.com/item?id=36592641). Utiliser Google Sheet comme source de données était simple, et cela aurait probablement été pareil en partant d’un système de fichiers de photos
  • J’envisageais justement de quitter Smugmug pour faire quelque chose dans ce genre, donc je serais curieux de voir ton portfolio ou ton code source si tu peux les partager

• Ça ne me semble pas vraiment « simple », mais plutôt simpliste. On peut faire un site relativement simple en ne faisant presque rien et en rognant sur les angles
  Rien qu’en prenant le dark mode, pratiquement la seule fonctionnalité non triviale visible sur cette page, il est géré par du JS chargé en différé, ce qui provoque un flash blanc inévitable à chaque chargement de page. Pour bien faire, il faudrait une approche par classe CSS sur le body, et une solution qui ne fonctionne pas n’a pas d’intérêt, qu’elle soit simple ou complexe
  De plus, importer tout un interpréteur « hyperscript » personnalisé comme https://hyperscript.org/ pour trois lignes de JS concernant localStorage et le réglage du dark mode va à l’encontre de l’idée selon laquelle « la simplicité est l’ultime sophistication ». Charger une bibliothèque non mise en cache de 96 Ko uniquement pour ça est étrange, et je me demande aussi si c’est pour cela que le HTML ne passe pas la validation
  Enfin, un interrupteur binaire est une mauvaise implémentation du dark mode, car il ignore les réglages système/navigateur. Même si le dark mode est activé dans l’OS du smartphone, le site restera en mode clair tant que l’utilisateur ne l’active pas manuellement, et il ne respecte pas non plus les réglages système qui changent selon l’heure ou la lumière ambiante. localStorage peut expirer et les appareils changent, donc il faut refaire le réglage encore et encore, et il est fort possible que les utilisateurs ne partagent pas l’idée de « simplicité » du développeur

  • Si l’objectif est d’avoir un site aussi simple que possible, alors il ne devrait pas y avoir de dark mode du tout. Il existait déjà des sites simples et agréables à lire dans les années 90, et avant la mode du dark mode, le mode clair suffisait très bien
    Dès qu’on prend en compte les réglages système/navigateur, les bascules selon le fuseau horaire ou la lumière ambiante, on ajoute une complexité qui entre en conflit avec la philosophie du site simple. Il vaudrait mieux retirer le dark mode, et même HN est toujours en mode clair sans que cela pose de vrai problème la nuit
  • Je suis d’accord pour dire que l’approche avec JS chargé en différé est mauvaise, mais l’approche par media queries est elle aussi délicate
    En général, on veut respecter prefers-color-scheme tout en proposant un bouton de bascule, et on veut aussi donner la priorité au choix de l’utilisateur s’il a déjà sélectionné un mode sur le site. Dans ce cas, on a quand même besoin de JS et de localStorage
    Mon approche préférée consiste à mettre un style inline avec body {visibility: hidden; opacity: 0;}. On conserve la page précédente, puis au moment de DOMContentLoaded, on vérifie prefers-color-scheme et localStorage, on applique la bonne classe au body, puis on laisse la page s’afficher
  • En lisant, je me suis dit : « excellente analyse », puis j’ai vu l’auteur et j’ai compris. Pour le dire à l’OP, il s’agit de l’auteur de https://gwern.net ; ce site a eu une grande influence sur le design de nombreux blogs techniques et sites personnels, et il regorge d’idées originales et brillantes
    Mon site respecte les thèmes clair/sombre via CSS et n’a pas de bascule manuelle. Je me fixe comme objectif personnel d’avoir un site pur HTML/CSS sans JS, et je pense que les réglages clair/sombre doivent respecter les préférences de l’utilisateur. S’il faut une bascule, elle devrait se trouver dans la barre d’outils du navigateur, pas sur le site
    Si /u/gwern lit ceci, mon site https://daveon.design/ est influencé par le design de gwern et par Tufte.css. Il y a aussi un mélange de publications anciennes, de manuscrits et de goûts personnels, mais gwern a été pour moi l’exemple clé qui m’a d’abord inspiré sur ce à quoi peut ressembler un site personnel moderne et épuré, et sur ce qu’il peut contenir
  • Sur Firefox, Chrome et Safari sur Mac, ainsi que sur Firefox et Chrome sur Android, je ne vois pas de flash blanc. Au premier chargement, au rechargement, et lors du passage sombre/clair, tout semble simplement bien fonctionner
  • C’est un point juste. Malheureusement, une façon de penser cassée mais donnant une impression de simplicité est tout aussi répandue qu’une approche cassée et hypertrophiée

• À vrai dire, actuellement, SvelteKit + Skeleton est vraiment impressionnant en termes de vitesse pour créer un prototype exploitable
  Même sans bien connaître Svelte, si l’on comprend le routage basé sur les fichiers, le reste est presque entièrement du HTML jusqu’au moment où l’on en a besoin, Tailwind est inclus par défaut, et les thèmes restent globalement très proches du vanilla
  Ces derniers mois, j’ai essayé Astro, Lit, Next.js, les templates intégrés de Go, pug, Eleventy, etc., et jusqu’ici c’est cette combinaison que je préfère sur presque tous les points

  • SvelteKit est excellent, mais j’ai du mal à adhérer à Skeleton. Au début, ça paraît productif et sûr, mais il y a beaucoup de pièges, et dès qu’un aspect ne plaît pas, la personnalisation devient difficile
    Rien qu’en regardant le propre site de Skeleton https://www.skeleton.dev/docs/get-started, appuyer sur Page Down ne fait pas défiler la page, survoler la barre de navigation avec la souris bloque aussi le défilement, et à l’impression seule la partie visible à l’écran est tronquée. J’ai signalé ce problème, mais ce n’est toujours pas une grande priorité, alors même que beaucoup de sites utilisent ce modèle de composants
    Skeleton semble considérer qu’inverser les couleurs du thème sombre suffit à produire un bon thème clair, mais en pratique ce n’est pas le cas. DaisyUI est plus mature, plus performant, plus largement utilisé et prend l’accessibilité au sérieux. C’est aussi impressionnant de voir ce qu’il accomplit uniquement avec des animations CSS, sans JS, tout en réglant les parties difficiles du HTML/CSS et en laissant écrire soi-même les parties simples en Svelte. Sa dépendance à Svelte est aussi faible, donc il est facile de réutiliser le HTML de DaisyUI dans d’autres frameworks
  • D’accord. C’est un framework, mais il permet facilement de générer un site statique qui fonctionne bien même avec le JS désactivé, on peut l’utiliser sans connaître Svelte, et utiliser Svelte si nécessaire
    Tailwind fonctionne immédiatement et le déploiement vers un service comme Netlify est très simple. À l’heure actuelle, c’est selon moi le meilleur générateur de sites statiques, et bien plus simple que l’approche décrite dans l’article
  • En tant qu’amateur de minimalisme, j’ai utilisé Astro et SvelteKit, et SvelteKit me donne l’impression d’être une couche très légère au-dessus de Svelte, qui est déjà une bibliothèque de composants très légère
    Avec +page.ts et la configuration adéquate, on peut aussi créer un site web statique, puis évoluer vers une application multipage ou monopage
  • On voit peu d’exemples du type « si vous saisissez ceci, vous obtenez cette page finale ». Ce serait bien d’avoir des exemples qu’on puisse simplement consulter avant d’installer quoi que ce soit et de suivre toute la procédure
  • Bonne recommandation. J’aimerais aussi en entendre davantage sur l’expérience avec d’autres frameworks web, et je me demande si Flutter a aussi été essayé

• Mon Dieu, construire un site web en HTML et CSS, ça semble complètement fou
  Blague à part, à part pour les templates, j’utilise la même stack. Quand on n’est pas développeur web, on comprend mal l’intérêt des frameworks CSS, et les faire soi-même est bien plus simple. J’ai aussi essayé Hugo comme générateur de site, mais ça ne m’a fait gagner aucun temps
  Il y a quelques mois, pour améliorer mon niveau en CSS, j’ai reproduit les sites web de quelques entreprises, et il était possible d’en recréer entièrement l’apparence avec seulement du HTML et du CSS. En revanche, leurs vrais sites web ne s’affichaient même pas du tout quand on désactivait le JS
  Nous continuons à empiler des frameworks sur des frameworks, de nouveaux langages, de nouveaux outils, et la plupart ne font qu’augmenter la complexité et la charge de travail de la génération suivante. Les 5 % de sites web qui ont réellement besoin de ce genre de choses sont l’exception
  J’ai aussi trouvé intéressant qu’il s’agisse d’un site vendant un vrai service, et je me demandais quelle était sa gamme de prix

  • Faire le design, puis le garder cohérent, me paraît extrêmement difficile. C’est pour ça que du CSS prédéfini est utile ; sinon, le résultat a vite l’air bâclé
  • Je suis globalement d’accord, mais j’ai tout de même utilisé Astro avec pas mal de succès

• À mon avis, la manière la plus minimaliste et la plus productive, c’est simplement d’utiliser PHP. Ce langage a été conçu à l’origine pour ce genre d’usage
  Pour un site simple, pas besoin de composer ni de logique de routage : il suffit de créer séparément les fichiers header/footer/navigation et de les inclure dans chaque page

  • Même sans bibliothèque, on peut faire un routeur et une mise en page en une centaine de lignes. Le routeur se contente de vérifier l’existence du fichier, et pour la mise en page il suffit d’inclure header.php, pagename.php et footer.php. Pour un site simple, je fais comme ça, et c’est très simple et rapide
  • Même sans PHP, n’importe quel langage de script côté serveur convient. L’essentiel, c’est la capacité à nommer, stocker et recharger des données et des blocs de code pour pouvoir refactorer le site
    Si le HTML pouvait insérer du HTML externe comme le font le CSS ou le JS, même cela serait en grande partie inutile. J’aimerais simplement qu’on nous laisse le faire librement
  • Si l’on veut de la simplicité, il est difficile de battre PHP + HTML. Pour quelque chose de plus gros qu’un script à usage unique, je n’irais pas jusqu’à vouloir quelque chose d’aussi simple et je mettrais généralement au moins une bibliothèque de templates séparée, mais c’est bien d’avoir cette possibilité
  • Je suis d’accord sur l’idée générale, mais avec seulement 5 à 20 heures, on peut créer un générateur de site personnalisé efficace basé sur Eleventy et le déployer gratuitement sur Netlify
    On modifie quelque chose, on fait un git commit/push, et en moins de 30 secondes les changements sont répercutés dans le monde entier. C’est franchement excellent et ça ne nécessite pas d’hébergement serveur séparé
  • Il existe beaucoup de frameworks simples, mais dès qu’on en ajoute quelques-uns de plus, on revient vite au gonflement habituel

• Cela me fait penser à la phrase : « aussi simple que possible, mais pas plus simple ». Ce n’est probablement pas d’Albert Einstein
  Du HTML + CSS pur, avec le CSS intégré dans chaque balise HTML ou dans la page elle-même, c’est acceptable pour démarrer. Dès qu’on a deux pages, on finit par extraire le CSS dans un fichier séparé
  Mais dès qu’on commence à créer un site avec plusieurs pages au même format, on a besoin d’un système de templates avec des include et d’un générateur de pages statiques
  Si les pages sont pilotées par des données, il faut un générateur de site programmable qui ingère ces données et produit les pages ; et si ces données sont « en temps réel », il faut générer les pages pour chaque vue, ce qui fait basculer au minimum dans le territoire de PHP, voire dans celui des frameworks web modernes avec un serveur en cours d’exécution
  J’ai récemment créé bénévolement un site lié à un hobby. C’est un site de promotion de danse et d’événements, et la propriétaire est une prof de danse peu familière avec la technique. J’ai généré un site statique avec Eleventy(https://www.11ty.dev/) sur l’offre gratuite de Netlify, en y ajoutant du code de build personnalisé pour récupérer des données depuis Google Sheet afin qu’elle puisse définir les événements à venir
  Cela m’a pris une dizaine d’heures à construire, mais maintenant ça tourne très bien sans coûts d’exploitation ou d’administration. J’ai découvert qu’il existe un sweet spot très puissant entre une configuration totalement minimale et le niveau Rails/Phoenix/Django

  • Même l’OP finit par utiliser deux bibliothèques : les templates Jinja et le styling Tailwind. C’est un juste milieu raisonnable entre le HTML/CSS pur et Django/Phoenix/Rails + Angular/React/Vue
  • En général, je refactorise à la deuxième occurrence, mais j’ai aussi entendu dire que pour DRY, attendre la troisième offre de meilleures chances d’atteindre le seuil de rentabilité entre effort et gain
    Cela dit, le nombre de pages d’un site dépassera presque certainement 3, donc ce n’est pas tout à fait la même chose que la probabilité qu’un bloc de code générique soit réutilisé au moins trois fois
  • Je me demande si tu l’as publié en open source ou si tu as trouvé un projet similaire
    Je me demande aussi si l’architecture consiste à appeler l’API Google Sheets côté client pour remplir les données, et si oui, s’il y a une couche de cache ou si chaque client récupère une nouvelle copie à chaque fois

• Le débat sur les frameworks et la complexité devient franchement lassant
  Quand un client demande un CMS sur mesure avec un workflow de publication à plusieurs étapes, l’internationalisation et l’accessibilité pour la conformité réglementaire, il faut des outils puissants pour le livrer dans les délais attendus. Dans l’entreprise, il y a beaucoup de clients comme ça, d’où une forte demande pour ces outils. Si vous n’avez fait que du B2C, ça peut surprendre, mais c’est la partie immergée de l’iceberg dans l’industrie tech
  C’est vrai qu’un blog statique n’a pas besoin d’une configuration Next.js compliquée ni d’une toolchain Vite. Mais les gens qui discutent sérieusement de ces outils ne parlent pas de créer un simple blog statique. L’exemple réduit d’un tutoriel peut être un blog, mais le vrai problème est différent
  Donc j’aimerais qu’on se calme un peu sur la haine des frameworks. Si vous avez une bonne idée pour créer simplement des sites web, publiez un tutoriel ; si elle est convaincante, des gens l’utiliseront là où c’est approprié. Mais évitons d’argumenter contre un ennemi vague du genre « toolchains épicées et frameworks à la mode »

  • Beaucoup de ceux qui participent à cette discussion n’ont jamais directement traité des problèmes pour lesquels ces outils sont utiles. Ils sont peut-être ingénieurs, mais sans toucher au front-end, donc sans connaissances au-delà des bases ; ou étudiants en informatique qui pensent tout savoir du développement front-end parce qu’ils ont monté un blog perso avec Jekyll
    Ou bien ils croient tout savoir parce qu’ils ont longtemps développé une application métier interne avec un nombre d’utilisateurs à deux chiffres et sans exigences UX. Ce genre de jugements peu informés tire la discussion vers le bas
  • Si on fait quelque chose de complexe sans utiliser de framework, on finit par construire un autre framework soi-même
    Sauf que cette fois, la personne qui héritera du code n’aura ni mises à jour, ni aide facile sur Stack Overflow
  • D’accord. Même du point de vue de quelqu’un qui n’aime pas la complexité introduite par les frameworks
    Je ne vois pas pourquoi on penserait qu’il ne faut pas utiliser des outils différents selon les tâches. Il y a des moments où un framework n’est pas nécessaire, mais d’après mon expérience, ils sont rares, sauf si on construit quelque chose de très simple qui change peu souvent
    Dans un contexte avec une équipe et des clients, j’ai du mal à imaginer comment un site basé sur des « outils simples » fonctionnerait en pratique, et ce n’est pas une critique : je veux dire que je ne le sais vraiment pas

• Même cette approche me paraît déjà trop compliquée
  J’écris les articles en Gemtext, c’est-à-dire du Markdown pour Gemini, puis j’ai créé un script Python qui les convertit en HTML et génère une page d’index
  Le CSS ne fait que 42 lignes, donc je l’ai mis directement dans chaque page, et j’ai même calculé que le coût d’ajouter 42 lignes par fichier ne dépasserait jamais celui d’une deuxième requête HTTP
  C’était bien plus simple que prévu, sans bibliothèque Python ni template. La partie la plus difficile a été de générer les emails à envoyer à la mailing list. J’ai passé des mois à analyser divers frameworks et générateurs de sites statiques, et des semaines à chercher un CSS correct
  D’après l’historique git, j’ai terminé ça après deux semaines de bidouillage, y compris l’import de 18 ans d’historique WordPress. Comme c’est du Python pur, je n’ai rien eu de nouveau à apprendre, et s’il y a un bug, je peux facilement le corriger ou le modifier. C’est mon code
  Les informaticiens ont complètement oublié qu’au lieu d’essayer de tout réutiliser, on peut simplement coder une solution ad hoc. Le temps passé à apprendre et à adapter dépasse celui de construire soi-même
  Code : https://git.sr.ht/~lioploum/ploum.net
  Site : https://ploum.net

  • Des emails ? Un script Python ? Git ? Quelle magnifique machine de Rube Goldberg
    Mon site est servi depuis un processeur 6502 taillé dans du balsa en 2003, collé à un câble Ethernet à l’époxy. Quand je veux le modifier, je chauffe l’EPROM au sèche-cheveux pour faire basculer les bits voulus. Pas de templates, pas de code, pas de bloat
  • Excellent blog. Je l’ai ouvert juste pour voir le design, et j’ai fini par lire quatre articles d’affilée
    En faisant défiler vers le bas, la façon dont il retrace l’histoire des technologies provoque une vraie nostalgie

• Sauf mauvaise compréhension de ma part, cela ne paraît pas très différent d’un générateur de site statique moyen. Ça ressemble à la différence entre générer des fichiers HTML avec des templates Jinja basés sur Python et Jekyll, qui génère des fichiers HTML/Markdown avec des templates Liquid basés sur Ruby

  • Au lieu d’utiliser un framework existant, il a fait le sien. Et ce n’est pas grave. Créer des choses, c’est amusant
  • J’ai eu la même impression. Si l’objectif était la simplicité, construire directement un générateur sur mesure au lieu d’utiliser un générateur de site statique existant semble être un choix étrange
    Un site PHP avec des includes, ou un générateur de site statique existant, me semblerait bien plus logique

• Je ne comprends pas. En gros, il ne voulait pas d’un générateur de site statique, donc il a écrit lui-même un générateur de site statique