What the fuck is Jamstack ?

17 October 2020

(Photo principale par Lakeisha Bennett on Unsplash)

Depuis quelques années, il y a une véritable explosion du terme "Jamstack" dans le monde du développement web; avec des promesses fortes à la clef : des sites qui seraient plus faciles à maintenir, plus sécurisés, plus scalables, plus découplés. Mais de quoi s'agit-il exactement ? D'un terme marketing bullshit pour vendre du statique ? D'une manière de développer ? D'une association de logiciels bien précise comme LAMP (Linux / Apache / Mysql / PHP) ? À la fin de l'article, vous saurez répondre à cette question !

Les bienfaits du statique

Revenons aux origines, en tout cas telles que je m'en souviens lors de mes débuts dans le développement web.

Quand j'ai commencé à développer dans les années 2000, il y avait beaucoup de sites codés "from scratch" en PHP qui ne disposaient pas d'un back-office permettant aux clients de modifier eux-mêmes leurs contenus. 

Il n'était pas rare qu'un client voulant modifier sa page d'accueil doive contacter et payer des développeurs / agences web pour modifier une phrase ou un texte !

Les CMS (Content Management Systems) existaient pour résoudre ce problème : une interface de rédaction en ligne permettant au client de modifier (ou de créer) lui-même ses contenus sans faire appel aux développeurs à chaque fois.

Avec l'essor de PHP ont surgi de très nombreux CMS, certains d'entre eux restent très populaires et utilisés aujourd'hui, comme Wordpress (qui domine aujourd'hui très largement le marché mondial) ou Drupal. 

Ces CMS en PHP étaient au départ légers, rapides et faciles à apprendre. Il était par exemple possible d'héberger un Drupal ou un Wordpress sur des hébergements gratuits, et la courbe d'apprentissage permettait rapidement de comprendre leur fonctionnement et de produire des sites bien plus rapidement qu'en codant depuis zéro soi-même. C'était le début d'un âge d'or pour les sites dynamiques propulsés par des CMS.

Avec les années, ils sont devenus de plus en plus puissants et flexibles, pour ne pas dire tout simplement obèses.  L'ajout de fonctionnalités, année après année, a rendu la courbe d'apprentissage de plus en plus longue, le code de plus en plus complexe; et Wordpress et Drupal sont devenus de plus en plus gourmands en mémoire vive avec un temps d'affichage de page de plus en plus lent; et les upgrades vers des versions majeures de plus en plus douloureuses concernant Drupal.

Tant et si bien que les inconvénients générés ont fini par contre-balancer les bénéfices initiaux; la complexité à développer, le temps de production d'un site, la lenteur de rendu d'une page interprétée posait de plus en plus question : quel est le sens d'exécuter à chaque requête HTTP, à chaque affichage de page donc, un logiciel pesant des centaines de milliers de lignes de code ? C'est du PHP, donc à chaque affichage de page, le logiciel est exécuté en entier à nouveau pour générer le HTML final.

Et surtout, ce dynamisme obèse était-il toujours justifié ? Si le client n'avait besoin de mettre à jour son contenu qu'une fois par mois ou une fois par semaine cela ne faisait pas sens d'exécuter à chaque visite ces mastodontes.

Il y a donc eu une envie de revenir aux fondamentaux, de recréer des sites bien plus simples à produire et à héberger, et en phase avec le rythme auquel les contenus ont besoin d'être mis à jour. Une envie de légèreté.

Un cas d'école est le blog : si vous écrivez seulement 10 articles par an, un énorme logiciel dynamique semble sur-dimensionné !

Jekyll : le come back en force du statique

Créé en 2008 par Tom Preston-Werner, le fondateur de GitHub, Jekyll se présentait comme un “générateur de site statique simple, prêt-à-bloguer”. Il reste l'un des générateurs statiques les plus populaires à ce jour !

L'idée est de revenir à une forme de minimalisme pragramatique : on stocke directement le contenu du blog dans des fichiers markdown. Un logiciel en Ruby va ensuite, lors d'une phase "compilation" ou "génération", les passer au travers d'un système basique de templating (Liquid), pour générer tous les fichiers HTML finaux. Il n'y a plus qu'à déployer alors ces fichiers statiques HTML sur n'importe quel hébergeur / serveur et voilà, c'est prêt ! Pas besoin de language côté serveur comme PHP, pas de configuration complexe ! Une brise d'air frais dans le monde douloureux de la maintenance applicative.

À chaque nouvel article, il suffit de re-générer et re-déployer le tout. Oui, il faut re-générer TOUT le site pour chaque modification, mais la démarche est très peu coûteuse, quelques secondes peuvent suffire à générer des centaines ou des milliers de pages ! 

Pas de base de données, pas de CMS, pas de langage serveur à gérer, pas de failles de sécurité ! Ça scale et ça fait le taf.

C'est un peu le départ de la nouvelle vague statique (pour ne pas dire la nouvelle folie) qui s'empare aujourd'hui du monde du web.

Jamstack : du statique sous amphétamines

