5 mythes sur Jamstack

Jamstack n'est pas une nouvelle chose. Bien que le terme ait officiellement émergé en 2016, la technologie et l'architecture qu'elle décrit existent depuis longtemps. Récemment, Jamstack a reçu une attention généralisée, et les principaux sites Web et publications ont publié des rapports connexes, et de nombreuses activités, newsletters, podcasts, etc. émergent qui se concentrent sur Jamstack. En tant que développeur qui suit de près Jamstack, j'ai même observé une augmentation significative des discussions connexes sur Twitter, dont beaucoup sont d'abord exposées au concept.

Des discussions à chaud s'accompagnent également de critiques. Certaines des critiques sont justifiées, et je vais parler de certains d'entre elles plus tard, mais d'autres semblent être basées sur certains des malentendus communs persistants sur Jamstack, et c'est exactement ce que je vais d'abord résoudre. Jetons donc un coup d'œil à cinq malentendus courants sur Jamstack que j'ai rencontrés et les réfuter un par un. Comme de nombreuses idées fausses, elles sont généralement basées sur des situations réelles, mais conduisent à de fausses conclusions.

Misonctant 1: Jamstack n'est qu'un emballage de remplacement pour les sites Web statiques

Jamstack 99,9% est le marketing de marque et 0,1% est un contenu réel. ?? https://www.php.cn/link/33f976eca39cccf5a14627fc9f6cf1b9

- Nicole Sullivan - Black Lives Matter (@Stubbornella) 9 février 2020

Oui, comme je l'ai mentionné plus tôt, le terme «Jamstack» est sans doute un reconditionnement de ce que nous appelions auparavant «sites Web statiques». Ce n'est pas destiné à induire en erreur ou à vendre des produits qui n'ont pas encore été entièrement formés - bien que le contraire. Le terme «site Web statique» n'a pas depuis longtemps été en mesure de décrire ce que les gens construisent. Les sites Web construits avec le générateur de sites Web statique (SSG) contiennent souvent une variété de contenu et de fonctionnalités dynamiques.

Les sites Web statiques sont principalement considérés comme des blogs et des documents, et leur interface utilisateur est principalement fixe. La portée de l'interaction peut être juste des commentaires intégrés et des formulaires de contact. D'un autre côté, le site Web de Jamstack comprend des fonctions telles que l'authentification des utilisateurs, le contenu dynamique, le commerce électronique, le contenu généré par l'utilisateur, etc.

Besoin de preuves? Certaines sociétés et sites Web bien connus construits avec Jamstack incluent Smashing Magazine, Sphero, Postman, Prima, Impossible Foods et Tinet pour n'en nommer que quelques-uns.

Misonding 2: le site Web de Jamstack est fragile

Jay Freestone, dans l'article "Ask About Jamstack: vous pourriez avoir besoin d'un backend"

La lecture de la liste de dépendances du magazine Smashing est comme Node_Modules sur le serveur, notamment Algolia, GoCommerce, Gotrue, Gorell et divers services NetLify, pour n'en nommer que quelques-uns. Il est d'une grande valeur de savoir ce qui peut être l'externalisation (et quand), mais il convient de noter que la complexité est introduite dans la tentative évidente de «retourner à la fondation». Cela ne doit pas dire la vulnérabilité potentielle qui vient de s'appuyer sur de nombreux services tiers différents.

Oui, pour mettre en œuvre des fonctionnalités dynamiques qui distinguent Jamstack des sites Web statiques, les projets JAMSTACK s'appuient généralement sur divers services, y compris les services de premier parti ou de tiers. Certains croient que cela rend le site Web de Jamstack particulièrement vulnérable pour deux raisons. Tout d'abord, ils disent que si une pièce échoue, la fonctionnalité de l'ensemble du site Web se bloquera. Deuxièmement, votre infrastructure devient trop dépendante des outils et des services que vous n'avez pas.

Résolvons le premier argument. La majeure partie du contenu du site Web de Jamstack devrait être prélevée. Cela signifie que lorsqu'un utilisateur visite le site Web, la page et la plupart de son contenu seront livrées à partir du CDN en tant que ressource statique. C'est pourquoi Jamstack obtient la plupart de la vitesse et de la sécurité. Les fonctionnalités dynamiques - telles que le panier d'achat, l'authentification, le contenu généré par les utilisateurs et la recherche - comptent sur une combinaison de fonctions sans serveur et d'API pour fonctionner.

D'une manière générale, une application appellera une fonction sans serveur qui agit comme un backend pour se connecter à l'API. Par exemple, si nos capacités de commerce électronique s'appuient sur l'API de Stripe pour fonctionner et Stripe diminue, alors, oui, nos capacités de commerce électronique ne fonctionneront pas. Cependant, il est important de noter que le site Web ne baissera pas. Il peut gérer ce problème gracieusement en disant à l'utilisateur le problème. Les pages de rendu côté serveur qui reposent sur l'API Stripe pour le commerce électronique seront confrontées au même problème. En supposant que la page de rendu côté serveur appelle toujours le code rétro-end de manière asynchrone pour le paiement, il ne sera pas plus vulnérable ou moins fragile que la version Jamstack. D'un autre côté, si le rendu côté serveur s'appuie réellement sur les appels d'API, les utilisateurs peuvent être coincés en attente d'une réponse ou recevoir un message d'erreur (toute personne utilisant le réseau est très familière avec cela).

