Le paradoxe des sites statiques

• Même pour des sites simples comme un blog personnel ou une page de contact, les utilisateurs ordinaires restent sur des CMS comme WordPress, tandis que les sites HTML statiques sont paradoxalement plus faciles à exploiter pour des ingénieurs spécialisés
• Pour créer soi-même un site statique, il faut gérer plusieurs étapes intermédiaires : acheter un domaine, choisir un hébergement, configurer le DNS, choisir un SSG et mettre en place un pipeline de déploiement
• Les ingénieurs utilisent GitHub Pages ou Cloudflare Pages pour bénéficier d’un hébergement gratuit et d’un domaine personnalisé, alors que les utilisateurs ordinaires finissent par dépendre de services plus coûteux et plus lourds, même quand un site statique suffirait
• SuperHTML est présenté comme le premier serveur de langage HTML à remonter des diagnostics aux utilisateurs ; les outils de diagnostic existants sont généralement liés à un framework frontend précis, ce qui les rend difficiles à utiliser avec du HTML vanilla uniquement
• Si l’on ne parvient pas à rendre le développement web simple plus accessible, le web s’éloignera des non-spécialistes et les utilisateurs ordinaires seront repoussés vers des espaces fermés comme les réseaux sociaux

---

Le paradoxe d’un site statique devenu plus difficile

• Deux exemples de sites web personnels sont mis en contraste
  • L’un est un CMS complexe écrit en PHP, qui nécessite un serveur web, plusieurs workers, un cache Redis et une base de données SQL
  • Son frontend se charge aussi sous forme de Single Page Application, demande le contenu au format JSON, puis le reconstruit côté client
  • L’autre se compose de fichiers HTML statiques et d’un ou deux fichiers CSS, sans JavaScript
• À première vue, on pourrait penser que les utilisateurs ordinaires utilisent des sites statiques simples et que les ingénieurs spécialisés utilisent des architectures complexes, mais la réalité est presque inverse
• Pour exploiter eux-mêmes un site statique, les utilisateurs ordinaires doivent franchir plusieurs étapes
  • Acheter un domaine
  • Trouver une plateforme d’hébergement
  • Configurer le DNS
  • Choisir ou créer un SSG
  • Mettre en place un pipeline de déploiement
• À l’inverse, les ingénieurs logiciels peuvent profiter d’un hébergement gratuit et de la prise en charge d’un domaine personnalisé via GitHub Pages, Cloudflare Pages, etc.
• Résultat : même dans les 99 % de cas où un site web statique suffirait, les utilisateurs ordinaires se retrouvent enfermés dans des solutions complexes, plus coûteuses et plus consommatrices de ressources de calcul

Le besoin d’outils qui simplifient le web simple

• Une présentation à SquiggleConf à Boston portait sur l’expérience de mise en œuvre d’un serveur de langage HTML, et sa conclusion débouchait sur la question de l’accessibilité du web
• SuperHTML est présenté comme le premier serveur de langage HTML à remonter des diagnostics aux utilisateurs, et l’article associé est arrivé en une de Hacker News
• Les linters existent et les diagnostics dans les éditeurs sont possibles, mais ils sont généralement liés à un framework frontend particulier
  • Cela pousse les utilisateurs à choisir un framework, même lorsqu’ils n’ont pas réellement besoin de cette complexité
• Le web n’appartient pas qu’aux ingénieurs logiciels, et plus on le rend complexe, plus les utilisateurs ordinaires sont repoussés dans les enclos que sont les réseaux sociaux
• Les startups et les big tech n’ont pas les incitations économiques nécessaires pour résoudre ce problème à la place des autres ; il faut donc rendre le web simple plus facile à créer

[GN⁺]

Avis sur Hacker News

