Die Semantik von Jamstack

Im letzten Jahr gab es eine gesunde Debatte rund um den Begriff „Jamstack“, da die Definition erweitert wird, um neue Anwendungsfälle einzuschließen. Ich habe kürzlich meine Sicht auf eine Jamstack-Definition in „Static vs. Dynamic vs. Jamstack: Where’s The Line?“ gepostet. In diesem Artikel möchte ich die Evolution von Jamstack und ihre Bedeutung für den Begriff beleuchten.

Entwickler erstellen statische Websites lange bevor der Begriff Jamstack geprägt wurde. Der häufigste Anwendungsfall war eine einfache Möglichkeit für Entwickler, ihren Blog oder ihre Open-Source-Dokumentation auf GitHub Pages zu hosten. Einige Pioniere trieben größere, kommerzielle Projekte auf statischen Websites voran, aber es war sicherlich nicht so üblich wie heute.

Statische Websites wurden als begrenzt wahrgenommen – alte Technologie aus den 90ern. Warum sollten zukunftsorientierte Unternehmen diese alte Art des Website-Aufbaus nutzen wollen? Phil Hawksworth hat es in seinem IJS-Vortrag über „static being a loaded term“ auf den Punkt gebracht.

Sprechen wir über eine statische Erfahrung oder sprechen wir über eine statische Architektur?

Das Potenzial für Mehrdeutigkeit ist unglaublich verwirrend, besonders für Nicht-Entwickler. Die statischen Websites der 90er sind nicht dasselbe wie moderne statische Websites. Es gibt neue Technologien, die es rechtfertigen, statischen Websites einen zweiten Blick zu gönnen.

• JavaScript hat sich zu einer leistungsstarken Sprache für die Erstellung von Anwendungen im Browser entwickelt. Gmail wurde 2004 gestartet und war die erste Mainstream-Anwendung, die Ajax intensiv nutzte.
• Static Site Generators (SSGs) haben viele Vorteile dynamischer Websites gebracht, wie z. B. Layouts und die Trennung von Inhalt und Code. Jekyll war der erste weit verbreitete SSG, der 2008 gestartet wurde.
• CDNs waren früher eine Technologie, die sich nur große Unternehmen leisten konnten. Als AWS Cloudfront 2008 gestartet wurde, konnte man ein CDN in wenigen Minuten einrichten, und im kleinen Maßstab kostete es nur ein paar Dollar.
• Git-Workflows und die darum aufgebauten CI/CD-Tools haben fehleranfällige FTP-Deployments zu einer Sache der Vergangenheit gemacht.
• Ökosystem – es gibt eine wachsende Anzahl von eigenständigen Tools, die man in eine statische Website integrieren kann, um zusätzliche Funktionalitäten zu ermöglichen, von Suche und E-Commerce bis hin zu Datenbanken, Kommentaren und mehr.

Jamstack hat dazu beigetragen, die Wahrnehmung von statischen Websites zu ändern. Und die sich wandelnden Winde bezüglich statischer Seiten führten dazu, dass Matt Biilmann den Begriff Jamstack selbst im Jahr 2016 prägte. Plötzlich hatten wir ein Wort, das die Vorteile moderner statischer Websites ohne den Ballast von statisch einfing. Cassidy Williams hat eine fantastische Arbeit geleistet, um die Essenz von Jamstack zu erfassen.

Jamstack bedeutet, Webanwendungen im gleichen Stil wie mobile Anwendungen zu erstellen: die Benutzeroberfläche wird kompiliert, und dann werden Daten nach Bedarf abgerufen.

Jamstack fand bei vielen WordPress-Entwicklern großen Anklang. Aus der Welt der komplizierten Theming- und Plugin-APIs kommend, war die Einfachheit und Kontrolle, die man mit einem SSG erhielt, erfrischend. Die Bewegung hatte begonnen, und eine Community bildete sich um den entkoppelten Ansatz von Jamstack.

