- Contrairement à l’idée selon laquelle la différence entre sites web statiques et dynamiques se serait estompée, sur une longue échelle d’exploitation, les sites web basés sur des fichiers statiques conservent des propriétés distinctes
- La méthode de déploiement de fichiers héritée des débuts du Web et l’efficacité du service de fichiers statiques expliquent pourquoi les sites statiques ont tendance à durer
- Les sites web statiques disposent, entre le serveur web et le contenu, d’une frontière de responsabilités claire, comparable à un système de fichiers, ce qui limite ce que chaque côté doit savoir de l’autre
- Pour les sites web dynamiques, la frontière entre le serveur web et le code utilisateur est difficile à rendre petite et simple, et il est également difficile de standardiser cette frontière et son API en un seul modèle
- Le critère de distinction n’est pas la quantité de travail ni la fréquence des changements, mais l’emplacement de la frontière et ce dont chaque partie doit se soucier
Le point de départ du débat sur les sites web statiques
- There is no such thing as a static website de Wesley Aptekar-Cassels considère que la différence entre sites web statiques et dynamiques est plus faible qu’on ne le pense
- Les sites web statiques sont plus dynamiques et complexes qu’ils n’en ont l’air
- Créer et exploiter des sites web dynamiques est devenu plus facile qu’auparavant
- Chaque argument est développé de manière convaincante, mais cela ne conduit pas pour autant à la conclusion que la différence entre sites web statiques et dynamiques s’est réduite
La différence créée par la durabilité et les frontières de responsabilités
- Sur une longue échelle de temps, les contenus web basés sur des fichiers statiques ont fait preuve d’une grande durabilité
- Même si les serveurs web et les hébergeurs concrets changent, la manière de placer des fichiers statiques dans une arborescence de fichiers et de répertoires existe depuis les débuts du Web
- Servir des fichiers statiques est souvent nécessaire et efficace même pour les sites web dynamiques ; les sites qui ne contiennent que des fichiers statiques bénéficient donc des mêmes avantages
- Si l’on ne fournit que du contenu statique, on obtient un site stable et facile à maintenir en fonctionnement, ce qui, historiquement, n’a pas été le cas des sites web dynamiques
- Le cœur d’un site web statique est une frontière de responsabilités dotée d’une isolation simple et forte
- D’un côté se trouve la complexité d’un serveur web statique, qui inclut même des mises à jour dynamiques comme le renouvellement des certificats HTTPS
- De l’autre se trouvent les fichiers statiques, et entre les deux se place un système de fichiers, ou quelque chose qui y ressemble
- Ce que les deux côtés exigent l’un de l’autre est très limité
- Les sites web dynamiques ont du mal à disposer d’une frontière aussi petite et nette entre le serveur web et le code utilisateur
- Il est également peu probable qu’ils puissent être standardisés autour d’une frontière et d’une API uniques
- Le Web a, en un sens, été conçu pour servir des fichiers statiques
- Cette différence donne aux serveurs web de fichiers statiques un avantage en matière d’exploitation et de migration par rapport aux serveurs web dynamiques et à leurs environnements d’exécution
- Les serveurs web de fichiers statiques sont faciles à trouver
- Même si l’opérateur actuel arrête le service, il est facile de déplacer le site ailleurs
- Cette durabilité vaut au moins pour les sites web statiques de petite à moyenne taille pouvant tenir sur un seul serveur
- La distinction entre sites web statiques et dynamiques n’est pas floue
- Le critère n’est pas la quantité de travail nécessaire pour créer et exploiter le site, ni la quantité d’éléments qui changent régulièrement, comme le renouvellement des certificats HTTPS
- Le critère est l’endroit où se situe la frontière, et ce dont chaque côté doit se soucier
- Les sites web statiques possèdent une frontière nette qui permet de traiter les deux côtés indépendamment, tandis que les sites web dynamiques n’ont pas intrinsèquement ce type de frontière et doivent, si nécessaire, la tracer artificiellement
1 commentaires
Commentaires sur Hacker News
Je gagne ma vie avec un site de contenu, et cette année je suis passé de Craft CMS à un générateur de site statique maison
Je n’ai plus à me soucier du serveur ou du CMS, il n’y a plus de mises à jour à faire, et je me suis débarrassé de la base de données lourde et de la configuration de cache complexe. Maintenant, ce n’est plus qu’un serveur de fichiers statiques, donc c’est plus stable et ne demande presque plus de maintenance
Le meilleur, c’est qu’on peut travailler hors ligne. Il suffit d’un éditeur de texte, donc même un petit Macbook 12" paraît très rapide
Le contrôle de version est aussi très utile pour relire ou annuler des modifications, et on peut faire des rechercher/remplacer avec regex sur l’ensemble du contenu. Les fichiers texte sont faciles à manipuler
J’ai expliqué ici ce que cette transition m’a apporté et pourquoi elle fonctionne bien : https://nicolasbouliane.com/projects/ursus
Cela dit, ce serait bien que cette technologie devienne plus accessible à ceux qui ne savent pas recompiler et redéployer eux-mêmes. C’est une manière rapide et peu coûteuse de créer un site web, mais des outils existants comme Hugo supposent encore beaucoup de choses de la part de l’utilisateur, ce qui crée une barrière à l’entrée
J’ai aussi trouvé l’article agréable à lire. J’ai créé la version originale de html-to-markdown utilisée pour la migration, et ça fait plaisir de voir que c’est toujours utile
C’est rapide, il y a tout ce qu’il faut, et rien de superflu
Personnellement, j’aimerais bien une section sur les séries TV et films se déroulant dans le Berlin passé et présent, avec aussi une petite note sur le réalisme de leur représentation de Berlin
Plus de 95 % des sites web entiers auraient probablement très bien fonctionné avec 70 % du contenu populaire en cache dans la RAM, et les 30 % restants servis depuis un SSD capable de 10,000 IOPS en lecture aléatoire
À moins de retoucher sans cesse le design du site, la génération du site et du HTML devrait se faire en local, et la génération complète devrait prendre moins d’une seconde
Mais l’approche centrée sur GitHub, le contrôle de version et l’éditeur de texte reste encore trop orientée techniciens et programmeurs. Il faudrait quelque chose comme un WordPress hébergé, ou quelque chose de plus proche de l’époque Dreamweaver/Frontpage
J’aime le fait qu’on puisse aller très loin dans le détail quand on veut implémenter quelque chose de particulier. Par exemple, si je modifie un article sur mes aliases Git préférés, il peut être transformé en fichier
.bash_aliases, poussé vers GitLab et aussi répliqué sur GitHubPour les curieux, c’est ici : https://jdsalaro.com. Je n’ai pas encore détaillé la stack ni les raisons, mais je compte documenter ça progressivement
Pour l’instant, j’ai au moins écrit une antisèche Markdown pour Sphinx et Myst (https://jdsalaro.com/cheatsheet/sphinx-myst-cheat-sheet/) ainsi qu’un guide pour charger
environment.pickle(https://jdsalaro.com/howto/sphinx-load-environment-pickle/)Cela signifie aussi moins de ressources consommées, comme l’électricité, du matériel plus modeste suffisant, et surtout une meilleure sécurité. Les sites web statiques sont plus difficiles à attaquer, et les failles possibles se limitent au serveur web plutôt qu’au code du site
En général, j’utilise Hugo, qui est très riche en fonctionnalités et très abouti. J’ai même créé des sites multilingues avec
Cela peut aussi valoir le coup d’intégrer Turbo Hotwired à un site statique. Cela peut améliorer la réactivité de navigation et réduire la charge côté serveur comme côté client
Si besoin, on peut aussi intégrer Turbo à Mercure pour faire du streaming de pages en temps réel
La plus grande différence entre un site statique et un site dynamique, c’est la surface d’attaque de sécurité
Dans le pire des cas, le serveur web d’un site statique peut seulement être amené à servir un mauvais fichier, et on peut atténuer cela en ne mettant sur le serveur que des fichiers qu’il est censé servir de toute façon
Un site dynamique peut être amené à exécuter du code, à renvoyer de mauvaises données depuis une base de données accessible, et même à modifier ces données
Les compromissions de WordPress arrivent tout le temps, celles de Nginx non
Techniquement, il n’existe pas de site web qui n’exécute pas de code. Du serveur web jusqu’au pilote du système de fichiers et au système d’exploitation, tout est du code
Il est vrai que les fichiers statiques réduisent la surface d’attaque, mais il faut réfléchir en profondeur aux raisons, puis concevoir des systèmes dynamiques intelligents qui héritent des propriétés de sécurité des sites statiques
Au final, tout tourne autour des entrées et de la manière dont elles sont traitées. On peut exécuter un code aussi complexe qu’on veut, s’il n’accepte aucune entrée il n’y a rien à attaquer. Bien sûr, sans entrée on ne saurait même pas quelle page afficher, donc les sites statiques ont eux aussi des entrées. La distinction importante se situe là
Je suis d’accord pour dire que la surface d’attaque d’un site statique est plus petite, mais je pense que la raison principale est surtout que nginx est bien plus audité et évolue beaucoup plus lentement qu’une combinaison moyenne de plugins WordPress
Si vous fabriquiez vous-même un serveur web statique, sa première version aurait probablement plus de vulnérabilités qu’une installation WordPress de base
Un site statique, en théorie, pourrait ne jamais avoir besoin de mise à jour. Tant que la cible, comme la version de HTML, ne change pas, la notion même de mise à jour existe à peine
locationavec directivealiasreste une exceptionDu point de vue du développeur, la distinction est assez nette si l’on se base sur l’abstraction fournie par le web, à savoir l’hypermédia fourni au-dessus de HTTP/S
La sémantique de cette abstraction correspond à une structure où une requête avec des en-têtes et un corps arrive sur un chemin donné, et une réponse avec des en-têtes et un corps repart. Les détails réseau intermédiaires comme TLS sont masqués
En pratique, les frameworks modernes masquent encore davantage d’éléments au développeur en gérant automatiquement jusqu’aux sessions d’authentification et aux en-têtes de requête. Dans cette abstraction, la distinction standard selon laquelle « le statique ne dépend pas de la requête ou de l’état, alors que le dynamique en dépend » est propre, mais elle repose sur la sémantique fournie par l’abstraction
C’est comparable au fait que TCP fonctionne comme un protocole orienté connexion sur une infrastructure sous-jacente qui, fondamentalement, repose sur des paquets. On peut utiliser TCP pour des applications qui ont besoin d’un transfert de données en flux ou par paquets
On peut toujours prétendre que « dans la réalité, comme tout repose sur IP, il n’y a pas de distinction », mais cela revient à regarder depuis la mauvaise couche d’abstraction
Cela ne veut pas dire pour autant que l’idée principale de l’article est fausse. Les développeurs doivent toujours garder à l’esprit la dimension stateful qui se cache sous un « site web sans état », et il vaut mieux comprendre l’abstraction quelques couches plus en profondeur qu’on ne le pense nécessaire
Les sites personnels mêlent souvent statique et dynamique d’une manière un peu étrange. Le mien est majoritairement statique, mais la partie blog repose sur un rendu dynamique
Quand on accède à l’URL d’un billet de blog, un fichier Markdown est récupéré sur le disque, converti en HTML, puis cet HTML est injecté dans un template qui compose le reste de la page avec le CSS, etc.
Malgré cela, c’est rapide et efficace. Quand l’un de mes billets est monté n°1 sur HN la semaine dernière, un ami m’a envoyé un message pour me dire qu’il espérait que j’avais configuré Cloudflare. Je ne l’avais pas fait, mais la charge moyenne de mon VPS à 2 cœurs et 1 Go de mémoire n’a pas dépassé 0,15
L’idée était du type : « c’est principalement du HTML, mais arrivé à telle ligne de tel fichier, on exécute du code pour parser un fichier d’un autre format et insérer le résultat dans la sortie »
En 2001, c’était tout à fait raisonnable pour créer un site statique avec, par exemple, une section de commentaires sous chaque billet de blog. Ce type de PHP était assez peu coûteux pour que les FAI autorisent souvent son déploiement dans
/~userdir/et son exposition sur l’internet publicAvec une architecture raisonnable qui ne dépend pas trop lourdement d’une base de données, même un petit VPS peut facilement encaisser un afflux venu de Hacker News
Si vous lancez Threads, il vous faudra sans doute l’échelle à laquelle opère Facebook, mais pour un site en lecture seule ordinaire, il n’est absolument pas nécessaire de dépenser beaucoup d’argent
Je peux imaginer des raisons comme injecter du contenu dynamique dans un template, ou réduire le temps de build et la complexité, mais il y en a peut-être d’autres auxquelles je n’ai pas pensé)
En tant qu’observateur extérieur qui touche un peu à wasm, je ne comprenais pas pourquoi exécuter du code utilisateur sur le serveur pour générer des pages web « dynamiques » serait préférable à un simple serveur de fichiers.
Je me disais que la partie dynamique pouvait s’exécuter dans le navigateur, et que le serveur n’avait qu’à fournir les fichiers. Le seul cas à part, c’est que les navigateurs des années 90 étaient nuls pour ce genre de travail.
En termes de simplicité et de scalabilité, rien ne bat un simple serveur de fichiers derrière un CDN.
Il est aussi important de voir quelles technologies ne cassent pas les fonctionnalités natives du navigateur.
À titre d’exemple, GitHub casse encore le bouton retour environ 40 % du temps dans mon environnement quand je navigue dans le code source. J’utilise Chrome sur OSX, et je ne comprends même pas comment c’est possible.
D’après mon expérience, les sites qui génèrent le HTML côté serveur semblent plus rapides et plus fiables que ceux qui dépendent du rendu côté client. Quand le cache du navigateur est vide, ouvrir un booru avec plus de 50 images par page me semble toujours plus rapide et plus agréable qu’ouvrir une page GitHub composée uniquement de texte, déjà en grande partie en cache et inchangée depuis plusieurs jours.
Par exemple, on peut vouloir enregistrer dans une base de données du contenu soumis par les utilisateurs, avoir besoin d’authentification, ou fournir une recherche plein texte sur un jeu de données de plusieurs Go. Il peut aussi falloir fournir une interface vers des choses inaccessibles depuis le navigateur, ou valider les entrées utilisateur.
Tout cela nécessite du code côté serveur. Il faut alors transformer les données présentes sur le serveur en un protocole de transport bien défini pour les envoyer au client, puis les reconvertir et en faire du HTML.
Et cela vaut aussi dans l’autre sens : pour se protéger contre des clients personnalisés malveillants, il faut valider les entrées à la fois côté client et côté serveur.
Ou bien on peut simplement générer le HTML directement sur le serveur et s’arrêter là. C’est beaucoup moins de travail, et pour la plupart des applications, cela offre pratiquement la même expérience.
S’il existe des secrets à garder, comme un mot de passe de base de données, une clé API ou une clé de chiffrement, il faut que du code côté serveur s’en charge. Si tout le code s’exécute côté client, il y aura toujours un risque qu’un attaquant découvre ces secrets.
Il est aussi plus facile de réduire la surface d’attaque en exposant au client une API plus petite et plus limitée. Si le client se connecte directement à la base de données, il faut que les permissions et la configuration de sécurité soient parfaitement correctes ; alors que si l’application ne fournit qu’une liste de livres ou de films, il est plus difficile de contourner les défenses.
Fournir le chargement initial sous la forme d’un bloc de données immédiatement exploitable donne aussi souvent au site une impression de meilleure réactivité. Même si, dans les faits, cela prend autant de temps que de télécharger l’application, afficher un indicateur de chargement, puis récupérer et afficher les données, la première approche paraît plus rapide à l’utilisateur.
Le serveur se trouve généralement à côté de la base de données et des autres serveurs nécessaires, donc charger ce qu’il faut en amont peut être plus rapide. Les appels réseau dans cet environnement sont plus fiables. Si l’on reporte tout le traitement côté utilisateur, il faut gérer des appels plus lents et plus instables.
Le serveur a aussi de fortes chances d’être une plateforme bien plus cohérente que le navigateur de l’utilisateur. Les navigateurs se sont améliorés, mais ils gardent encore beaucoup de différences subtiles. Sur le serveur, on peut spécifier précisément les outils et les versions de runtime nécessaires, et les mettre à jour de façon plus déterministe.
Bien sûr, ce n’est pas toujours vrai dans tous les cas, et il existe des exceptions. Je travaille surtout sur des applications frontend, et il y a aussi beaucoup de valeur dans des applications bien conçues qui exécutent l’essentiel, voire la totalité, du travail dans le navigateur. Mais en général, il s’agit d’applications web assez complexes, ou de cas où un certain niveau de rendu dans le navigateur est de toute façon nécessaire.
La génération n’a lieu qu’une seule fois et se termine très vite. Ensuite, du point de vue de l’utilisateur, on retrouve tous les nombreux avantages des pages statiques.
L’utilisation des ressources est inférieure de plusieurs ordres de grandeur, les pages réagissent bien mieux, et l’expérience utilisateur est largement supérieure — simplement, nous n’y avons pas vraiment prêté attention ces dix dernières années.
rsync. Toutes les pages étaient rendues dynamiquement.L’avantage, c’est qu’une fois la configuration faite, je n’avais littéralement plus à me soucier du site web, je pouvais simplement écrire en Markdown comme je l’aimais.
C’était excellent. Jusqu’à ce que l’hébergeur supprime PHP.
C’est pour ça que j’aime énormément l’export de pages statiques de NextJS.
On build, puis on déploie les seuls fichiers statiques
.html,.jset.csssur le CDN ou le serveur web statique de son choix. Les pages et routes individuelles sont pré-rendues au moment du build, donc le premier chargement est très rapide et l’indexation par les moteurs de recherche est possible.La manière dont NextJS découpe le code
.jsen chunks et les précharge contribue aussi à une expérience de chargement rapide. Si l’on a besoin de fonctionnalités riches, on peut connecter le tout à l’API REST de son choix et le rendre aussi dynamique qu’on veut.Avec le plugin MDX, il est aussi facile de créer dans le même projet des zones entièrement statiques ou des sites centrés sur le contenu.
En revanche, depuis l’arrivée de l’app router v13, j’ai l’impression que la fonctionnalité d’export statique n’est plus suffisamment prise en compte. Certaines fonctionnalités du page router, comme le shallow routing ou les rewrites/redirections statiques, manquent dans l’export statique.
Comme l’export statique rend totalement inutiles les produits commerciaux de Vercel, je crains qu’ils ne finissent par supprimer complètement cette fonctionnalité à long terme.
La plupart du temps, il n’y a même pas besoin de JavaScript, et encore moins de React, JSX, middleware ou rendu côté serveur.
J’ai du mal à imaginer la maintenance à long terme de quelque chose avec autant de pièces mobiles et de dépendances npm. Cela ne veut pas dire que ça n’a aucun intérêt, mais avant de se lancer dans un projet de 1.8 GiB de checkout Git et 828,128 lignes de code juste pour faire une landing page, il faut savoir rester simple.
Voir l’exemple de Dan Abramov : https://gist.github.com/gaearon/9d6b8eddc7f5e647a054d7b33343...
Ce n’est pas à cause du business model de Vercel, mais parce que ce cas d’usage est moins fréquent au vu de la répartition des usages de Next.js.
Je ne vois pas très bien ce que signifie « rewrites statiques ». Est-ce que ça ne se gère pas via du middleware ?
À un moment dans les années 90, avant même d’entendre l’expression « générateur de site statique », je générais mon site avec m4
Ensuite, je suis passé à PHP puis à Python, et maintenant j’utilise Jekyll, donc je suis revenu au statique
Dès que c’est possible, l’approche statique est largement meilleure. À part le certificat SSL, je peux tout corriger selon mon propre calendrier
Si une mise à niveau de PHP casse quelque chose, il faut le réparer immédiatement, avec le site hors ligne jusqu’à ce que ce soit réglé
Avec un site statique, même si le générateur casse, le résultat de l’échec reste simplement en état statique. S’il n’y a pas besoin de publier de nouvel article, ce n’est pas un problème
Même si le serveur tombe, il suffit de demander à un ami d’héberger quelques fichiers. Pas besoin de demander « tu fais tourner PHP version X avec la configuration Y, n’est-ce pas ? Tu as aussi postgres ? »
Certains amis peuvent aussi dire : « je n’ai pas envie d’installer PHP sur mon ordinateur »
En termes de complexité, j’ai l’impression que c’est un cran au-dessus de
sed "s/VERSION/1.2.3/g". Si tout peut être géré avec des commandes shell externes, il n’y a pas besoin d’installer quelque chose comme PythonDepuis plusieurs années, j’explore un modèle d’architecture qui offre à la fois les avantages du statique et du dynamique
Il permet d’exécuter du code dynamique côté serveur tout en gardant un coût de montée en charge très faible et une capacité à se rétablir tout seul quand quelque chose casse
J’appelle ça le pattern Baked Data : https://simonwillison.net/2021/Jul/28/baked-data/
L’idée centrale consiste à déployer une copie complète en lecture seule des données du site comme un asset embarqué avec l’application
Comme pour un site entièrement statique, il faut redéployer l’ensemble du site à chaque changement, donc ce n’est pas adapté aux sites mis à jour en continu
L’avantage, c’est qu’on peut le déployer sur un hébergement dynamique scale-to-zero peu coûteux comme Vercel, lancer plusieurs copies de l’app pour absorber n’importe quel trafic, et laisser l’hébergeur redémarrer automatiquement l’app si elle tombe
J’ai déjà vu des sites statiques avec recherche côté serveur ou système de commentaires, où chaque article ou commentaire est soumis comme un fichier plat séparé puis déclenche une régénération automatique des pages statiques
Je me demande si la différence est simplement qu’on stocke dans sqlite au lieu de fichiers Markdown, puis qu’on construit à partir de là. Comparé à un site statique classique avec des fonctions backend / côté serveur, c’est la seule différence visible et significative que je vois
Il n’était pas rare d’inclure dans des exécutables binaires compilés des ressources binaires encodées, comme des fichiers ou des images. On n’en mettait pas beaucoup parce que cela augmentait la taille de l’exécutable
Exemple en C ou C++ : https://github.com/graphitemaster/incbin
Ce qui est intéressant, c’est qu’on concevait le programme pour que les données à l’intérieur de l’exécutable ne changent pas. Le code compilé s’exécute sur la machine, et du point de vue de la sécurité cela a aussi du sens
Mais si on pense aux conteneurs, par exemple docker, un conteneur en cours d’exécution ressemble à un exécutable empaqueté, sauf qu’il a aussi un système de fichiers
Mettre des données dans un conteneur revient à une idée similaire à des ressources embarquées dans un exécutable, sauf que ces données peuvent être modifiées
Cela dit, même si les données changent à l’exécution dans le conteneur, elles ne persistent pas sans stockage persistant attaché
Récemment, je me suis demandé pourquoi on n’avait pas créé quelque chose comme un fichier unique où « l’exécutable et un espace de données volatile se trouvent à l’intérieur de l’exécutable ». On pourrait imaginer qu’un programme et des données de type base de données soient combinés dans un seul fichier
C’est une idée un peu liée à « Baked Data ». Embarquer des ressources dans un exécutable, c’est au fond mettre des données encodées dans l’exécutable
Dans les langages de script, on peut créer un fichier script qui contient directement dans une variable des données encodées en base64
Ces deux dernières approches ne conviennent qu’à des données statiques relativement petites, mais il serait intéressant d’inventer une technique permettant de dépasser d’une manière ou d’une autre ces contraintes des exécutables
J’héberge aussi ma page de projets de cette façon : https://usmanity.com/projects
Comme je ne voulais pas éditer directement les fichiers HTML chaque fois que j’ajoute un nouveau projet à la liste ou que je modifie les détails d’une entrée existante, j’utilise Notion puis j’intègre les données avant de commit sur GitHub
Une fois activé, il cuisait toutes les pages du site en HTML dans un répertoire, puis modifiait le
.htaccesspour y rediriger tout le trafic. Quand le contenu était mis à jour, tout était recuithttps://www.drupal.org/project/boost
Ce qui manque encore le plus aux sites statiques, à mon avis, c’est où héberger un CMS d’édition
Corrigez-moi si je me trompe, mais Decap CMS (anciennement Netlify CMS) s’exécute dans le navigateur et peut lire/modifier via GitHub, puis déclencher un rebuild et un déploiement. Mais à cause de CORS, le navigateur ne peut pas communiquer directement avec l’API GitHub, donc il faut toujours, selon moi, un petit serveur ou un proxy
Netlify héberge un backend GitHub qui relaie les requêtes, mais cela lie alors à Netlify et à l’évolution de sa politique tarifaire
GitLab et BitBucket ont probablement le même problème : https://github.com/isomorphic-git/isomorphic-git#cors-suppor...
Existe-t-il un moyen simple de résoudre cela avec une configuration minimale ? On pourrait peut-être assouplir CORS de façon sélective avec une extension de navigateur, mais ce n’est pas idéal
Un CMS pour les générateurs de sites statiques basés sur Git, avec édition Markdown et prévisualisation en temps réel, qui s’exécute dans le navigateur et impose peu de contraintes d’hébergement/serveur, semblerait convenir à énormément de petits sites web et blogs
Le générateur statique n’aurait qu’à lire ces données via quelque chose comme un flux JSON pour produire les pages. Par exemple, chaque fiche produit pourrait inclure une description principale au format HTML
Ainsi, même si quelqu’un d’autre met à jour les informations produit, le site web resterait entièrement statique. Je pensais qu’Airtable conviendrait, mais de façon surprenante il ne gérait pas très bien les champs HTML
Il suffit de construire le site web comme on le souhaite, de connecter Surreal via FTP, puis de laisser les utilisateurs ou les clients modifier uniquement les parties autorisées
12 dollars par mois, c’est très peu cher pour ne plus avoir à s’en soucier, et cela permet d’offrir un éditeur WYSIWYG complet aux utilisateurs non techniques
[1] https://www.surrealcms.com
Actuellement, cette extension fonctionne avec VS Code installé localement sur un ordinateur portable, mais pas dans GitHub Codespaces
Si on pouvait faire fonctionner cela dans la limite de l’offre gratuite de GitHub Codespaces, avec une limite de temps d’utilisation raisonnable, ce serait probablement la formule gagnante. Une configuration entièrement en ligne et versionnée, sans avoir à installer l’environnement de développement sur ma machine, avec le site statique servi depuis quelque chose comme S3, tout en conservant une expérience CMS complète
Un point très important des sites statiques, c’est qu’il est bien plus facile de les mettre en ligne puis les oublier
Si on les met sur quelque chose comme un site de bucket S3, il n’y a pratiquement plus à s’en préoccuper
Si on crée un site « mis en ligne puis oublié » en PHP, ou pire, avec un WordPress auto-hébergé, il peut se retrouver couvert de pubs porno russes en quelques mois si on ne va pas vérifier régulièrement
J’exploite quelques sites statiques et c’est vraiment agréable de savoir qu’ils sont toujours disponibles et n’ont pas besoin d’être réparés. À l’inverse, pour les sites dynamiques, il faut des alertes pour vérifier s’ils sont tombés en panne ou non.