• J’ai eu beaucoup d’expériences amères à essayer de convaincre des responsables marketing d’abandonner WordPress pour utiliser un site statique.
  Au fond, le point essentiel, c’est la facilité d’édition. Un site WordPress est optimisé pour les rédacteurs, pas pour l’hébergement, les responsables techniques, la comptabilité ni les lecteurs ; et ce sont les personnes qui éditent le site qui finissent par décider de la façon dont il est implémenté.
  Si on leur donne le choix entre un site qui se rend en moins de 100 ms, totalement sûr, avec des coûts d’hébergement nuls, mais qui nécessite des fichiers Markdown et un peu de déploiement Git, et WordPress, lent, coûteux, vulnérable et demandant une maintenance constante, mais offrant une bonne expérience d’édition, ils choisiront toujours WordPress.
  Je me demande toujours pourquoi ces personnes ont le pouvoir de choisir, mais après avoir répété la même expérience plusieurs fois, le résultat a toujours été le même.

  • Ça paraît assez hostile aux utilisateurs. Le « travail à faire » des marketeurs consiste à créer du contenu et à le mettre devant le public visé ; il est donc normal que l’expérience d’édition passe avant la sécurité ou la vitesse de rendu.
    Je ne vois pas ce qu’il y a d’étrange à choisir WordPress plutôt que d’apprendre un éditeur de texte et Git. L’expérience devrait consister à comparer WordPress avec un outil qui offre une bonne expérience d’édition tout en générant, en arrière-plan, un site statique et un déploiement Git. Là, des exigences secondaires comme la sécurité et la vitesse pourraient commencer à compter.
  • Tu as donné toi-même la réponse. La technologie proposée ne répondait pas à leurs besoins. Un site marketing doit effectivement être optimisé pour les rédacteurs ; ce n’est pas un échec des responsables marketing, mais des développeurs.
  • C’est exactement le point clé. Même moi, en tant qu’ingénieur, j’ai quitté WordPress il y a quelques années et j’utilise maintenant Ghost, mais WordPress donne un sentiment de contrôle : il suffit de chercher « online store » pour trouver une centaine de plugins, dont WooCommerce, qui ressemblent à des plateformes e-commerce complètes.
    Plus qu’un blog, c’est presque une application personnalisée que des non-spécialistes peuvent bricoler selon les fonctionnalités voulues, simplement en cliquant et en glissant-déposant. Pas besoin de coder, jusqu’au jour où le site se fait pirater ou où il faut une fonctionnalité sur mesure nécessitant un vrai ingénieur.
    Avec Hugo, Ghost, etc., on en arrive vite à « il faut une autre plateforme pour ça », et cette plateforme devient Shopify, un système comptable, un plugin de réseau social/d’adhésion, un tableau d’offres d’emploi, etc. WordPress est devenu quelque chose que l’on peut transformer en n’importe quoi.
    Quand quelqu’un disait à un consultant ce qu’il voulait, la réponse était : « Je vais vous configurer ça avec WordPress » ; et comme tout le monde utilisait WordPress, il était facile de trouver quelqu’un pour résoudre un problème, modifier légèrement un plugin ou ajouter un hook d’envoi d’e-mails. L’ère des consultants PHP a construit la domination de WordPress.
    Le problème, c’est que la plupart de ces solutions, y compris payantes, ne sont pas de vraies solutions complètes. Dès qu’on commence à les utiliser, on se rend vite compte que WordPress impose des contraintes absurdes. Impossible de concevoir une boutique en ligne en dehors du désastre de performance de son système entités/métadonnées, où une requête de taille raisonnable prend 5 secondes et génère 50 requêtes secondaires non optimisées. Certains plugins contournent même WordPress en créant leurs propres tables de base de données.
    En dehors du blog, l’architecture de WordPress est catastrophique, mais il est utilisé comme outil pour tout. Les autres CMS ne font pas ça, et c’est pour cela que les gens ne les utilisent pas.
  • Tu mélanges deux fonctions différentes. WordPress fournit un système de gestion de contenu que les utilisateurs apprécient ; la façon dont ce contenu est servi peut être facilement séparée.
    Le contenu peut toujours être distribué via un CDN sous forme de fichiers statiques générés. Un site statique n’implique pas forcément Markdown et Git.
  • Ils ont le pouvoir de choisir parce que ce sont eux qui s’en servent tous les jours. L’objectif est de publier rapidement du contenu, et ce contenu est très varié : cela va de tableaux qui passent mal en Markdown à des images nécessitant un hébergement séparé.
    J’ai longtemps cherché une chaîne d’outils permettant même à un stagiaire sans aucune expérience technique de déployer des modifications sans se prendre les pieds dans les détails techniques, mais je ne l’ai toujours pas trouvée.
    Ce qui s’en rapproche le plus, c’est de mettre un générateur de site statique au-dessus d’un CMS headless, mais honnêtement, tout ça est assez mauvais.