Mit zunehmender Beliebtheit von Jamstack wuchsen auch Größe und Komplexität der Projekte. Wir sahen, wie die Prinzipien von Jamstack über Websites hinausgingen, und als sie in Webanwendungen Einzug hielten, erreichten wir bald die technischen Grenzen dessen, wozu eine statische Website fähig war. Plattformen fügten neue Funktionen und Workflows hinzu, um Jamstack-Prinzipien zu erweitern und größeren und komplexeren Anwendungen einen Jamstack-Ansatz zu ermöglichen.

Ich freue mich, mit CloudCannon an dieser Entwicklung teilzuhaben. Wir sehen einen bedeutenden Wandel darin, wie Entwickler Software für das Web erstellen. Es gibt ein florierendes Ökosystem von spezialisierten Tools und Plattformen, die es Frontend-Entwicklern ermöglichen, mehr zu tun, und für anspruchsvolle Anwendungen, die am Edge leben.

Meine Sorge ist, dass wir uns nicht darauf einigen können, was Jamstack eigentlich bedeutet. Es gibt prägnante Definitionen, die eine klare Grenze ziehen, was Jamstack ist und was nicht. Viele meiner Favoriten finden sich in diesem Artikel. Wir sehen, dass der Begriff Jamstack für immer mehr dynamisches Verhalten verwendet wird. Ein Teil der Community ist mit dieser Verwendung einverstanden, ein anderer nicht. Mehrdeutigkeit und Wahrnehmung waren die ursprünglichen Gründe für die Prägung des Begriffs, und wir laufen Gefahr, hier wieder auf Anfang zurückzufallen.

Es ist ein schwieriges Problem, mit dem sich die Jamstack-Community auseinandersetzen muss, da es so viel Überschneidungen zwischen der ursprünglichen Bedeutung von „Jamstack“ und der neuen, weiterentwickelten, etwas dynamischeren Verwendung des Wortes gibt. Ich bin selbst zwiegespalten, weil ich die Idee, Jamstack-Prinzipien auf dynamischere Ansätze anzuwenden, liebe. Ich habe kurzzeitig die Idee in Erwägung gezogen, „Jamstack“ für statische Nutzung und „Jamstack++“ für die dynamischere Nutzung zu verwenden. Aber mir wurde schnell klar, dass dies wahrscheinlich mehr Verwirrung stiften würde, als es löst.

Matt Biilmann hat es mit Netlifys Ankündigung von Distributed Persistent Rendering (DPR) perfekt getroffen.

Für jede Technologie ist der schwierigste Teil nicht die Etablierung von Einfachheit, sondern deren langfristiger Schutz.

Das fasst meine Gedanken perfekt zusammen. Es ist beruhigend zu wissen, dass ich nicht eingeschränkt bin, wenn ich ein neues Projekt mit einem Jamstack-Ansatz erstelle. Wenn meine Website riesig wird oder ich dynamisches Verhalten benötige, habe ich Optionen. Ohne diese Optionen würde Jamstack als limitierte Technologie für kleine Anwendungsfälle angesehen werden. Auf der anderen Seite, je mehr wir diese dynamischeren Lösungen betonen, desto weiter entfernen wir uns von der eleganten Einfachheit, die die Jamstack-Bewegung überhaupt erst geschaffen hat.

DPR ist eine aufregende neue Technologie. Es ist eine elegante Lösung für die schmerzhafte Einschränkung, große Websites im Voraus zu erstellen. Bei einer Website mit 100.000 Seiten, würde ich den Kompromiss eingehen, einen Teil dieser Seiten im Voraus zu erstellen und den Rest beim ersten Aufruf dynamisch zu erstellen, wodurch die Build-Zeit erheblich reduziert wird? Aber ja, würde ich! Das ist ein Kompromiss, der Sinn macht.

Ich habe viel darüber nachgedacht, wo DPR in das Jamstack-Bild passt, hauptsächlich weil es direkt an der Grenze liegt. Ob man es in den Jamstack-Schirm aufnimmt oder ausschließt, hat weitreichende Auswirkungen.

Sean Davis hat eine Jamstack- Definition, die mir gefällt.

