Alors… “le futur du web”, certes, mais il faut savoir que l’histoire est plus ancienne. Dans ses premiers jours, le web utilisait déjà ce principe : dans le disque dur d’un serveur lointain vivaient des fichiers html, css et javascript, et quand nous y faisions appel, le serveur les envoyait directement à notre navigateur, qui en faisait le rendu. Pas de pré-traitement des données par un back-end. Le contenu était déjà prêt ! Cela garantissait une rapidité très conséquente (à peine gâchée par la vitesse de connexion de l’époque).
Avec l’évolution du web, beaucoup de fonctionnalités sont passées du côté serveur, qui ne se contente plus aujourd’hui de juste servir des fichiers mais, au contraire, génère tout le contenu (le markup et ses dépendances) dans le serveur via un back-end pour finalement l’envoyer en format html, css et javascript à notre navigateur.
Cela a ses avantages, notamment celle de ne pas trop en demander du côté hardware de l’usager. En effet, un serveur peut être plus robuste et avoir plus de capacité de traitement de données pour générer le contenu final - plus léger - qui sera alors consommé par le navigateur du visiteur.
Cela a créé une dynamique très établie aujourd’hui dans les relations client-serveur web. On demande une page : le back-end fait que le serveur traite les données, les convertit en fichiers statiques, nous les envoie et on les lit. Puis on clique sur un lien pour une autre page : le serveur traite les données, les convertit en fichiers statiques, nous les envoie et on les lit. On fait une recherche, le back-end la traite, le serveur génère, la convertit, nous l’envoie… et l’histoire se répète ainsi tout au long de la visite.
Tout cela exige beaucoup de ressources - du serveur et de la connexion. Le serveur est constamment utilisé (processing power) pour résoudre le back-end, ce qui consomme de l'énergie et du temps. Et la connexion est constamment activée dans les nombreux appels de ce va-et-vient. En plus de consommer beaucoup de ressources, on peut concrètement sentir le temps que cela prend lors de notre navigation.
Le JAM stack se veut différent. Et si on faisait en sorte que tout le contenu d’un site soit déjà prêt avant qu’on ne le demande et qu’on maintienne quand même toutes les capacités interactives et dynamiques qui existent dans les sites modernes ? Comme dans le passé, on pourrait juste faire appel au serveur pour qu’il nous envoie les fichiers sans devoir travailler dessus. Cela demande (beaucoup) moins de temps et de ressources du point de vue serveur. Et qui dit moins de ressources dit moins de coûts liés à l’hébergement ainsi qu’une empreinte carbone fortement diminué.
Mais alors… pas de back-end pour notre site ? Et comment allons-nous éditer notre contenu ? Toutes les informations du JAM stack se font via des appels API. Au lieu de générer tout le markup de la page, celui-ci est déjà prêt et, grâce à javascript, ne fait appel qu’aux informations spécifiques (textes, images) qu’on a besoin pour la page. Nous pouvons donc avoir une API custom qui va servir notre front-end au fur et à mesure.
Encore mieux : des frameworks comme Next.js, Gatsby ou encore Nuxt permettent de rendre les pages avec les informations au build time (quand on met le site en ligne). Ainsi, les fichiers statiques sont déjà peuplés par les informations.
Avec l’utilisation de webhooks (un appel qui vient de notre api pour informer qu’un changement a été fait), on peut alors régénérer la page spécifique qui aura été éditée et qui, dès lors, sera une page statique également.
Le résultat est un site complètement customisable et qui garde pourtant une vitesse incroyable et demande très peu d’activité côté serveur.
Vitesse de chargement, moindre coût d’hébergement, eco-friendly… Les points positifs sont nombreux !