JAMstack CMSs sind endlich erwachsen geworden!

Dieser Artikel basiert auf Brians Präsentation auf Connect.Tech 2019. Folien mit Sprechernotizen aus dieser Präsentation sind zum Download verfügbar.

Meiner Erfahrung nach finden Entwickler die Vorteile des JAMstack im Allgemeinen leicht verständlich. Websites sind schneller, da die Ressourcen statisch sind und von einem CDN geliefert werden. Websites sind sicherer, da kein Framework, keine Anwendungsserver oder Datenbanken kompromittiert werden können. Entwicklung und Bereitstellung können optimiert werden, da alle Teile, aus denen der Stack besteht, entbündelt sind. Und so weiter.

Was für Entwickler schwieriger zu verstehen sein kann, sind die Kompromisse, die dies oft für die Personen erfordert, die Inhalte erstellen und bearbeiten. Traditionelle, monolithische Content-Management-Systeme wurden oft von Entwicklern (ja, sogar WordPress) verspottet, die frustriert waren, als sie versuchten, das Werkzeug zu ihrem Willen zu beugen, um Projektanforderungen zu erfüllen. Aber bis vor kurzem hat der JAMstack diese Last weitgehend auf die nicht-technischen Content-Ersteller und -Editoren abgewälzt.

Von Entwicklern, für Entwickler

Statische Website-Generatoren (d.h. Tools wie Jekyll, Hugo und Gatsby) erfreuten sich enormer Beliebtheit, zum großen Teil, weil Entwickler sie für Projekte übernahmen. Sie wurden zu gängigen Lösungen für Dinge wie Blogs, Dokumentationen oder einfache statische Seiten. Im Großen und Ganzen waren dies Websites, die von Entwicklern erstellt, von Entwicklern gepflegt und deren Inhalte hauptsächlich von Entwicklern geschrieben und bearbeitet wurden.

Als ich 2015 in einem Bericht für O'Reilly über diese Tools schrieb, sagte ich Folgendes:

Nur für den Fall, dass dies noch nicht klar ist, möchte ich betonen, dass statische Website-Generatoren für Entwickler entwickelt wurden. Dies beginnt mit der Entwicklung der Website bis hin zum Hinzufügen von Inhalten. Es ist unwahrscheinlich, dass sich Nicht-Entwickler beim Schreiben in Markdown mit YAML oder JSON Front Matter, dem Metadaten am Anfang der meisten statischen Website-Engine-Inhalte oder -Dateien, wohlfühlen. Auch würden sich nicht-technische Benutzer wahrscheinlich nicht wohlfühlen, YAML- oder JSON-Datendateien zu bearbeiten.