Quant au deuxième argument, il est difficile de mesurer le degré auquel les applications Web Jamstack et les applications de rendu côté serveur reposent sur des tiers. De nombreuses applications de rendu côté serveur comptent encore sur les API pour implémenter de nombreuses fonctionnalités, car cela permet un développement plus rapide, de levier des domaines d'expertise spécifiques des fournisseurs, des responsabilités de déchargement pour les problèmes de conformité juridiques et autres, etc. Dans ces cas, la version rendue côté serveur ne sera à nouveau plus dépendante ou moins dépendante que la version Jamstack. Certes, si votre demande repose principalement sur des solutions internes ou maison, les choses peuvent être différentes.

Malentendu 3: il est difficile de modifier le contenu

Kev Quirk, dans l'article "Pourquoi je n'utilise pas de générateur de sites Web statique":

Le fait de devoir SSH dans la boîte Linux, puis de modifier l'article sur VIM semble être une barrière très élevée à l'entrée en ce qui concerne l'écriture mobile. Que cela vous plaise ou non, le monde aujourd'hui est d'abord mobile, donc l'écriture mobile devrait être facile.

Ce problème ressemble à un héritage de sites Web statiques dans le passé. Pour être clair, vous n'avez pas besoin de SSH pour entrer la boîte Linux pour modifier le contenu de votre site Web. Il existe une grande variété d'options CMS sans tête, des produits entièrement gratuits et open source aux produits commerciaux qui fournissent du contenu pour les grandes entreprises. Les fonctionnalités d'édition qu'ils proposent sont comparables à tout CMS traditionnel (j'en ai déjà parlé). Le fait est qu'il n'y a aucune raison de modifier manuellement les fichiers Markdown, YAML ou JSON, même sur le projet de votre blog. Vous ne savez pas comment connecter toutes ces pièces? Nous avons aussi une solution!

Une critique raisonnable est que la CMS sans tête et le processus de construction peuvent entraîner la déconnexion entre le contenu en cours de modification et les modifications du site Web. Il est difficile de prévisualiser avec précision l'impact des modifications sur un site Web en direct avant la publication, ou sans un processus d'aperçu de build complexe. L'écosystème résout ce problème. Des entreprises comme Stackbit (où je travaille) construisent des outils qui rendent ce processus transparent.

Nous ne sommes pas les seuls à nous engager à résoudre ce problème. Les autres solutions incluent TinACMS et Gatsby Aperçu. Je pense que nous sommes sur le point de mettre en œuvre la simplicité de l'édition WYSIWYG sur un outil comme Wix sur Jamstack.

Malentendu 4: le référencement sur Jamstack est difficile

Kym Ellis, dans l'article "Ce que Jamstack signifie pour le marketing":

Abandonner le concept de plugin et choisir un site Web Jamstack "Just HTML" ne signifie pas que vous devez abandonner les fonctionnalités ou soudainement besoin d'apprendre le codage comme un développeur frontal pour gérer le site Web et son contenu.

Je n'ai pas vu ce problème se produire fréquemment ces dernières années, et je pense que c'est surtout une critique héritée de l'ère du site Web statique, lorsque la gestion des métadonnées liées au référencement impliqué de l'édition manuelle de Frontmatters basée sur YAML. Les gens craignent que faire correctement le référencement puisse devenir fastidieux et difficile à entretenir, surtout si vous souhaitez injecter différentes métadonnées dans chaque page unique générée, ou créer des données structurées comme JSON-LD, qui est essentielle pour améliorer votre liste de recherche.

Les progrès de la gestion de contenu de Jamstack abordent souvent la complexité du maintien des métadonnées SEO. En outre, puisque la page est pré-rendue, l'ajout d'un plan du site et JSON-LD est relativement simple, à condition que les métadonnées requises existent. Le pré-rendu facilite la création de ressources que les moteurs de recherche (c'est-à-dire Google) nécessitent des sites Web d'indexation, et ils sont également combinés avec les CDN, ce qui facilite la référence de performance qui améliore le classement des sites Web.

Fondamentalement, Jamstack est bon dans le "référencement technique" tout en fournissant aux éditeurs de contenu les mots clés et les autres métadonnées dont ils ont besoin. Pour une compréhension plus complète de Jamstack et SEO, je recommande fortement de consulter le guide Jamstack SEO de Bejamas.

Malentending 5: Jamstack nécessite beaucoup de frameworks javascript

Un beau site Web qui promeut les avantages de "Jamstack" est très utile si vous essayez de vendre un site Web normal à la direction obsédée par les derniers cadres.

- JDietrich, Hacker News

Récemment, Jamstack semble être devenu synonyme de frameworks JavaScript frontal. En effet, bon nombre des solutions les plus célèbres reposent sur des cadres frontaux, notamment Gatsby (React), Next.js (React), Nuxt (Vue), Vuepress (Vue), Gridome (Vue) et Scully (Angular). Cela semble être exacerbé par la confusion à propos de "J" dans Jamstack. Bien qu'il signifie JavaScript, cela ne signifie pas que toutes les solutions JAMSTACK sont basées sur JavaScript, et cela ne signifie pas qu'ils nécessitent tous des cadres NPM ou JavaScript.

En fait, bon nombre des outils les plus utilisés ne sont pas construits avec JavaScript, en particulier Hugo (Go), Jekyll (Ruby), Pelican (Python) et le Bridgetown récemment publié (Ruby). Dans le même temps, des outils comme Eleventy sont construits avec JavaScript, mais ne comptent pas sur le framework JavaScript. Aucun de ces outils ne prévient l'utilisation de frameworks JavaScript, mais ils n'en ont pas besoin.

Le point ici n'est pas d'abandonner les cadres JavaScript ou d'utiliser leurs outils. Ce sont d'excellents outils qui sont utilisés avec succès par de nombreux développeurs. Les cadres JavaScript peuvent être des outils très puissants qui peuvent simplifier certaines tâches très complexes. Le point ici est simplement que l'idée d'exiger un framework JavaScript pour utiliser Jamstack est erronée - Jamstack a 460 styles!

Où nous pouvons nous améliorer

Est-ce vrai? Jamstack est un monde idéal de développement Web où tout est non seulement parfait, mais c'est très facile. Malheureusement, pas. Jamstack a beaucoup de critiques raisonnables.

Simplicité

Sebastian de Deyne, dans l'article "Les choses à penser (et aux questions) après avoir traité avec Jamstack":

D'après mon expérience, Jamstack (JavaScript, API et Tags) est génial jusqu'à ce que ce ne soit plus génial. Quand un jour je dois ajouter du contenu dynamique - et ce jour vient toujours - je commence à me gratter la tête.

Pour être honnête: il n'est pas facile de commencer avec Jamstack. Bien sûr, il peut ne pas être particulièrement difficile de créer un blog ou un simple site Web à l'aide d'un générateur de sites Web statique. Mais, essayant de créer un vrai site Web avec toutes les fonctionnalités dynamiques, les choses se compliquent rapidement.

Vous rencontrez généralement de nombreuses options pour effectuer des tâches, ce qui rend difficile la pesée des avantages et des inconvénients. L'un des meilleurs aspects de Jamstack est qu'il n'est pas normatif, mais cela peut le rendre inaccessible, laissant l'impression qu'il peut ne pas convenir à des tâches complexes.

Service de reliure

Lorsque vous commencez vraiment à construire ces fonctionnalités dynamiques, votre site Web peut finir par s'appuyer sur une gamme de services et d'API. Vous pouvez appeler CMS sans tête pour obtenir du contenu, appeler des fonctions sans serveur pour que les API effectuent des transactions de paiement, des services de recherche comme des algolies, etc. Le rassemblement de toutes ces pièces peut être une tâche très complexe. Ajoutant au fait que chaque section a généralement son propre tableau de bord et les mises à jour API / SDK, les choses deviennent encore plus compliquées.

C'est pourquoi je pense que des services comme Stackbit et des outils comme Redwoodjs sont importants car ils réunissent les différentes parties derrière le site Web de Jamstack et facilitent la création et la gestion de ces pièces.

Surutilisation des cadres

À mon avis, notre dépendance à l'égard des cadres JavaScript dans le développement frontal moderne a été indispensable à remettre en question récemment. Comme l'indique le récent article de Tim Kadlec, il y a des compromis. Comme je l'ai déjà dit, vous n'avez pas besoin d'un framework JavaScript pour fonctionner dans Jamstack.

Cependant, cette impression survient parce que de nombreux outils JamStack reposent sur des cadres JavaScript, et la façon dont nous enseignons Jamstack est principalement axée sur l'utilisation des frameworks. Je comprends la raison à cela - de nombreux développeurs de Jamstack connaissent les frameworks JavaScript et il est impossible d'enseigner chaque outil, donc vous choisissez celui que vous aimez. Néanmoins, je pense personnellement que le succès à long terme de Jamstack dépend de sa flexibilité, ce qui (bien que j'ai mentionné la simplicité ci-dessus) signifie que nous devons présenter les différentes solutions qu'il offre - que ce soit en utilisant des cadres JavaScript ou non.

Où aller ensuite

Wow, tu l'as fait! Je sais que j'ai beaucoup à dire, peut-être plus que ce que je n'ai réalisé quand j'ai commencé à écrire, donc je ne vous dérangerai pas avec de longues conclusions, à part dire, évidemment, j'ai présenté ces malentendus du point de vue de quelqu'un qui est très convaincu de la valeur de Jamstack, malgré ses défauts!

Si vous cherchez un bon article sur le moment et le moment de ne pas choisir Jamstack plutôt que le rendu côté serveur, consultez ou non l'article récent de Chris Coyier? 》.

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!