Oulà, je disais juste ça à titre de conseil…
Loin de moi vouloir troller, mais la somme est nulle, pas un de tes arguments n’est juste :
Va sur la doc de silkaj réalisé avec vuepress, désactive le javascript : le site est le même !
Juste la navigation n’utilise pas l’api html5 pour le routage, mais ça recharge la page au lieu de naviguer directe ; régression transparente.
62.8 KB de js, ça va ton vieux téléphone et firefox peuvent tenir le coup… (ce forum utilise 4.2MB de js).
Toutes les balises meta et le sitemap sont construit au compile time, c’est SEO friendly. C’est pas le client qui travaille, c’est ton ordi lors de la compilation. Tous les calculs sont justement fait en amont, même pas de serveur, c’est quand même mieux en conso énergétique. Mais bon, zola fait ça aussi. Je pense qu’il y a une incompréhension sur ce que fait réellement le javascript… un SSG javascript peux comprendre le javascript dans un fichier markdown au compile time, charger les composants dont à besoin la page et les intégrer directement pour le runtime. Zola, Hugo, Pelican, Jekyll… et autres SSG non js ne peuvent pas faire ça.
Avec nuxt, tu peux commencer le site en statique, puis passer en PWA ou en SSR en changeant juste un paramètre. C’est fait pour évoluer en fonction des besoins et la taille du site…
Benchmark :
http://duniter.trentesaux.fr ← 18 requests, 7 fichiers css, 1.2MB
https://mystifying-nobel-66ae54.netlify.app/fr/ ← 17 requests, 1 fichier css, 588 KB
Et encore, les perfs sont plombées par la taille des images… Bon ok, ce site fait en 2020 à du javascript, ça craint. Par contre tu l’installes sur ton smartphone comme une appli web, et tu navigues hors ligne… Perso je préfère plutôt désactiver le wifi que javascript, mais là tu peux même faire les 2 
Côté allergique à js, tu fais yarn dev au lieu de zola build dans ton bash et tu créés le site en live sans recharger le site, il te suffit juste d’oublier que c’est du js en fait…
Côté séparation contenu, c’est justement pour éviter ce genre de problème. Chacun pourra compiler le site avec le moteur SSG de son choix…
Si le contenu est couplé avec la mise en forme, c’est qu’il y a un problème SoC (Separation of Concern) avec ton SSG. Pour les nons techos, c’est quand même plus clair de ne pas avoir d’autres fichiers que les fichiers du contenu en .md. En terme de gestion du site, ils n’ont pas à ce soucier d’avoir des commits et issues sur le code au milieu d’issues et commits sur le contenu… c’est pas pour rien que tous les gros outils open source font comme ça pour leurs docs ! Il n’y a qu’à parcourir github…
Enfin, tu peux avoir un fichier markdown que n’importe quel rédacteur à l’aise en markdown peut comprendre :
<breadcrumb />
<toc />
# Bienvenue !
La **june** compte actuellement **<g1-members-count /> membres**.
Le dividende est de <g1-dividend />.
Les composants mettent à jour automatiquement listes et compteurs. Pas une ligne de js. Et tu peux compiler ça pour du vuejs, react, svelte… peu importe ! Pas besoin de scripts de migration et autres shortcodes… c’est juste du html + md. Pas besoin de templates et autres {% extends %} séparant le contenu de la vue…
Pour les devs se sera aussi plus simple.
Tout ça n’est pas que le dernier trucjs à la mode. Tu as déjà utilisé gatsby, vuepress ou du headless cms comme strapi ? Moi oui et depuis longtemps, et je comprend tout l’écosystème que c’est mis en place autour des SSG, headless ou JAMstack…
Les points qui guident mes conseils sont aussi une grande expérience, des outils low tech et rapide (vitejs avec vue3, c’est de l’import de module en natif. Ça peut pas être plus rapide, c’est natif !). De la compilation sass, less, postcss… depuis le composant direct (encore SoC), avec assurément plus de fonctionnalités (RSS, breadcrumb et import uml et surtout du PWA !) et utilise un language à la base fait pour le web et pas pour les serveurs.
En terme de maintenance pour les 3 prochaines années, ce sera sûrement plus simple à gérer et évolutif qu’un outil qui ne respecte pas les standards front matter, fait pas d’i18n et n’utilise pas les dernières avancées du web (build modulaire js et css, HMR, PWA, import js natif…).
Maintenant, je dis tout ça juste à titre de conseil justement pour expliquer pourquoi telle chose est pertinente ou non… Mais j’ai l’impression de rentrer dans une gueguerre de specs techniques que je ne pensais pas générer avec mon précédent post…
Bref, j’émettais seulement des idées et proposais d’installer tout ça avec nuxt. Vu la réaction, je sais plus… Je le ferais plutôt plus pour monnaie-libre, et assurer la construction et maintenance du générateur, pas forcément du contenu.
Pour la mise en place j’ai pas la main, @moul doit faire une CI avec gitlab pour la doc Silkaj pour que ce soit sur “nos” serveurs. En attendant, l’hébergement gratos installé en 5 min sur netlify marche toujours très bien depuis des mois…
Tout ça à définitivement à voir avec le 1er post de ce topic : boucles de rétroaction trop longues, processus conflictogène… Chacun fait à sa sauce sans concertation et avec ses convictions… et c’est toujours aussi difficile de savoir qu’est-ce qu’il y a à faire et qui fait quoi dans le process de cette ML…
Pour pouvoir fonctionner en réseau, il faut de la transparence.
Bref, j’adhère à 100% aux remarques de @anon88550267 !