Jamstack ist eine Architektur für den atomaren Aufbau und die Bereitstellung vorkompilierter, entkoppelter Frontend-Webprojekte vom Edge.

Das spiegelt wider, was meiner Meinung nach Jamstack ausmacht. Wenn wir DPR in diese Definition aufnehmen wollen, muss sie etwas überarbeitet werden.

Jamstack ist eine Architektur für den atomaren Aufbau und die Bereitstellung vorkompilierter (oder bei Bedarf generierter Webseiten, aber nur, wenn es die erste Anfrage ist und diese dann persistent gespeichert wird), entkoppelter Frontend-Webprojekte vom Edge.

Die offizielle Jamstack-Definition funktioniert besser für DPR.

Jamstack ist die neue Standardarchitektur für das Web. Unter Verwendung von Git-Workflows und modernen Build-Tools werden vorgerenderte Inhalte an ein CDN ausgeliefert und durch APIs und serverlose Funktionen dynamisiert.

DPR liefert Inhalte entweder über eine serverlose Funktion oder als statische Datei über ein CDN, sodass es in die Definition passt.

Es ist interessant zu sehen, wie sich die Definition im Laufe der Zeit verändert hat. Vor Ende 2020 lautete die offizielle Jamstack-Definition, die damals direkt auf Jamstack.org veröffentlicht wurde, wie folgt:

Schnelle und sichere Websites und Apps, die durch Vorabrendern von Dateien und deren direkte Bereitstellung von einem CDN geliefert werden, wodurch die Notwendigkeit der Verwaltung oder Ausführung von Webservern entfällt.

Technologie entwickelt sich im Laufe der Zeit, ebenso wie Sprache. Es ist daher großartig zu sehen, dass die Definition angepasst wird, um mit der Zeit Schritt zu halten. Die Einführung von „serverless“ in die Definition ist einerseits sinnvoll, da die Technologie für Frontend-Entwickler, die die Hauptzielgruppe von Jamstack sind, zugänglicher wird. Andererseits widerspricht sie den Kernprinzipien von Jamstack des Vorabrenderns und der Entkopplung. Müssen wir diese Kernprinzipien auch aktualisieren?

Ich verarbeite all diese Gedanken und Ideen noch selbst. Ich bin ein großer Fan von Jamstack, es war ein wichtiger Katalysator für das Wachstum von Static Site Generators und hat uns eine Sprache gegeben, um über den Ansatz des Vorabrenderns und der Entkopplung von Websites zu sprechen. Mit Blick auf die Zukunft sehe ich fünf Richtungen, in die sich Jamstack entwickeln kann:

1. Jamstack ist in seiner ursprünglichen Bedeutung gefestigt: Vorabrendern und Entkopplung. Die dynamischeren, von Jamstack inspirierten Ansätze erhalten einen eigenen Namen.
2. Jamstack entwickelt sich weiter, und die Definition und die Prinzipien werden erweitert. Infolgedessen wird die Bedeutung wahrscheinlich mehrdeutig.
3. Jamstack ist der Name der Community. Es sind eine Reihe von Richtlinien, und es gibt keine festen Regeln.
4. Jamstack hat das Gepäck von „static“ abgeworfen, und wir können über statische vs. hybride vs. dynamische Websites sprechen.
5. Jamstack wird Mainstream genug, dass wir es einfach als moderne Webentwicklung bezeichnen können.

Es gibt Leute in all diesen Lagern, die in verschiedene Richtungen ziehen, was zu viel Verwirrung und Diskussion in der Community führt. Klar ist, dass diese Gemeinschaft von Menschen mit Leidenschaft für diesen Ansatz des Website-Aufbaus bei der Sache ist. Ehrlich gesagt, ich könnte nicht aufgeregter sein über die Innovationen, die in diesem Bereich stattfinden. Was wir brauchen, ist Konsens und ein Weg nach vorne. Ohne dies werden wir meiner Meinung nach, ob zum Besseren oder Schlechteren, mit einer Mischung aus Optionen 3, 4 und 5 enden.