• En 2016, quand je travaillais dans une agence qui créait des sites vitrine pour des entreprises locales, un client nous a demandé d’ajouter un petit iframe pour un système de réservation sur le site qu’ils avaient créé. Ce qu’ils nous ont envoyé était un document Word ; il s’est avéré qu’ils l’exportaient en HTML et le mettaient sur un hébergement mutualisé bon marché.
  Pour eux, ça fonctionnait très bien. Ils pouvaient garder leur menu en ligne toujours à jour, parce qu’il suffisait de l’exporter depuis le document Word qui servait déjà à produire le menu imprimé. À l’époque, en interne, on s’en était un peu moqués, mais avec le recul je m’en veux. Quand on a un million de choses plus importantes à faire, comme gérer un restaurant, c’est en fait une méthode géniale.
  Créer un site statique reste plus simple. Le problème, c’est que les outils d’édition qui génèrent du HTML sont aujourd’hui assez médiocres, ou bien, même quand ils sont corrects, ils imposent un processus côté serveur pour servir le site.

  • J’aime cette façon dont les entreprises résolvent les problèmes. Si ça marche, ça marche.
    Mon travail n’est pas de me moquer en disant « on pourrait faire mieux », mais d’améliorer leur solution, de faire en sorte que celle que je leur propose fonctionne au moins aussi bien, si possible mieux, que leur méthode existante, sans compromettre le succès qu’ils ont déjà obtenu.
    Beaucoup de développeurs n’aiment pas l’admettre, mais ce genre de solutions web temporaires fonctionne souvent mieux que diverses stratégies qu’un développeur web expérimenté mettrait en œuvre seul.
    Ce qui compte, c’est ce que l’entreprise propose, et la manière dont elle noue des relations et interagit avec ses clients. Parfois, exporter un document Word en HTML suffit. La technologie peut apporter des améliorations, mais la vraie magie est chez les personnes qui font tourner l’activité.
    Trouver comment améliorer ce genre de solution peut, en réalité, être assez difficile. On peut créer un meilleur site web et le déployer sur une infrastructure sophistiquée, mais au final, les clients l’apprécient-ils davantage ? L’activité s’en porte-t-elle mieux ? Ce point peut être tout sauf trivial.
  • Cela fait longtemps que je regrette la disparition de FrontPage. On se moquait du HTML atroce qu’il générait, mais c’était aussi un programme qui permettait à des commerçants ou à des particuliers ordinaires de mettre à jour un petit site web peu coûteux, sans se soucier de la sécurité tant qu’ils choisissaient un bon mot de passe.
    Cela fait des années que je cherche une bonne alternative, qui produise un HTML plus correct que l’export HTML de Word et offre davantage d’options.
  • Le menu d’un restaurant où je suis allé cet été à CDMX était un lien de prévisualisation publique d’un document Figma. Ça m’a fait énormément rire, mais j’étais aussi ravi de voir à quel point ça fonctionnait bien.
    J’aime ce genre de choses. Il y a aussi beaucoup de sites en un seul fichier HTML créés avec Vue template, des sites publiés sous forme de documents Notion publics, ou encore des bibliothèques de photos iCloud intégrées. C’est étonnant de voir à quel point il est devenu simple et largement possible de simplement relier des choses entre elles, et à quel point on complique souvent les choses en essayant de tout créer soi-même à partir de zéro.
    Quand je manque de temps, j’aime aussi des outils comme mmm.page pour bricoler rapidement de petits microsites ou des sites ponctuels. Explorer ce genre d’outils est amusant.
  • Pour un client, j’ai créé une « application de données » qui fait toutes sortes de choses sophistiquées : gestion des métadonnées, contrôles qualité, etc.
    Mais les « documents » de certaines pages sont simplement des ensembles de tableaux avec des dates et du texte, que le client gère lui-même. La solution à laquelle nous sommes finalement arrivés était similaire : il met les tableaux dans un document Word et nous l’envoie, puis nous l’exportons en HTML/CSS et l’insérons au bon endroit.
    Ce n’est ni élégant ni scalable, mais pour cet usage précis, c’est de loin la méthode la plus simple.
  • Juste après l’invasion de l’Ukraine par la Russie, la réponse humanitaire allemande a elle aussi fonctionné de cette façon, jusqu’à ce que les institutions officielles rattrapent leur retard quelques jours à quelques semaines plus tard. Notion, Telegram, WhatsApp et Google Docs ont sauvé la situation.
    C’était merveilleux à l’époque, et ça l’est toujours aujourd’hui. Discrètement, nous avons réalisé le rêve d’apporter l’informatique à tout le monde.