En 2014 naît un néo-hébergeur désormais bien connu : Netlify. Il est spécialisé dans le build et l'hébergement de site statique. Le fonctionnement est d'une simplicité enfantine : vous le connectez à, par exemple, votre site Jekyll hébergé sur GitHub. À partir de là, à chaque git push sur la branche master, Netlify re-génère automatiquement votre site statique Jekyll et le déploie pour vous sur son CDN, le tout dans une interface extrêmement simple et intuitive. 

Ce ne sont pas les seuls à permettre cela, d'ailleurs GitHub Pages proposait déjà de faire votre build Jekyll et de déployer vos fichiers avec un simple "git push" ! Mais c'est bien un nouveau workflow de travail qui s'impose progressivement : créer un repository git, modifier un fichier markdown, faire un git push, et c'est prêt !

Si je parle de Netlify, c'est qu'ils sont à l'origine du fameux terme Jamstack, mais j'y reviens.

La montée en puissance de JavaScript

À cela s'ajoute la belle histoire de JavaScript, le vilain petit canard du web devenu cygne ! Il a pris, on va le voir, une place bien au chaud dans cette histoire de renouveau du statique pour notamment trois raisons :

1 - Rendre dynamique un site statique avec du HTML

Prenez ce site statique : Popcorn Nantes, une alternative à Malt que j'ai lancé pour trouver un développeur freelance à Nantes. Le site est bien généré statiquement à partir de fichiers markdown, hébergé gratuitement sur GitHub Pages, pourtant la recherche est dynamique : tapez un mot clef et seuls les profils contenant ce mot clef seront affichés.

JavaScript est bel et bien un moyen d'ajouter du dynamisme à une page statique, la frontière entre fichiers statiques hébergés et un site dynamique est donc poreuse : on peut bien injecter du dynamique dans une page HTML à partir de fichiers statiques grâce à JavaScript.

2 - Appelez des APIs en JavaScript pour épicer votre site statique !

Avec l'apogée du JSON, des webservices et des SaaS, on peut même aller bien plus loin : JavaScript étant capable de faire des requêtes HTTP, un site statique peut en réalité appeler des APIs externes pour ajouter de nombreuses fonctionnalités puissantes, par exemple un paiement en ligne avec Stripe pour créer une véritable boutique en ligne ! 

Certes, il y a bien quelque part un serveur avec un language dynamique, mais chez Stripe, pas du côté de votre front-end : vous n'avez donc toujours pas de serveur avec un language dynamique à gérer vous-même, pas de mise à jour de plugin, de module ou de CMS non plus.

3 - JavaScript est aussi un moteur de template exceptionnel  !

Autre fait notable, la naissance de librairies comme Angular, React, Vue, etc a complètement changé la manière de créer des templates; c'est-à-dire de générer du HTML en sortie en fonction de données entrantes.

Tant et si bien qu'il est vite devenu évident qu'on pouvait générer le HTML de fichiers statiques avec ce genre de librairie orientée composants, c'est ainsi qu'est né Gatsby.js : on crée son site avec des composants React, Gatsby les transforme en HTML statique qu'on peut ensuite déployer où l'on veut, comme un site statique Jekyll ! 

Du point de vue du développeur, ce sont les avantages d'un Jekyll avec l'expérience de développement de React qui est très appréciée par les développeurs front-end, on peut donc comprendre le succès de la démarche.

Le fait de pré-générer le HTML grâce à Gatsby plutôt que d'utiliser directement du React "classique" a un avantage significatif : cela rend votre site beaucoup plus facile à indexer par les moteurs de recherches, et le pré-rendu HTML permet aussi d'afficher la page directement avant même qu'elle soit totalement hydratée par le JavaScript, elle s'affiche donc plus rapidement pour le visiteur. 

Le retour du Jedi : les CMS nouvelle génération ou "CMS Headless" !

Si le stockage sous forme de fichiers markdown est très astucieuse, il reste un problème de taille, initialement résolu brillamment par les CMS monolithiques ! Comment offrir une administration en ligne simple pour qu'un client puisse éditer lui-même ses contenus sur son site statique ?

(Notons aussi que le stockage dans des fichiers markdown ne peut pas vraiment rivaliser avec une véritable base de données lorsqu'il s'agit de gérer une certaine complexité dans les relations ou le tri des données !)

Il y a deux écoles à partir de là : les CMS "git-based" qui offrent une belle interface en ligne identique à un CMS classique pour éditer directement les fichiers markdown de votre site statique (tel que Forestry) : en se connectant à votre dépôt GitHub, ils enregistrent les modifications en écrivant et modifiant les fichiers markdown de votre dépôt git !

Les CMS "API-based" comme Fireblog : dans ce cas, le but est de ne pas utiliser de fichiers markdown du tout : comme avec un Wordpress, on écrit dans l'interface en ligne directement. On peut ensuite utiliser un générateur de site statique comme Eleventy, Gatsby (mais aussi des frameworks versatiles comme Nuxt ou Next !) pour faire des appels API au moment de la génération du site pour générer les fichiers HTML finaux !

