Les CMS de Jamstack ont ​​enfin grandi!

Cet article résume la présentation Brian's Connect.tech 2019 (diapositives disponibles en téléchargement). Il explore l'évolution des CMS Jamstack, en se concentrant sur le passage des outils centrés sur les développeurs en solutions adaptées aux créateurs de contenu non techniques.

Les développeurs saisissent facilement les avantages de Jamstack: vitesse (ressources statiques servies à partir d'un CDN), sécurité (aucun composant côté serveur à compromettre) et le développement / déploiement rationalisé. Cependant, le flux de travail de la création de contenu a présenté des défis initiaux. Alors que les CMS traditionnels étaient confrontés à la critique des développeurs, les premières solutions de Jamstack ont ​​souvent accablé les utilisateurs non techniques.

Initialement: un écosystème axé sur les développeurs

Les générateurs de sites statiques (Jekyll, Hugo, Gatsby) ont gagné en popularité en raison de l'adoption des développeurs. Il s'agissait généralement de projets construits, entretenus et peuplés au contenu. Comme indiqué dans un rapport O'Reilly de 2015:

Des générateurs de sites statiques sont conçus pour les développeurs. Il est peu probable que les non-développeurs soient à l'aise avec Markdown, YAML ou JSON - les formats utilisés pour le contenu et les métadonnées.

Même en 2017 (O'Reilly Book co-écrit avec Raymond Camden), les premiers outils comme Jekyll Admin et Netlify CMS étaient immatures par rapport aux éditeurs WYSIWYG dans des plateformes comme WordPress. L'expérience d'édition a exigé Markdown et d'autres compétences en langage de balisage. Cette adoption limitée traditionnelle.

La phase de maturation: CMS basée sur GIT et API-First

Au cours des prochaines années, deux tendances ont transformé le paysage de Jamstack: la montée des CMS à base de GIT et des CMS sans tête d'abord.

Netlify CMS (open-source) illustre une approche basée sur GIT. Au lieu du stockage de contenu traditionnel, il fournit des outils pour modifier Markdown, YAML et JSON, en commettant des modifications directement dans le référentiel, déclenchant une reconstruction d'un site. D'autres options Web comme la foresterie existent.

L'API-First CMSS (Contentful, Datocms, Sanity) offre une expérience d'édition plus traditionnelle, le stockage du contenu et le fournissant via API à n'importe quel frontage. Ce découplage fonctionne bien avec Jamstack, séparant la gestion du contenu de l'affichage frontal. Beaucoup s'intègrent aux générateurs de sites statiques populaires. Headlesscms.org propose une liste complète des outils disponibles. Le post de Bejamas fournit une comparaison détaillée des CMS basés sur GIT vs API-First.

Bien que ces créations de contenu améliorées, la déconnexion entre l'édition backend et l'affichage du frontend restait. L'absence de rétroaction visuelle immédiate, associée aux temps de reconstruction, a créé un flux de travail imparfait.

The Future: Édition et aperçu du frontend

JAMSTACK_CONF_SF Présentation des outils combler cet écart. TinACMS de Forestry (open-source) offre une expérience d'édition de frontend WYSIWYG pour les sites Gatsby et Next.js à l'aide de CMSS à base de GIT. Stackbit Live (Stackbit, où je suis un défenseur du développeur) propose une solution CMS et un générateur de site statique-Ambaratrice pour l'édition et l'aperçu de la page.

Ces avancées démontrent la viabilité de "Jamstack sans tête" comme une véritable alternative aux CMS traditionnels. Le compromis entre l'expérience des développeurs et la convivialité du rédacteur en chef diminue. D'ici 2020, les CMS de Jamstack avaient mûri considérablement. ??‍?

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!