• Nous vivons ce problème de plein fouet à Asheville en ce moment. Même quand le service mobile est à peine revenu, tout le monde utilisait une 3G médiocre qui se coupait sans cesse, et aucun des sites web censés fournir des informations de survie de base ne se chargeait.
  Des gens bien ont créé un site d’actualité en texte seul, et aujourd’hui j’ai vu qu’un site bas débit avait aussi été mis en place sur le site du comté de Buncombe ; mais en l’ouvrant, il y avait toujours 130 Ko de CSS Bootstrap et 50 Ko de jQuery qui bloquaient le rendu.
  C’est formidable que des gens fassent ce genre de choses, mais les habitants en avaient besoin il y a une semaine et demie. Maintenant, on a déjà compris où trouver de l’eau, de la nourriture, de l’eau non potable, etc. Voir la technologie échouer aussi gravement pendant cet épisode m’a ouvert les yeux, de façon déprimante.

  • Ce n’est pas aussi catastrophique, mais lors des coupures de courant dans mon quartier, il ne reste généralement que le téléphone mobile, avec un mauvais signal. Les équipements Internet par câble n’ont pas d’alimentation de secours.
    La carte des coupures de la compagnie d’électricité est cachée derrière une connexion, et elle est rendue avec de jolies fonctions de clustering et d’interface qui la rendent déjà lente même avec une bonne connexion. Donc même vérifier l’état ou signaler une coupure prend un temps considérable.
    On peut aussi appeler la compagnie d’électricité, mais ils ont choisi une navigation vocale au lieu de menus par tonalités de clavier, et elle reconnaît mal la voix déformée par une mauvaise connexion 4G ou 2G.
  • Ce genre de situation me donne envie de repasser une licence de radioamateur. Dans une catastrophe comme celle qui a touché non seulement Asheville mais une zone bien plus vaste de l’ouest de la Caroline du Nord, je ne veux pas dépendre de systèmes basés sur Internet.
    Il faut de grandes longueurs d’onde et une faible puissance. Mais l’accessibilité est très faible, et je ne sais pas vraiment si c’est pour de bonnes raisons.
    Les communications ont été coupées de Black Mountain jusqu’aux frontières du Tennessee et de la Géorgie. Je me demande si beaucoup de gens retrouvent même une médiocre 3G. Tout ce que je sais, c’est qu’il a été difficile de rester en contact avec les personnes que je connais là-bas.
  • Il y a un lien vers le site d’actualité en texte seul ?
  • J’ai utilisé toutes sortes de mauvaises connexions Internet pendant longtemps, donc ce genre de situation m’est familier. Une trop grande partie d’Internet est conçue en supposant un ordinateur rapide, une connexion rapide et un excellent écran.
    Une partie de mon meilleur travail a été faite sur un MacBook 12 pouces connecté à un Wi-Fi d’hôtel instable. C’est pour ça que je fais très attention à la vitesse des pages.
  • J’habite à Sylva, à environ 45 minutes d’Asheville, et avec le service mobile il était vraiment difficile d’obtenir des informations utiles sur son téléphone. Sans Starlink, je n’aurais rien su de beaucoup de choses pendant au moins une semaine.
    Si je devais résumer la souffrance de cette catastrophe en une phrase, ce serait l’effondrement de la communication sous toutes ses formes.

