JAMstack? Mehr wie SHAMstack.

Ich bin ein Fan von der ganzen JAMstack-Sache. Es scheint eine *gesunde* Web-Bewegung zu sein. Ich freue mich auf beide bevorstehenden Konferenzen.

Von allen Web-Trends scheint #jamstack der am wenigsten zu bedauernde zu sein.

— Chris Coyier (@chriscoyier) 22. Mai 2019

Ich habe das Gefühl, dass das Akronym dem Ganzen vielleicht nicht ganz gerecht wird. Nicht, dass ich vorschlagen würde, es zu ändern. Wenn eine Sache einmal ins Rollen gekommen ist, ist es meiner Erfahrung nach am besten, dabei zu bleiben. Dasselbe gilt für Serverless. Verdammt, der Name dieser Website ist ziemlich... nicht gerade toll.

Für mich ist der wichtigste Teil von JAMstack im Konzept des statischen Datei-Hostings verwurzelt. Statisches Datei-Hosting ist die Grundlage für all die Power. Es öffnet eine ganze Reihe von Türen, wie

• Alles kann CDN-gehostet werden. „The Edge“, wie man sagt. Sogar das HTML (das M in JAMStack bezieht sich auch auf Markup) kann CDN-gehostet werden, was man sonst nicht kann. Das gibt Ihnen eine erstaunliche Basis an Geschwindigkeit, die Sie dazu ermutigt, diese Geschwindigkeit auch beim Bauen beizubehalten.
• Das Projekt fühlt sich einfacher zu handhaben an. Git-Klon, npm-Installation, Build. Deployments sind Git-Pushes eines dist-Ordners. Es ist so cool, dass zum Beispiel Netlify Ihnen für jeden Build eine URL gibt, selbst für Branches, an denen Sie gerade arbeiten. Dies wird dadurch ermöglicht, dass Deployments irgendwie unveränderlich sind. Ein Satz von Dateien zu einem bestimmten Zeitpunkt.
• Cloud Functions sind großartig. Da Sie keine traditionelle serverseitige Sprache zur Verfügung haben, bauen Sie diese mit Cloud Functions, wenn Sie serverseitigen Code benötigen – was ohnehin eine coole Art ist, Dinge zu architektonisch zu gestalten und eng mit all dem verbunden ist.

Denken Sie nicht: „Oh, JAMstack ist nur für Jekyll-Blogs“ oder was auch immer. Zwar sind Static Site Generatoren extrem JAMstack-mäßig, und JAMstack fördert stark so viel vorab erstelltes Markup wie möglich (was gut für Geschwindigkeit und SEO und all das ist), aber vorab erstelltes Markup ist keine *Voraussetzung*.

Ich würde sogar so weit gehen zu sagen, dass eine von clientseitigem JavaScript betriebene App, die ein <div id="root"></div> und ein JavaScript-Bundle ausliefert, das APIs abfragt und die Website aufbaut, immer noch eine JAMstack-Website ist. Sie wird immer noch (wahrscheinlich) statisch gehostet, mit Cloud Functions, die Daten bereitstellen.

Ich würde sagen: „Ja“.

Vielleicht wäre ein bisschen mehr SSR aus allen genannten Gründen gut, aber naja, kein Muss für ein JAMstack-Leistungsabzeichen.

— Chris Coyier (@chriscoyier) 22. Mai 2019

Aber solange Sie sowieso JAMstack machen, ermutigt Sie das, *mehr* in diese statischen Dateien zu packen. Auf diese Weise fördert es auch statische *Inhalte*, wenn möglich. Ich würde sagen „serverseitig gerendert“ (SSR), da dies der gebräuchliche Begriff ist, aber es geht darüber hinaus. Es ist keine serverseitige Sprache, die das Markup auf Anfrage generiert; es wird in einem *Build-Schritt* im Voraus erstellt, vor der Bereitstellung. Auch hier ist es keine *Voraussetzung*, nur ermutigt.

Also haben wir statisch gehostetes HTML und alle unsere anderen Dateien (z. B. CSS, Bilder usw.) sind ebenfalls statisch. Dann

• Das J von JAMstack ist JavaScript.
• Das A von JAMstack sind APIs.

Sie sind so etwas wie dasselbe. Ihre JavaScript-Dateien werden statisch gehostet. Sie laufen und sprechen mit APIs, wenn sie müssen. Ein gängiges Beispiel könnte ein GraphQL-Endpunkt sein, der einige Inhalte ausspuckt.

Eine interessante Wendung hier ist, dass man diese Dinge halb und halb machen kann. Mit anderen Worten, Sie können *einige* der Markups vorab erstellen und auf JavaScript und API-Aufrufe für andere Teile warten. Stellen Sie sich eine E-Commerce-Website mit einer Homepage und einem Dutzend anderer Seiten vor, die Sie *vollständig vorab erstellen* können, aber dann einen Katalog von Tausenden von Produkten, die zu unpraktisch zum statisch Generieren wären (zu langsam). Sie sind nur eine einzige, mit Vorlagen versehene Struktur, die sich selbst mit clientseitigen API-Aufrufen ausfüllt.

Wenn wir also ein neues Akronym erfinden *würden*, würden wir vielleicht Static Hosting mit aufnehmen und JavaScript und APIs zu nur APIs zusammenfassen, was uns übrig ließe…

Static Hosting, APIs und Markup, oder der SHAMstack. Äh, naja 😬 vielleicht nicht.