C'est une bonne solution si vous avez besoin de vous affranchir des limites de formatage du markdown (ajouter des légendes sous des images, gérer des tableaux comparatifs, etc sont des choses difficiles ou impossibles avec le markdown de base).

Bien évidemment, les CMS headless peuvent théoriquement servir pour créer des sites 100% dynamiques (rien ne vous interdit d'afficher les contenus d'un CMS headless avec du Node.js ou du PHP qui va le récupérer dynamiquement à chaque affichage de page).

Mais chez Fireblog, nous prônons l'utilisation du statique quand c'est possible et pertinent car cela présente de nombreux avantages (facilité à déployer et à héberger, sécurité, scalabilité, pas de serveur à gérer soi-même...) et c'est tout particulièrement adapté pour du blogging.

Jamstack : un mélange de plusieurs concepts

Comment Netlify schématise l'architecture Jamstack : https://www.netlify.com/jamstack/

Au final, Jamstack c'est un peu un mélange de tout ça : il s'agit de créer des sites statiques (donc du HTML pré-généré plutôt que créé à la volée par un language tel que PHP) en tirant parti des néo-hébergeurs comme Netlify (génération automatique de votre site statique au git push + déploiement sur CDN) et de JavaScript pour épicer vos pages avec des appels à des APIs et ajouter du dynamisme.

Il ne faut pas oublier la notion de découplage fort également : si par exemple votre front-end est purement statique et que vous utilisez un CMS headless, cela veut dire qu'il est possible de travailler sur l'un sans impacter l'autre et sans connaître toutes les particularités de l'autre ! À l'inverse d'un Drupal dont il faut bien comprendre les mécanismes internes pour réaliser un template correctement. 

Cela signifie également qu'à tout moment, vous pouvez changer d'hébergement ou de techno pour votre front-end sans que cela impacte le fonctionnement de votre back-office.

Il y a une relation intime entre Jamstack et Netlify : Netlify essaie ainsi de résumer en un seul mot sa vision d'entreprise pour le futur du web centrée sur le front-end tel qu'il le conçoit, et qu'il oppose fermement à la manière traditionnelle de faire des sites avec des CMS monolithiques complexes généralement auto-hébergés. 

C'est donc par extension aussi pour eux un outil de marketing et de communication. Ainsi les conférences mondiales Jamstack qu'ils organisent chaque année permettent de sensibiliser le monde du web aux sites statiques / Jamstack, et bien sûr et surtout d'envisager Netlify pour les héberger !

Néanmoins, les offres se multiplient de ce côté et les alternatives puissantes à Netlify (telles que Vercel) sont nombreuses, cette vision Jamstack est en réalité bien évidemment facile à mettre en place chez d'autres hébergeurs et en communiquant sa vision, Netlify pave aussi le chemin pour les autres acteurs de cette véritable nouvelle économie du web.

A-t-on perdu de vue la simplicité initiale du statique ?

Dans un cycle dont l'histoire a le secret, il semble aujourd'hui qu'on perd parfois de vue que l'origine de la nouvelle vague statique était un retour à la simplicité de développement et de maintenance, une manière également de ne pas dépendre d'un hébergeur particulier et d'éviter l'enfer de la maintenance : en soi, des fichiers statiques sont faciles à déployer n'importe où sans aucune configuration et c'est toute la magie !

Notre motivation pour Fireblog, c'est cette simplicité d'usage du statique pour le blogging, alliée à une véritable interface de rédaction pensée pour les web-rédacteurs et les clients qui ont besoin d'écrire de longs articles avec des médias riches, pour éviter les limites des fichiers mardown ! On vise l'alliance du meilleur de la nouvelle vague statique et des anciens CMS de blogging en somme. :)

Il est ainsi particulièrement simple et agréable de créer des thèmes pour afficher un blog fireblog comparé à des solutions comme Wordpress et Drupal qui imposent leurs règles et leur language. Fireblog permet lui aux développeurs front-end de choisir leurs technologies front-end préférées sans avoir à connaître la mécanique interne de Fireblog : il suffit d'interroger notre API GraphQL particulièrement expressive et simple.

Le blog que vous lisez actuellement est conçu sur ce principe : généré statiquement avec Eleventy qui va chercher les articles sur fireblog; et il hébergé chez Netlify. À chaque fois qu'un article est créé ou modifié, le site est re-genéré automatiquement en quelques secondes (Fireblog prévient Netlify automatiquement qu'il faut re-générer le site via un webhook).

Si cet article vous a donné envie, il est temps de faire un essai ! Créez votre blog statique avec un CMS nouvelle génération dédié à l'écriture, en utilisant les technologies front-end qui vous font vibrer. (Consultez notre documentation pour voir des exemples de code et d'intégrations !)

En cas de question, contactez-nous directement par chat (depuis notre CMS ou depuis notre page d'accueil) ou contactez-moi personnellement par mail, je serai ravi d'échanger avec vous sur le sujet ! (yann@fireblogcms.com)

Yann, fondateur de Fireblog
 

 

 

.

Suivez-nous