• Je souscris pleinement à l’idée que « le Web n’appartient pas seulement aux ingénieurs logiciel. Plus nous rendons le Web complexe, plus nous poussons les utilisateurs ordinaires dans l’enclos que nous appelons les réseaux sociaux »
  Il existe aussi un podcast lié à la récente conférence Squiggle Conf d’où vient cette citation : https://changelog.com/jsparty/339

• Avec le temps, les fonctionnalités que les gens attendent d’un « site Web de base » ont beaucoup augmenté
  Même moi, qui suis programmeur, je suis tombé plusieurs fois dans le piège des générateurs de sites statiques
  Quand je lance un projet perso avec un générateur de site statique et que, dès que je veux ajouter une petite fonctionnalité, je me retrouve à regretter de ne pas être simplement parti sur une petite appli Rails ou PHP, c’est agaçant
  Aujourd’hui, quand j’ai besoin d’un site statique, je commence simplement par un dossier de fichiers HTML. Le chemin entre l’idée et l’exécution est beaucoup moins compliqué et plus rapide, sans discussions théoriques ni procrastination autour des outils
  Je suis assez à l’aise avec le fait d’écrire directement du HTML et du CSS, mais je ne le recommanderais pas à tout le monde
  Autre point appréciable : si l’on décide plus tard de « s’échapper » vers Rails, il suffit de copier le dossier de fichiers HTML dans le dossier public/ de Rails. Le chemin de montée en gamme est plutôt simple

  • Il se peut aussi que vous n’ayez pas encore trouvé le générateur de site statique adapté à vos besoins
    Côté Ruby, Jekyll est le plus connu, mais il est conçu pour un cas d’usage précis : écrire un blog en Markdown ou dans un autre langage de balisage léger. On peut le forcer à faire autre chose, mais comme générateur de site statique généraliste, il n’est pas très confortable
    Si vous voulez quelque chose de facile à copier-coller dans Rails, middleman, un générateur de site statique basé sur Rack, est un bon choix. On peut l’écrire dès le départ avec erb/haml et ActiveSupport
    Si vous voulez conserver la simplicité de l’écriture manuelle du HTML et du CSS tout en ajoutant seulement des commodités comme les include, les templates partiels ou les helpers de liens, nanoc est un générateur de site statique progressif assez correct. Commencez avec du HTML/CSS ordinaire, puis ajoutez des fonctionnalités uniquement quand vous en avez besoin
  • Il est vrai qu’il est difficile d’en discuter sans exemples. J’ai commencé à utiliser Pelican il y a plus de dix ans et j’en suis toujours satisfait
    Il m’arrive d’écrire du code pour personnaliser son comportement, mais seulement une fois toutes les quelques années. C’est simple et ça fonctionne tout simplement bien
    Il y a des choses qui me manquent dans les sites dynamiques, mais je ne vois pas vraiment en quoi un simple dossier de fichiers HTML serait meilleur que Pelican
  • Je publie sur mon site personnel depuis plus de 20 ans, et le parcours a grosso modo été : HTML de base → Drupal → WordPress → HTML de base via Jekyll
    La règle fondamentale que je me suis fixée pour éviter l’inflation fonctionnelle du site a été de définir l’identité que je voulais lui donner. Je voulais en faire une archive de ce que j’ai fait, et une archive doit pouvoir tenir très longtemps. Des fichiers statiques, faciles à copier, à mettre en miroir et à faire fonctionner sur n’importe quelle plateforme d’hébergement, étaient donc adaptés
    Mettre correctement en place un site multilingue m’a pris un peu de temps, mais au moins c’est un coût payé une seule fois
  • Pour mon blog, j’utilise Hugo. Parce qu’il est facile de se concentrer sur le contenu plutôt que sur le style. C’est aussi pour cela que je n’aime pas écrire des fichiers HTML purs
    Les changements de style peuvent également devenir problématiques s’ils sont codés en dur dans les fichiers HTML
    Pour les tâches plus avancées, j’écris en Django. Pour moi, il est très facile d’y ajouter des fonctionnalités
  • Moi aussi, ces temps-ci, quand j’ai besoin d’un site statique, je commence par un dossier de fichiers HTML. J’ai envisagé d’ajouter une étape .md → .html pour le contenu, mais je n’en ai pas encore eu besoin
    J’aime aussi le fait de pouvoir consulter facilement le site avec un serveur local. Le mieux serait de pouvoir aussi le consulter via file://, mais je n’ai pas complètement résolu la structure ; j’ai donc fini avec une étape make local qui crée une copie séparée pour la consultation basée sur les fichiers