—Ich (Bericht über statische Website-Generatoren für O'Reilly 2015)

Als ich zwei Jahre später ein Buch für O'Reilly zu diesem Thema schrieb (mit meinem Freund Raymond Camden), hatte sich nicht allzu viel geändert. Es gab einige Tools in den allerersten Stadien, darunter Jekyll Admin und Netlify CMS, aber sie hatten sich noch nicht so weit entwickelt, dass sie realistisch mit der Art von WYSIWYG-Tools konkurrieren konnten, an die sich Content-Editoren von Tools wie WordPress gewöhnt hatten.

Im Gegensatz dazu erforderte die Bearbeitungserfahrung von statischen CMSs immer noch ein Verständnis von Markdown und anderer Markup-Sprachen (YAML, Liquid usw.).

Es genügt zu sagen, dass dies, ungeachtet der technischen Verdienste der Architektur zu dieser Zeit, aus Sicht der Content-Bearbeitung kein Toolset war, das für die Mainstream-Adaption bereit war.

Die unbeholfenen Teenagerjahre

In den folgenden zwei Jahren trug eine Kombination aus einigen Trends dazu bei, dass der JAMstack zu einer praktikablen Lösung für Mainstream-Content-Websites mit nicht-technischen Redakteuren wurde. Der erste war, dass sich das statische CMS zu dem entwickelte, was wir heute im Allgemeinen als Git-basierte CMS-Lösungen bezeichnen. Der zweite war der Aufstieg des Headless-, API-First CMS als eine von Unternehmen übernommene Lösung.

Betrachten wir zuerst den ersten Trend. Netlify CMS, ein Open-Source-Projekt von Netlify, ist ein Beispiel für ein Git-basiertes CMS. Ein Git-basiertes CMS speichert Ihren Inhalt nicht, wie es ein traditionelles CMS tun würde, aber es verfügt über Tools, die verstehen, wie Dinge wie Markdown, YAML, JSON und andere Formate bearbeitet werden, aus denen eine JAMstack-Website besteht. Dies gibt den Content-Redakteuren Tools, mit denen sie sich wohlfühlen, aber im Hintergrund werden ihre Inhaltsänderungen einfach wieder in das Repository committet, was einen Neuerstellung der Website erzwingt. Während Netlify CMS auf der Website selbst installiert wird, sind andere beliebte Git-basierte CMS-Optionen wie Forestry webbasiert.
.

Das Headless-, API-First CMS funktioniert viel mehr wie die Bearbeitungserfahrung in einem traditionellen CMS. Es bietet nicht nur Werkzeuge zur Erstellung und Bearbeitung von Inhalten, sondern speichert diese Inhalte auch. Es macht diese Inhalte jedoch über eine API für das Frontend – jedes Frontend – verfügbar. Obwohl nicht auf JAMstack beschränkt, funktioniert ein API-First CMS gut damit, da die Erstellung und Verwaltung des Inhalts von der Anzeige dieses Inhalts im Frontend getrennt ist. Darüber hinaus bieten viele API-First CMS vorgefertigte Integrationen mit einigen der am weitesten verbreiteten statischen Website-Generatoren. Beliebte API-First-Optionen sind Contentful, DatoCMS und Sanity.

HeadlessCMS.org ist eine von Netlify gepflegte Website mit einer umfassenden Liste aller verfügbaren Tools, sowohl Git-basiert als auch API-First. Für einen guten Überblick über die Unterschiede, Vor- und Nachteile zwischen der Wahl eines Git-basierten und eines API-First CMS lesen Sie diesen Artikel von Bejamas.

Sowohl Git-basierte als auch API-First Headless CMS-Optionen begannen, nicht-technischen Content-Redakteuren die Werkzeuge zu geben, die sie im Backend zur Erstellung von Inhalten benötigten. Die Unbeholfenheit dieser „Teenagerjahre“ rührt daher, dass die Werkzeuge immer noch vom Frontend getrennt sind. Dies macht es schwierig zu sehen, wie sich Änderungen im Backend auf das Frontend auswirken werden, bis diese Änderungen tatsächlich in das Repository committet oder über die API live gestellt werden. Rechnen Sie dann die Zeit für eine Neuerstellung hinzu, und Sie haben eine weniger als ideale Bearbeitungserfahrung, bei der Fehler leichter auf die Live-Website gelangen können.

Ein Blick in die Zukunft

Wie sieht also die Zukunft aus, wenn der JAMstack CMS endlich erwachsen ist? Nun, wir haben auf der diesjährigen JAMstack_conf_sf einen guten Einblick bekommen. Zufälligerweise gab es zwei Präsentationen, die neue Tools vorstellten, die die Content-Editing-Erfahrung auf das Frontend bringen und es Content-Redakteuren ermöglichen, zu sehen, was sie ändern, wie ihre Änderungen aussehen und wie sie das Layout der Website beeinflussen werden.

Die erste Präsentation hielt Scott Gallant von Forestry. Darin stellte er ein neues Open-Source-Projekt von Forestry namens TinaCMS vor, das eine WYSIWYG-ähnliche Content-Editing-Erfahrung auf das Frontend von Websites bringt, die ein Git-basiertes CMS und Gatsby oder Next.js (beides React-basierte Tools) verwenden.

Die zweite Präsentation hielt Ohad Eder-Pressman von Stackbit (volle Offenlegung: Ich arbeite als Developer Advocate für Stackbit), der eine kommende Tool-Suite namens Stackbit Live vorstellte. Stackbit Live ist so konzipiert, dass es CMS und statische Website-Generatoren unabhängig voneinander unterstützt und gleichzeitig die Bearbeitung und Vorschau einer JAMstack-Website auf der Seite ermöglicht.

Beide Tools zeigten, dass wir an einem Punkt angelangt sind, an dem eine „JAMStack + Headless“-Architektur eine echte Alternative zu einem traditionellen CMS ist. Ich glaube, wir haben den Wendepunkt erreicht, an dem wir nicht mehr eine großartige Entwicklererfahrung gegen eine unbequeme Bearbeitungserfahrung für Content-Autoren eintauschen. Bis 2020 wird JAMstack CMS offiziell erwachsen sein. 👩🏽‍🎓