L'histoire des CMS Jamstack remonte aux années 90. Dans cet article, nous faisons un voyage dans le passé pour voir comment nous sommes arrivés aux CMS Jamstack modernes que nous avons aujourd'hui, et où ils se dirigent dans la prochaine décennie.
Le premier site Web au monde a été créé à partir de fichiers HTML statiques créés dans un éditeur de texte. Bien qu'il semble modeste, il a jeté les bases du Web que nous avons aujourd'hui. 30 ans plus tard, et la technologie des sites Web a considérablement changé – nous avons des images, des feuilles de style, JavaScript, des vidéos en streaming, AJAX, des animations, des WebSockets, WebGL, des coins arrondis en CSS – la liste est longue.
Sir Tim Berners-Lee. Je n'aurais jamais pu imaginer l'endroit étrange et merveilleux que deviendrait le World Wide Web et à quel point il ferait partie de notre vie quotidienne. Pourtant, malgré tous ces développements technologiques, il est intéressant de noter que beaucoup d'entre nous servent toujours des sites de la même manière que Tim l'a fait avec le tout premier site Web – un serveur Web servant des fichiers de sites Web statiques.
Tout au long du Web. historique, les sites Web statiques ont toujours été une option populaire en raison de leur simplicité, de leur évolutivité et de leur sécurité. Cependant, contrairement aux premiers jours du Web, les sites statiques ne sont plus réservés aux développeurs travaillant dans un éditeur de code. Il existe maintenant une vaste gamme de CMS Jamstack disponibles, qui offrent tous les avantages des sites statiques tout en permettant aux personnes non techniques de mettre à jour le contenu.
Au fil des ans, il y a eu de nombreuses approches et évolutions différentes de CMS statiques et Jamstack. Dans cet article, nous parcourons le chemin de la mémoire pour examiner les CMS qui ont donné naissance aux CMS Jamstack que nous avons aujourd'hui et jeter un coup d'œil au-delà de l'horizon de ce qui va suivre.
Les années 90
Au cours des années 90, nous vu deux systèmes de gestion de contenu pour les sites statiques — Microsoft FrontPage en 1996 et Macromedia Dreamweaver en 1997. Je me souviens très bien avoir reçu un magazine PC pour mon anniversaire avec un essai de Dreamweaver. Reconstituer un site Web à l'aide d'un éditeur WYSIWYG et voir le code qu'il a généré a été une expérience fascinante et éducative qui a suscité un intérêt initial pour la conception de sites Web. . L'idée de glisser-déposer des composants de site Web tout en gardant le contrôle du code HTML était révolutionnaire à l'époque.
La maintenance des mises en page est devenue un problème particulier pour les sites statiques. Par exemple, disons que vous avez un site Web et que vous souhaitez modifier votre navigation. Vous auriez besoin de faire ce changement sur chaque page. À ce stade, les sites Web générés dynamiquement avaient déjà résolu ce problème avec les inclusions.
Dreamweaver 4 a introduit des régions modifiablesce qui était la première incursion dans la séparation du contenu de la mise en page sur un site Web statique. Désormais, vous pouvez gérer des sites plus volumineux et même confier l'édition de contenu à quelqu'un d'autre sans craindre qu'il ne brise le reste du site. FTP. Je me souviens de la lutte pour obtenir ma configuration FTP exactement correcte dans Dreamweaver pour l'hébergement gratuit et publicitaire que j'avais trouvé. Mais, quand cela fonctionnait, c'était magique. J'avais mon site Web avec des photos amusantes et des liens vers des sites Web préférés en direct sur Internet, et mieux encore, je pouvais éditer directement sur le serveur.
Feature Panel" width="480" height="697″/>
]Les années 00
Dans les années 2000, nous avons eu une confrontation entre deux plateformes de publication de blogs populaires — MovableType en 2001 et WordPress en 2003. Ce n'était pas seulement une bataille entre propriétaires et open source mais aussi statique vs dynamique. Il est sûr de dire que WordPress, la plate-forme qui alimente désormais 40 % d'Internet, a remporté cette bataille, mais MovableType a ouvert la voie aux CMS Jamstack à l'avenir.
MovableType était l'un des premiers générateurs de sites statiques sur le marché, bien que ce terme ne devienne populaire qu'en 2008. Ben et Mena Trott ont créé MovableType en raison d'une « insatisfaction avec les CMS de blogs existants – performances , stabilité." À ce jour, ces deux points sont des raisons courantes pour passer d'un site dynamique à un site statique.
Ce qui est intéressant, c'est qu'il n'y avait que peu de mentions de sites statiques dans la documentation de MoveableType. Au lieu de cela, ils parlaient de « reconstruire » le site après tout changement. J'imagine qu'ils voulaient éviter la perception limitante du mot « statique ». C'est le même problème qui a conduit la communauté à adopter le terme « Jamstack ». Blogger & Open Diary. Cependant, MovableType était l'une des premières plates-formes largement disponibles que vous pouviez télécharger gratuitement et héberger vous-même. En outre, ils ont introduit une version hébergée de MovableType en 2003 appelée TypePad pour concurrencer d'autres plates-formes cloud populaires.
Avec MovableType, vous aviez tout ce dont vous aviez besoin pour gérer votre blog. Vous pouviez créer et mettre à jour des articles de blog, tout le contenu était directement HTML – les éditeurs WYSIWYG open source n'étaient pas disponibles à l'époque, et Markdown n'est apparu qu'en 2004.
Nous pouvons voir tous les os de les CMS Jamstack modernes ici. MovableType était vraiment avant son temps.
En 2006, Denis Defreyne a essayé de mettre en place une plate-forme de blog basée sur Ruby et a rencontré des problèmes de performances – "Ayant un VPS avec seulement 96 Mo de RAM, n'importe quel CMS basé sur Ruby fonctionnait extrêmement lentement. Un an plus tard, Denis lance Nanocun générateur de site statique qui simplifie le modèle de MovableType. Nanoc a supprimé l'interface utilisateur et est à la place un programme que vous exécutez sur la ligne de commande.
Pour autant que je sache, il s'agit du premier générateur de site statique moderne bien que nous soyons encore à un an de forger ce terme. À l'époque, Nanoc parlait de compiler les fichiers sources en HTML :
Il fonctionne sur des fichiers locaux, et ne s'exécute donc pas sur le serveur. nanoc "compile" les fichiers sources locaux en HTML en évaluant eRuby, Markdown, etc.
Nanoc disposait de nombreuses fonctionnalités de générateur de site statique (SSG) que nous tenons maintenant pour acquises :
- Layouts
Créer des éléments de mise en page à l'aide de l'ERB de Ruby langage de modèle. - Métadonnées de la page
Un fichier YAML distinct pour stocker le titre et d'autres métadonnées pour une page. L'avant-propos n'était pas encore une chose. - Prise en charge de Markdown
Écrire du contenu dans Markdown et le transformer en HTML lors de la construction. - Modèles
Une fonctionnalité similaire aux archétypes d'Hugo. - Plugins
Connu sous le nom de bibliothèques ; étendez le générateur de site statique pour vos propres besoins.
À la fin de 2008, Tom Preston-Werner annonce Jekyll – un générateur de site statique simple, compatible avec les blogs. Il a pris les idées de Nanoc et les a poussées encore plus loin avec deux innovations importantes :
- Front Matter
Au lieu de métadonnées vivant dans un fichier séparé, vous pouvez désormais avoir un petit extrait YAML en haut d'un fichier. - Connaître les blogs
Créez des articles avec des fichiers Markdown. Jekyll les intègre dans un tableau que vous pouvez parcourir et paginer pour créer un blog.
Nanoc et Jekyll ont révolutionné l'avenir de l'outillage de site statique à leur manière. Tout d'abord, Nanoc a introduit la configuration, les mises en page et le contenu d'un site sous forme de fichiers statiques. L'avantage de faire cela est que le code source du site entier peut vivre dans Git. Jekyll est allé plus loin en fournissant plus de structure autour du contenu. Vous pouvez maintenant utiliser GitHub comme CMS. Ajouter un nouvel article de blog est aussi simple que de créer un nouveau fichier Markdown dans GitHub, d'écrire votre contenu et de le valider.
Les 10s
En 2012, Dave Cole a publié un article sur Comment nous construisons des sites Web gratuits avec CMS . L'article détaille comment Development Seed a déplacé ses sites Web de Drupal vers Jekyll et comment ils utilisent Prose.io pour gérer le contenu. Development Seed a construit Prose.io pour permettre aux rédacteurs de contenu de contribuer plus facilement aux sites Web Jekyll.
Prose.io se synchronise avec votre référentiel GitHub et fournit une interface graphique simple pour les tâches de contenu quotidiennes telles que la mise à jour de l'avant-propos, la rédaction de Markdown, la création de publications et le téléchargement de fichiers. De plus, les mises à jour de contenu sont enregistrées sur GitHub, créant un flux de travail étroit entre les développeurs et les rédacteurs de contenu.
Prose a transformé Jekyll d'un outil permettant aux développeurs de créer des blogs en une puissante plate-forme de publication de contenu. De plus, cela a déclenché une décennie d'entreprises poussant la publication de contenu de générateur de sites statiques au niveau supérieur.
Il existe maintenant des centaines de CMS Jamstack modernes parmi lesquels choisir, chacun avec ses propres avantages et compromis. Les CMS Jamstack adoptent généralement l'une des trois approches suivantes pour gérer le contenu d'un site Web statique :
Package SSG/CMS
Revenant à MovableType, ces plates-formes gèrent le contenu et restituent elles-mêmes le site statique. Le contrôle de l'ensemble de la pile signifie que ces CMS peuvent fournir une expérience étroitement intégrée. Attendez-vous à des aperçus en direct, à une configuration simple et à des conventions solides.
L'inconvénient du package SSG/CMS est qu'ils sont regroupés. Vous aimerez peut-être l'expérience d'édition, mais détestez la partie génération de sites Web. Il convient de noter que vous pouvez jeter la partie SSG sur certaines de ces plates-formes et l'utiliser uniquement comme API de contenu.
Exemples : StatamicPubliiWordPress (avec Simply Static plugin).
Content API
Ces les plateformes fournissent du contenu en tant que service. Ils offrent de nombreux types de champs différents que vous pouvez utiliser pour reconstituer le contenu de vos pages. En plus de cela, les plates-formes d'API de contenu fournissent des API sophistiquées pour récupérer le contenu.
Lorsque vous exécutez une génération SSG, vous téléchargez le contenu à partir de l'API de contenu et interagissez avec lui comme vous le feriez avec un fichier de données. L'avantage des API de contenu est que vous pouvez réutiliser le contenu dans de nombreuses expériences numériques différentes. En plus de cela, vous pouvez gérer des quantités massives de contenu et avoir des relations profondes entre les éléments de contenu.
L'inconvénient est que votre contenu vit sur un tiersvous êtes donc à sa merci pour tout les temps d'arrêt, les modifications de l'API ou la façon dont vous interagissez avec votre contenu. Enfin, comme l'interface d'édition est abstraite du cas d'utilisation final du contenu, il peut y avoir une déconnexion entre les champs de l'API de contenu et ce que vous voyez affiché sur une page Web.
Exemples : ContentfulPrismicStrapi.
Git-Based CMS
Ces plates-formes adoptent une approche similaire à Prose .io. Vous connectez votre référentiel Git, ils récupèrent les fichiers de votre site Web et créent une interface d'édition autour d'eux. Lorsque vous enregistrez les modifications, les fichiers sont renvoyés vers votre référentiel. L'avantage de cette approche est que votre référentiel Git contient l'intégralité de votre site et tout son contenu.
Les CMS basés sur Git apportent toute la puissance des Flux de travail Git aux rédacteurs de contenu non techniques. L'inconvénient est que tout vit dans votre référentiel, donc si vous souhaitez réutiliser le contenu sur plusieurs expériences numériques, vous devrez créer des points de terminaison JSON sur votre site statique. Les référentiels hébergés ont également une limite supérieure d'environ 2 Go, vous devrez donc peut-être utiliser un service tiers pour les médias si vous disposez de nombreux actifs.
Exemples : CloudCannon (avertissement : je suis le co-fondateur), Netlify CMSTina
Où sont les CMS Jamstack aujourd'hui ?
SSG étaient à l'origine des outils permettant aux développeurs de créer des blogs personnels. C'était une approche simple qui donnait aux développeurs un contrôle total, mais vous aviez besoin d'une compréhension de base du développement Web pour contribuer aux sites. Au cours de la dernière décennie, l'évolution rapide de Jamstack et du CMS Jamstack a contribué à propulser Jamstack dans les cas d'utilisation grand public. Ces cas d'utilisation incluent :
Documentation
Les développeurs attendent beaucoup des sites de documentation, et une bonne expérience aidera à les convaincre. Jamstack vous met sur la bonne voie pour créer des sites de documentation que les développeurs adorent :
- Le développement est rapideet il y a plus de temps pour peaufiner.
- Markdown est un excellent format de documentation rendu encore plus facile avec un bon CMS.
- Le site se chargera en un instant.
- Le contenu du site habite dans un référentiel qui permet à la communauté des développeurs de suggérer des améliorations.
Des entreprises telles que TwitchRackspace et Linode profitent des avantages de Jamstack pour leurs sites Web de documentation.
eCommerce
Visiteurs d'un Les sites de commerce électronique sont sur le point de payer de l'argent. Des temps de chargement lents ou pire, des temps d'arrêt peuvent les faire chercher ailleurs. Des plateformes telles que SnipcartCommerceLayerheadless Shopify et Stripe vous permettent de gérer les produits dans une interface utilisateur conviviale tout en profitant de la avantages de Jamstack :
- La célèbre étude d'Amazon a indiqué que pour chaque 100 ms de latence, ils perdent 1 % des ventes. Les sites Jamstack sont généralement parmi les plus rapides du Web.
- Lorsqu'un site de commerce électronique a des temps d'arrêt, il ne peut pas générer de ventes. Il y a beaucoup moins de pièces mobiles dans un site Jamstack, ce qui les rend plus faciles à garder en ligne.
- Les sites de commerce électronique itèrent constamment pour améliorer les taux de conversion. L'expérience des développeurs est au cœur de Jamstack, permettant aux développeurs d'apporter et de publier des modifications rapidement.
Victoria Beckham BeautyTeespring et Louis Vuitton utilisent tous Jamstack pour améliorer leur expérience de commerce électronique.
Sites Web d'entreprise
Sites Web d'entreprise. sont la porte d'entrée en ligne d'une entreprise. Faire bonne impression avec un site Web à chargement rapide et bien construit peut donner un avantage sur les concurrents. La plupart des CMS Jamstack que nous avons mentionnés ont les fonctionnalités et les flux de travail dont les entreprises en croissance ont besoin. Il s'agit notamment des traductions, des workflows de publication et de la modélisation de contenu complexe.
NetflixPeloton et Intercom itèrent plus rapidement sur leurs sites Web d'entreprise grâce aux CMS Jamstack et Jamstack.
Blogs à grande échelle
Statique les générateurs de sites sont souvent catalogués comme une solution pour les petits sites Web. Grâce à la vitesse de création de générateurs de sites statiques comme Hugo et les CMS modernes Jamstack conçus pour gérer de grandes quantités de contenu, même des blogs de premier plan comme Smashing Magazineweb.dev et JFK International Air Terminal peut profiter d'une approche Jamstack.
Gouvernement
Quelle meilleure façon de promouvoir la transparence en ligne au sein du gouvernement que d'avoir un site Web dont le contenu se trouve dans un référentiel public ? Il existe un historique complet de tous les changements et les citoyens peuvent suggérer des améliorations. Vous pouvez vraiment avoir un site Web gouvernemental créé par le peuple, pour le peuple.
digital.govSingapore Together et CIO.gov ont tous des dépôts publics sur GitHub, dans lesquels vous pouvez parcourir chaque modification apportée ou suggérer un mise à jour du contenu.
Sites Web clients
Les sites Web destinés aux clients doivent être exceptionnellement simples à mettre à jour. Les CMS Jamstack avec un éditeur visuel comme StoryblokCloudCannon et Tina permettent aux clients non techniques de gérer le contenu de leur site Web Jamstack de manière intuitive.
Wilto Makes FoodDown ThymeThe Bottle Room Bar tirent parti de la même approche Jamstack que les entreprises leaders mondiales.
Comment Le CMS Jamstack moderne se compare-t-il aux autres CMS populaires ?
À un niveau élevé, il existe deux façons de mettre un site Web en ligne :
- Vous sélectionnez un modèle, le personnalisez en fonction de votre marque et saisissez votre contenu.
- ]Vous travaillez avec un concepteur et un développeur pour créer un site Web sur mesure.
Bien sûr, l'approche par modèle est moins chère. Pour moins de 100 $, vous pouvez obtenir un thème/modèle de haute qualité et mettre votre site Web en ligne en quelques minutes. C'est un excellent moyen pour un particulier ou une petite entreprise de mettre un site Web en ligne.
Un site Web sur mesure de qualité commencera à 1 000 $ et peut facilement atteindre 100 000 $ +. Un site Web unique avec des fonctionnalités personnalisées vous aide à vous démarquer d'un océan de millions de sites Web, ce pour quoi de nombreuses entreprises sont prêtes à payer.
Squarespace, Wix et Weebly
Les plateformes de création de sites Web se concentrent sur le approche modèle. Ils s'adressent au marché de masse et offrent à quiconque un moyen de créer un site Web sans développeur.
Il ne fait aucun doute que Jamstack est une technologie axée sur les développeurs. Lorsque nous parlons de générateurs de sites statiques, de régénération incrémentielle ou d'invalidation instantanée du cache, cela suffit à faire briller les yeux du profane. J'ai du mal à voir un avenir où le fleuriste local a besoin d'un site Web et choisit une approche Jamstack sans l'implication du développeur.
Même avec le système de gestion de contenu le plus intuitif pour Jamstack où vous pouvez sélectionner un modèle, glisser-déposer des composants et en ligne modifier le contenu, les avantages de Jamstack pour ce public par rapport aux constructeurs de sites Web sont trop techniques. Bien sûr, ce sera rapide, sécurisé et facile à modifier ; Cependant, l'utilisateur final se moque bien de savoir s'il utilise Jekyll, Hugo, Gatsby ou un backend dynamique.
Les avantages d'un site Web à chargement rapide, de DevOps automatisés, d'une disponibilité plus élevée et de cycles de développement plus rapides sont bien plus séduisant pour les entreprises qui construisent des projets web sur mesure. En ce sens Je ne vois pas beaucoup de chevauchement entre les constructeurs de sites Web et les cas d'utilisation de Jamstack.
WordPress
WordPress a capturé les deux flux de travail. Quelqu'un de complètement non technique peut créer un modèle avec divers plugins et mettre son site Web en ligne en une journée. WordPress possède également des API riches que les développeurs utilisent pour créer des expériences Web uniques et sur mesure. Ce large éventail de cas d'utilisation a contribué à faire croître WordPress pour alimenter près de 40% d'Internet.
Dans la plupart des articles sur Jamstack, vous trouverez une section qui jette WordPress sous le bus. On parle souvent de la lenteur, de l'insécurité et de la complexité de WordPress. Je crois que c'est une conversation d'approche plus fondamentale. On parle souvent de statique contre dynamique et de monolithe contre découplé. WordPress est le CMS le plus populaire, c'est donc souvent la cible.
Il n'y a pas de Jamstack vs WordPress. La vérité est que vous pouvez profiter des avantages de Jamstack tout en utilisant WordPress comme CMS. Les plateformes d'hébergement comme Shifter et Strattic transforment votre site WordPress en un site Web statique. Vous pouvez également utiliser un plugin pour générer un site statique ou utiliser WordPress en tant que CMS sans tête pour remplir du contenu dans un générateur de site statique.
C'est également relativement simple à migrer de WordPress vers un CMS Jamstack . Pour un CMS Git, vous souhaiterez migrer les articles de blog et les ressources vers des fichiers Markdown qui vivent avec le générateur de site statique de votre choix. Heureusement, de nombreux SSG ont des outils d'importation qui rendent cela facile. Pour un CMS Content API, certains d'entre eux ont un outil d'importation de données sinon, vous pouvez toujours écrire un script pour extraire des données de WordPress et les enregistrer dans votre Content API.
Webflow
Webflow est curieux car il permet concepteurs pour créer des sites Web sur mesure sans développeurs, mais c'est trop technique pour être considéré comme un constructeur de sites Web. C'est une plate-forme robuste qui chevauche certainement certains cas d'utilisation de Jamstack. En fin de compte, il s'agira de contrôler .
Si vos besoins correspondent aux capacités de Webflow, cela pourrait être une bonne solution pour vous. Bien qu'il puisse faire beaucoup, il a des limites qu'un développeur peut dépasser. Si vous avez besoin d'un développeur, adopter une approche Jamstack est l'un des moyens les plus efficaces d'exploiter vos ressources en personnel.
Drupal
Drupal n'est pas seulement un CMS. C'est un framework puissant qui peut résoudre même les cas d'utilisation les plus complexes, en l'orientant davantage vers des solutions sur mesure pour les problèmes d'entreprise plutôt que vers des sites d'information beaucoup plus petits.
Les CMS Jamstack modernes ont de nombreuses études de cas réussies de ces derniers. sites Web plus petits. Pour les cas d'utilisation d'entreprise plus complexes, nous avons moins d'exemples. Il y a certaines limitations que Jamstack doit surmonter pour rivaliser avec une installation Drupal importante :
Durée de construction
La pré-construction d'un site à l'aide d'un générateur de site statique prend du temps. Pour un petit site, une construction peut prendre quelques secondes. Un site de 100 000 pages peut prendre plus d'une heure à créer. Attendre une heure pour que votre site soit construit après chaque modification n'est pas un workflow de développement viable.
Les générateurs de sites statiques ont plusieurs stratégies pour gérer les longs temps de constructiony compris la mise en cache des builds, les builds incrémentiels, le rendu dynamique persistant , et le sharding de sites Web. Le choix de l'outillage a également un impact important sur le temps de construction. Par exemple, l'utilisation d'un générateur de site statique basé sur Golang comme Hugo peut rapidement créer de grands sites, tandis que l'utilisation de quelque chose basé sur Ruby comme Jekyll peut avoir des difficultés. les stratégies s'améliorent constamment, ce qui ouvre des possibilités pour des cas d'utilisation plus étendus.
Fonctionnalité dynamique
Les sites Web volumineux et complexes ont généralement une forme de comportement dynamique. Les formulaires, les commentaires, la recherche et les points de terminaison d'API personnalisés sont tous essentiels pour Drupal. Pour de nombreux développeurs, il n'est pas évident de savoir comment les faire sur un site Jamstack.
Vous ne voulez peut-être pas faire appel à un tiers et vous avez besoin d'une solution sur mesure. Vous avez toujours des options avec Jamstack :
- Vous pouvez créer une API distincte avec laquelle votre site Jamstack interagit pour toute fonctionnalité dynamique.
- NetlifyVercelCloudFlare et AWS ont tous le concept de fonctions sans serveur exécutées sur les nœuds périphériques d'un CDN.
Autorisations affinées
Drupal dispose d'un système d'autorisations riche et extensible . Les grands sites ont de grandes équipes d'éditeurs de contenu, qui nécessitent un système d'autorisations approfondi.
Nous n'avons pas vu le même niveau de systèmes d'autorisations profonds dans un CMS Jamstack qu'il est possible avec Drupal, mais ce n'est qu'une question de temps. C'est une situation d'œuf de poule. Sans grands sites de contenu avec des équipes de contenu étendues, nous n'avons pas besoin de systèmes d'autorisation complexes. Lorsque nous verrons une plus grande adoption de sites de contenu dans Jamstack, les CMS Jamstack introduiront des systèmes d'autorisation approfondis pour correspondre à Drupal.
20s And Beyond
Les CMS Jamstack sont sur une trajectoire passionnante. Cependant, il reste encore un long chemin à parcourir pour devenir un moyen courant pour les entreprises de créer des sites Web. Alors, quels sont les problèmes que nous devons résoudre pour avoir un attrait plus large pour Jamstack ?
Édition de contenu intuitive
Les plateformes comme Squarespace et Webflow sont connues pour leurs expériences d'édition de contenu très intuitives. Quoi de plus simple que de rédiger du contenu directement sur votre site Web ? Aucune conjecture ou aperçu n'est nécessaire.
La gestion du contenu du site Web Jamstack a dérivé vers une approche déconnectée. Vous mettez à jour le contenu sur un ensemble de composants de champ abstrait qui ne représentent pas à quoi ressemblera ce contenu sur le site rendu. L'avantage de cette déconnexion est la réutilisation du contenu, mais vous sacrifiez l'expérience d'édition pour avoir cette flexibilité. Il n'y a aucune raison pour que nous ne puissions pas avoir une expérience d'édition similaire à Squarespace sur un site Web Jamstack. Lorsque nous le ferons, vous n'aurez plus à faire de compromis sur l'édition pour profiter des avantages de Jamstack. le processus de publication de contenu. Pour que Jamstack grandisse, nous avons besoin d'outils de contenu qui réduisent cette dépendance . Les éditeurs devraient pouvoir créer, gérer et publier du contenu sans développeur. Nous nous rapprochons de ce que les éditeurs deviennent complètement autonomes une fois qu'un site est configuré, mais il reste encore du travail à faire. sites Internet. Pourtant, ces workflows deviennent rapidement un problème dès que vous avez plusieurs contributeurs. C'est l'équivalent d'avoir une équipe de développeurs essayant de travailler sur une seule branche.
Git a révolutionné la façon dont les développeurs collaborent sur le contenu. Nous avons maintenant des flux de travail où les développeurs indépendants du monde entier peuvent se réunir et créer des logiciels de très haute qualité. Ces workflows changent la donnealors pourquoi ne pouvons-nous pas faire la même chose pour le contenu ? Les sites Jamstack sont statiques. Ils vivent dans un dépôt. Avec la bonne interface, nous pouvons apporter ces flux de travail à un tout nouveau public, poussant la collaboration de contenu bien au-delà de ce que tout CMS est capable de faire aujourd'hui.
Les développeurs examinent les demandes d'extraction à l'aide d'un code diff qui indique quel code a changé. Dans le processus de révision, vous pouvez avoir des conversations sur des lignes de code particulières et itérer jusqu'à ce qu'il soit au bon endroit pour fusionner dans la base de code principale. En plus de cela, il est courant d'exécuter une suite de vérifications d'état dans le cadre d'une demande d'extraction. Les vérifications d'état sont de petits programmes pour lisser, exécuter des tests ou toute autre chose que vous souhaitez mesurer. Les différences de code et les vérifications d'état sont des outils essentiels pour examiner le code source et s'assurer qu'il est cohérent et de haute qualité. Alors, comment prenons-nous ces idées et les amenons-nous à la gestion de contenu ?
Nous ne pouvons pas mettre des différences de code devant les éditeurs de contenu. Tout l'intérêt d'un CMS Jamstack est d'abstraire des concepts techniques. Nous pouvons cependant afficher des différences de contenu pour indiquer quel contenu a changé plutôt que le code source sous-jacent. Les différences visuelles sont une autre option et vous donnent un angle différent. Des plates-formes comme Percy le font déjà et vous donnent une vue au pixel près de ce qui a changé entre deux versions de pages Web.
En ce qui concerne la vérification statique du contenu, nous avons déjà de nombreux outils disponibles. Il y a tout, de la recherche de liens brisés, des balises alt manquantes, des vérifications SEO, des vérifications grammaticales et de la vérification de l'accessibilité. Nous avons besoin d'interfaces conviviales en plus de ces outils pour aider les éditeurs non techniques à identifier et à résoudre eux-mêmes les problèmes. L'intégration de ces outils et flux de travail dans les CMS Jamstack va changer la façon dont nous gérons le contenu sur le Web. cinq ans, nous avons vu un financement et des ressources importants propulser l'approche. Nous en sommes encore à l'adoption précoce de Jamstackmais je pense que nous approchons d'un point de basculement.
Le nombre de déploiements à grande échelle de Jamstack par des entreprises de renommée mondiale augmente de jour en jour. . Au fur et à mesure que les outils et les plates-formes s'améliorent, je ne peux que voir cette tendance s'accentuer. Il sera difficile de justifier ne pas utiliser Jamstack pour un site Web ou une application d'entreprise sur mesure au cours de la prochaine décennie.
Où pensez-vous que les CMS Jamstack seront en 2030 ?
Source link