• Les sites personnels des développeurs Web ont un facteur de complexification : le développement piloté par le CV
  Certains professionnels utilisent leurs projets personnels comme terrain pour du développement piloté par le CV, en se disant que cela réduira le risque de casser les projets de leur employeur
  Par exemple, pas plus tard que ce matin, il y avait un site Web indépendant bientôt public qui utilisait un framework Web moderne et populaire, principalement pour des raisons de CV, et il n’était plus possible de le mettre à jour
  Un paquet NPM présentait un grave problème de sécurité et, au moment de le mettre à jour, NPM s’est retrouvé face à un conflit d’interdépendances impossible à résoudre automatiquement. Ironiquement, cela a empêché de pousser la mise à jour de sécurité sur le site en production
  Ce site aurait probablement pu se contenter de 5 fichiers HTML écrits à la main, d’un peu de JS inline et de 2 petits scripts Perl CGI. Il aurait alors parfaitement fonctionné encore 25 ans plus tard
  À la place, rien que la partie NodeJS comporte 129 paquets NPM, des mises à jour de sécurité fréquentes, des fragments de templates, de la configuration TS et une arborescence de fichiers source obscure faite de handlers
  Mais les professionnels n’ont pas le luxe de ne pas faire les choses d’une manière absurdement complexe. Par exemple, avoir Perl sur son CV est un coup fatal pour l’employabilité. Même les personnes qui n’écartent pas le CV à cause de la discrimination liée à l’âge vous prendront pour un idiot si vous n’avez pas fait de développement piloté par le CV

  • Je pense que la tendance est en train de changer, à mesure que les gens commencent à prendre conscience de la fragilité de la complexité
  • Je travaille à la fois sur le Web et sur des systèmes distribués, et heureusement, un site PHP ennuyeux qui lit du contenu dans des fichiers XML et JSON n’a jamais nui à mes changements de poste
  • Vous avez vraiment essayé ? Et si vous pensez que cela ne vous aide pas, rien ne vous oblige à mettre sur votre CV tout ce que vous avez fait jusqu’ici
  • Cinq fichiers HTML écrits à la main, un peu de JS inline et deux CGI Perl pourraient parfaitement fonctionner pendant 25 ans, mais, par confort, on peut aussi se situer quelque part entre les deux
    Dans mon cas, je ne m’intéresse absolument pas aux CV ni aux offres, mais je veux tout de même quelque chose de plus ergonomique que de générer du HTML depuis des templates JS/Python. Mes sites sont donc un mélange de TypeScript, Mithril, Express et de quelques bibliothèques utilitaires
    Je ne sais pas combien de paquets cela représente, et je m’en fiche. Il suffit principalement que ce que j’importe soit mature et ne produise pas une nouvelle fonctionnalité-vulnérabilité toutes les quelques minutes
    Vous n’avez pas mentionné la stack, mais il semble très probable qu’il s’agisse de React et de son écosystème « toujours en amélioration, mais jamais terminé ». Conseil non sollicité : mieux vaut ne pas croire au faux dilemme. Il y a un grand espace entre le HTML pur et le pire bourbier, et la situation dans le monde React est propre à React ; elle ne représente pas ce qui existe au-delà

