Jamstack CMSS sind endlich erwachsen!

Dieser Artikel fasst die Präsentation von Brian Connect.tech 2019 zusammen (die zum Download verfügbaren Folien). Es untersucht die Entwicklung von JamStack CMSS und konzentriert sich auf die Verschiebung von Entwickler-zentrierten Tools zu Lösungen, die für nicht-technische Inhalte erstellt werden.

Entwickler erfassen die Vorteile des Jamstack leicht: Geschwindigkeit (statische Ressourcen, die von CDN serviert), Sicherheit (keine serverseitigen Komponenten für Kompromisse) und optimierte Entwicklung/Bereitstellung. Der Workflow der Inhaltserstellung stellte jedoch anfängliche Herausforderungen vor. Während die traditionelle CMSS-Entwicklerkritik konfrontiert war, belasteten frühe Jamstack-Lösungen häufig nicht-technische Benutzer.

Zunächst: ein Entwickler ausgerichtetes Ökosystem

Statische Site -Generatoren (Jekyll, Hugo, Gatsby) wurden aufgrund der Einführung von Entwicklern an Popularität gewonnen. Diese waren in der Regel Entwickler-, Pflege- und inhaltsbekannte Projekte. Wie in einem O'Reilly -Bericht von 2015 angegeben:

Statische Site -Generatoren sind für Entwickler gebaut. Es ist unwahrscheinlich, dass Nichtentwickler mit Markdown, Yaml oder JSON vertraut sein-den Formaten, die für Inhalte und Metadaten verwendet werden.

Sogar 2017 (O'Reilly Book, die mit Raymond Camden zusammengestellt wurden) waren frühe Tools wie Jekyll Admin und Netlify CMS im Vergleich zu WYSIWYG-Redakteuren in Plattformen wie WordPress unreif. Die Bearbeitungserfahrung erforderte Markdown- und andere Markup -Sprachkenntnisse. Diese begrenzte Mainstream -Akzeptanz.

Die Reifungsphase: GIT-basierte und API-erste CMSS

In den nächsten Jahren veränderten zwei Trends die Jamstack-Landschaft: den Aufstieg von CMS-basierten CMS und API-First Headless CMSS.

Netlify CMS (Open-Source) veranschaulicht einen GIT-basierten Ansatz. Anstelle eines herkömmlichen Inhaltsspeichers bietet es Tools zum Bearbeiten von Markdown, YAML und JSON, wodurch Änderungen direkt am Repository verantwortlich sind und einen Wiederaufbau eines Standorts auslösen. Weitere webbasierte Optionen wie Forstwirtschaft gibt es.

API-First CMSS (intastful, Datocms, Sanity) bieten ein traditionelleres Bearbeitungserlebnis, speichern Inhalte und die Bereitstellung dieser über API für jede Frontend. Diese Entkopplung funktioniert gut mit JamStack und trennt die Content -Management von Frontend Display. Viele integrieren sich in beliebte statische Site -Generatoren. HeadlessCms.org bietet eine umfassende Liste verfügbarer Tools. Bejamas 'Post bietet einen detaillierten Vergleich von GIT-basierten vs. API-ersten CMS.

Während diese verbesserten Inhaltserstellung blieb die Trennung zwischen Backend -Bearbeitung und Frontend -Display. Das Fehlen eines sofortigen visuellen Feedbacks in Verbindung mit den Wiederaufbauzeiten führte zu einem unvollkommenen Workflow.

Die Zukunft: Frontend -Bearbeitung und Vorschau

JAMSTACK_CONF_SF ZUM ERFOLGUNG TOLS, die diese Lücke überbrücken. Die Tinacms (Open-Source) von Forestry bietet ein Wysiwyg-Frontend-Bearbeitungserlebnis für Gatsby- und Next.js-Standorte mit GIT-basierten CMS. Stackbit Live (Stackbit, wo ich ein Entwickleranwalt bin) bietet eine CMS- und statische Site-Generator-Agnostic-Lösung für die Bearbeitung und Vorschau auf der Seite.

Diese Fortschritte zeigen die Lebensfähigkeit von "Jamstack Headless" als echte Alternative zu herkömmlichem CMSS. Der Kompromiss zwischen Entwicklererfahrung und der Benutzerfreundlichkeit des Inhaltseditors verringert sich. Bis 2020 war Jamstack CMSS signifikant gereift. ??‍?

Das obige ist der detaillierte Inhalt vonJamstack CMSS sind endlich erwachsen!. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!