Le terme "Jamstack" a déclenché un débat animé récemment, car sa définition s'étend pour englober les applications plus récentes. Mon article précédent, "Static vs Dynamic vs Jamstack: Où est la ligne?", Offrait mon point de vue sur la définition de Jamstack. Cette pièce explore l'évolution de Jamstack et son impact sur le sens du terme.
La création de sites statiques est antérieure à l'étiquette "Jamstack". L'adoption précoce impliquait souvent des blogs simples ou une documentation open source hébergée sur les pages GitHub. Bien que certains pionniers aient abordé des projets commerciaux plus importants, ce n'était pas la norme.
Les sites statiques étaient autrefois considérés comme obsolètes - une relique des années 90. La question s'est posée: pourquoi les entreprises modernes adopteraient-elles cette approche apparemment désuet? La conversation IJS perspicace de Phil Hawksworth a mis en évidence l'ambiguïté: "Parlons-nous d'une expérience statique ou d'une architecture statique?"
Cette ambiguïté, en particulier pour les non-développeurs, est problématique. Les sites statiques modernes diffèrent considérablement de leurs homologues des années 90. Plusieurs progrès technologiques clés ont revitalisé le développement de sites statiques:
Jamstack a redéfini la perception des sites Web statiques. Matt Biilmann a inventé le terme en 2016, capturant les avantages des sites statiques modernes sans les connotations négatives de «statique». Cassidy Williams a résumé à juste titre l'essence de Jamstack: "Jamstack construit des applications Web comme les applications mobiles: l'interface utilisateur est compilée, et les données sont récupérées au besoin."
Jamstack a résonné fortement avec les développeurs WordPress, offrant une simplicité et un contrôle rafraîchissants par rapport aux API de thème et de plugin complexes. Une communauté a émergé autour de l'architecture découplée de Jamstack.
À mesure que Jamstack gagnait en popularité, l'échelle du projet et la complexité augmentaient. Les principes de Jamstack s'étendent au-delà des sites Web dans les applications Web, repoussant les limites de ce que les sites statiques pourraient réaliser. Les plates-formes ont introduit des fonctionnalités et des workflows pour s'adapter aux applications plus grandes et plus complexes utilisant des principes JAMSTACK.
L'implication de CloudCannon dans cette évolution est passionnante. Nous assistons à un changement significatif dans le développement Web, avec un écosystème florissant d'outils autonomisant les développeurs frontaux et permettant des applications sophistiquées basées sur les bords.
Le défi réside dans le manque de consensus sur la signification de Jamstack. Bien qu'il existe des définitions concises, l'application du terme à des comportements de plus en plus dynamiques provoque une division au sein de la communauté. Cette ambiguïté risque de saper le but même pour lequel le terme a été créé.
Le chevauchement entre les interprétations originales et évoluées de Jamstack crée un problème difficile. Bien que j'apprécie d'appliquer des principes Jamstack à des approches plus dynamiques, la création de nouveaux termes comme "Jamstack" exacerberait probablement la confusion.
L'observation de Matt Biilmann concernant le rendu persistant distribué de Netlify (DPR) est perspicace: "Pour toute technologie, la partie la plus difficile n'est pas une simplicité, mais la protéger au fil du temps."
Cela résonne profondément. La flexibilité de Jamstack est cruciale. Si un projet augmente ou nécessite des fonctionnalités dynamiques, des options doivent exister. Sans ces options, Jamstack serait relégué à des applications à petite échelle. Cependant, les solutions dynamiques excessives risquent de perdre la simplicité élégante qui a alimenté le mouvement Jamstack.
La DPR est une progression importante, abordant élégamment les limites des grands sites pré-construction. Pour un site avec 100 000 pages, le compromis de la pré-construction d'un sous-ensemble et la création d'autres autres à la demande est une optimisation intéressante.
La position de DPR dans le cadre Jamstack nécessite une attention particulière. Son inclusion ou son exclusion a des implications importantes. La définition de Sean Davis résonne: "Jamstack est une architecture pour la construction atomiquement et la livraison de projets Web frontaux précompilés et découplés depuis le bord." L'adaptation de cela pour inclure le DPR nécessite une modification. La définition officielle de Jamstack accueille cependant bien DPR.
L'évolution de la définition officielle de Jamstack est remarquable. L'inclusion de «sans serveur» reflète son accessibilité croissante aux développeurs frontaux, mais il est potentiellement en conflit avec les principes fondamentaux du pré-rendu et du découplage. Ces principes principaux doivent-ils être mis à jour?
L'avenir de Jamstack présente plusieurs possibilités:
Les diverses perspectives de la communauté nécessitent un consensus et une voie claire. Sinon, un mélange d'options 3, 4 et 5 est probable. La passion entourant Jamstack est indéniable et les innovations sont passionnantes. Ce qui est nécessaire est un accord sur une voie à suivre.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!