• La killer app de WordPress, ce sont les commentaires. Les générateurs de sites statiques, presque par définition, ne permettent pas les commentaires, alors qu’ils sont quasiment toujours intégrés aux blogs WordPress.
  Si quelque chose comme Hugo veut vraiment décoller dans l’univers des blogs, il suffit de créer un joli thème avec commentaires. Il faut résoudre ça à grande échelle. Par exemple, avec du SQLite shardé par blog, un tiers pourrait l’héberger pour presque rien. Cela deviendrait alors une petite poule aux œufs d’or.

  • C’était vrai à l’époque des blogs, mais je pense que ça l’est beaucoup moins aujourd’hui.
    Les commentaires et discussions autour des articles se trouvent sur des communautés tierces comme Reddit, HN ou Facebook. Qui est le plus nombreux : les gens qui parcourent la liste des commentaires sous un article Substack, ou ceux qui lisent une ou deux pages de commentaires HN sur le même article ?
    S’il s’agit d’un article technique, il est presque acquis que la discussion sur HN sera de meilleure qualité qu’un fil de commentaires propre à l’article. HN attire déjà un lectorat plus large que 99,9 % de l’ensemble des blogs.
    Le principal avantage de commenter directement un billet de blog, c’est seulement que l’auteur a beaucoup plus de chances de le voir. Le passage, fugace, en page d’accueil de HN ne dure pas.
  • Hacker News et les « vrais programmeurs » continuent de sous-estimer les concepts de base des CMS. Comme ils voient ça comme une technologie peu sexy, ils considèrent que tous les problèmes autour sont des problèmes ennuyeux déjà résolus, et ne savent donc pas vraiment quels sont les vrais problèmes.
    L’écosystème WordPress est exactement l’inverse. Il regroupe des entreprises pesant des milliards de dollars, qui comprennent en profondeur ce dont les gens qui exploitent des CMS et des sites web ont besoin dans leurs petits créneaux de marché respectifs ; et ce marché représente environ 500 millions de sites web.
    La personne qui a écrit cet article est sans doute intelligente, mais clairement pas sur les usages pratiques d’un CMS. La vision du monde selon laquelle « les sites HTML statiques sont meilleurs, mais ils ne sont pas populaires à cause des méchantes entreprises » se révèle presque fausse dès qu’on a créé un ou deux sites web rémunérés.
    Un générateur de sites HTML statiques a très peu de chances de faire tout ce qu’un client souhaite. WordPress a compris depuis longtemps à quel point ce marché était vaste et varié, et a donc implémenté la prise en charge des plugins.
    Je suis 100 % d’accord pour dire que les commentaires sont l’un des usages originels qui poussent à utiliser sur le Web quelque chose de plus proche d’un CMS qu’un générateur de site statique. Mais il y a aussi un million d’autres usages.
    Avec de simples documents HTML statiques, on ne va pas très loin. Dès qu’on sort du blog minimaliste de développeur, il faut beaucoup de logique applicative pour faire ce que les vrais utilisateurs et clients veulent. On utilise donc un CMS adapté à ses besoins, puis on met en cache de manière agressive si l’on doit encaisser beaucoup de trafic. Ça fait aussi partie du travail.
    Je ne comprends vraiment pas pourquoi des développeurs qui se croient brillants veulent réinventer la roue au lieu d’apprendre un peu comment fonctionne le caching et de l’appliquer. Est-ce encore parce que c’est un « problème résolu » trop ennuyeux ?
  • La killer app de WordPress, ce ne sont pas les commentaires, mais son écosystème de plugins. Sur WordPress, il existe des plugins que même ma mère peut activer en deux clics, là où il faudrait passer tout un week-end à configurer la même chose avec Hugo.
    J’utilise moi-même Hugo, mais même si, du point de vue de l’ingénierie, son empreinte est inutilement importante, l’expérience utilisateur de WordPress est bien plus accueillante.
  • Un autre élément d’« interaction », ce sont les formulaires de contact.
    Tous les sites d’entreprise ne veulent pas de commentaires, mais ils voudront probablement un formulaire de contact. Publier une adresse e-mail est aussi une option, mais il vaut mieux gérer le pipeline de saisie.
    Sur un site statique, il faut trouver un service fiable pour traiter les soumissions et l’intégrer correctement au site. Cela ajoute une pièce mobile, peut devenir une facture séparée à payer, et ajoute un élément de plus à gérer lorsque le secteur se consolide.
  • Disqus a résolu ce problème pendant un temps, mais depuis des années il fait fuir les gens : https://en.wikipedia.org/wiki/Disqus#Criticism,_privacy,_and...
    https://hn.algolia.com/?q=%22disqus%22
    Facebook aussi proposait un système de commentaires utilisé par de nombreux sites, mais divers scandales lui ont fait perdre confiance et portée.

• Je corresponds moi aussi à ce paradoxe. J’ai réécrit mon site personnel en PHP moderne, sans framework ni base de données.
  C’est essentiellement un site statique, mais j’utilise PHP pour ajouter les en-têtes et gérer des listes comme celle des billets de blog. Ne pas être entièrement statique s’est avéré un peu plus pratique. J’écris un article, je commit, je push, et il est immédiatement en ligne. La plupart des générateurs de sites statiques me semblaient trop complexes.
  Le code d’une page individuelle ressemble grosso modo à title = "Blog Article Title";, $this->shortTitle = "Title";, $this->date = mktime(0,0,0,1,27,2024);, if ($this->mode == PageMode::Meta) return;, suivi du contenu HTML brut.
  Le routeur ajoute automatiquement l’en-tête et le pied de page du site, et si l’on ajoute un fichier _layout.php dans un dossier, on peut appliquer un niveau de mise en page supplémentaire aux pages enfants. La page de liste du blog parcourt les fichiers d’articles individuels dans le dossier pour créer l’index.
  C’est là que $this->mode == PageMode::Meta est utilisé. Le code de chaque fichier est exécuté pour obtenir les métadonnées, puis il sort avant de rendre le reste. Ce ne sera pas très scalable si le volume de contenu augmente beaucoup, mais j’ajusterai si ça devient un problème.
  Tout le code PHP de mon « framework » tient dans quatre fichiers : init.php, functions.php, Layout.php et Page.php.
  L’avantage d’être développeur, c’est qu’on peut utiliser du code plutôt que de la configuration ou des données. On peut aussi utiliser du code pour écrire du contenu plus efficacement.
  Le résultat est encore assez inachevé, mais le voici : https://www.codaris.com/

  • J’ai justement commencé l’un de mes sites web de la même manière. À 90 %, c’est du HTML, avec seulement quelques include() en PHP pour l’en-tête et certains fragments globaux.

• Si l’on considère l’expérience utilisateur du point de vue du propriétaire du site web, ce n’est pas vraiment un paradoxe. WordPress rend les choses absurdement simples, même avec une surcharge bien plus importante.
  Ça ne ressemble à un paradoxe que si on le voit comme un compromis avec le temps passé à configurer tout un tas de choses. Pour la plupart des gens, l’alternative consiste à payer quelqu’un pour créer le site web.
  Si vous créez un éditeur WYSIWYG pour Hugo et que vous permettez de tout faire en quelques clics, de l’enregistrement du domaine à la publication du site, vous pouvez gagner beaucoup d’argent.

  • N’est-ce pas ce que font des entreprises comme Netlify, Squarespace ou GitHub Pages ? Sur Netlify, on peut transférer un domaine parqué, choisir un template, et la plupart de la configuration est prise en charge ; le site est en ligne en quelques minutes, tandis que la gestion du domaine prend environ 24 heures.
    Je vois ce que tu veux dire. Même si ces entreprises s’en rapprochent, quelqu’un aurait un gros avantage s’il pouvait prendre en charge les petites étapes intermédiaires.
  • Tu ne viens pas de décrire Micro.blog[1] ?
    [1] https://micro.blog

• Le passage disant : « Quand j’ai publié SuperHTML, j’ai constaté que c’était le premier serveur de langage pour HTML à signaler des diagnostics aux utilisateurs. J’ai écrit un billet de blog, il est arrivé en une de Hacker News, et personne ne m’a corrigé, donc c’est vrai » s’explique probablement par le fait que la plupart des IDE faisaient déjà cela depuis des années, bien avant que Microsoft ne publie LSP.

  • Je pense que très peu d’éditeurs populaires disposaient d’un moyen de fournir des diagnostics pour du HTML pur. La seule exception que je connaisse est WebStorm.
    Vim, Neovim, Helix, Zed et VSCode partageaient tous la même implémentation de base, sans prise en charge des diagnostics.
    Helix prévoit d’activer SuperHTML par défaut à partir de la prochaine version : https://github.com/helix-editor/helix/pull/11609