Zufällige Notizen von einem JAMstack Roundtable

Ich habe am vergangenen Wochenende auf der Web Unleashed eine JAMstack-Diskussionsrunde veranstaltet. Hier sind nur ein paar zufällige Notizen aus dieser Erfahrung.

• Ich war zunächst überrascht, dass es tatsächlich Verwirrung darüber gibt, dass das „M“ in Jamstack für „Markdown“ (die Sprache, die zu HTML kompiliert) und nicht für „Markup“ (das „M“ in HTML, das manchmal mit HTML gleichgesetzt wird) steht. Es kam als legitime Verwirrung auf. Antwort: Markdown ist für JAMstack nicht erforderlich. Die Verwirrung entsteht aus der Vorstellung, dass Markdown oft Hand in Hand mit statischen Seitengeneratoren geht, die wiederum Hand in Hand mit JAMstack gehen.
• Mir wurde zum ersten Mal klar, dass jede einzelne Website, die auf Netlify oder GitHub Pages oder einem S3-Bucket („statisches Hosting“) gehostet wird, JAMstack ist. SHAMstack, tatsächlich! :). Der statische Hosting-Teil (SH) von JAMstack ist vielleicht der wichtigste Aspekt.
• Eine Website, die aus einer einzigen index.html-Datei mit <div id="root"> und einem JavaScript-Bundle besteht, das den Rest clientseitig rendert, kann JAMstack sein. Vorausgesetzt, die benötigten Daten sind entweder integriert oder stammen von einer API auf einem anderen Server, der nicht derjenige ist, der diese index.html-Datei hostet, ist es JAMstack.
• Es gibt einen Unterschied zwischen *technisch* JAMstack und *spirituell* JAMstack. Das Obige ist vielleicht eher technisch und weniger spirituell. Letzteres möchte, dass mehr von der Seite vorgerendert wird als nichts.
• Das Vorrendern ist gut, weil: es schnell ist, es CDN-gehostet werden kann, es sicher ist und es SEO-freundlich ist. Viele Frameworks bieten es als Teil ihrer Funktionalität an, also kann man es auch nutzen. Vorrendern bedeutet nicht statisch, JavaScript kann immer noch geladen werden und schick aussehen.
• Es lässt sich nicht leugnen, dass Static Site Generators und JAMstack BFF sind. Aber JAMstack möchte, dass Sie größer denken. Was ist, wenn Sie nicht alles rendern können, weil Sie 50.000 Produktseiten haben und die Generierung zu langsam oder anderweitig unpraktisch ist? Kein Problem, Sie können andere Seiten vorrendern, aber nur eine Hülle für die Produktseiten und bei Bedarf eine API für Produktdaten abrufen. Was ist, wenn einige Seiten absolut nicht statisch gehostet werden können? Kein Problem, Sie können die, die es können, auf einen statischen Server weiterleiten und den Rest unberührt lassen. Möchten Sie vollständig auf statisches Hosting setzen, benötigen aber Server für bestimmte Funktionalitäten? Betrachten Sie serverlose Funktionen, die sozusagen der spirituelle Backend-Partner für statisches Hosting sind.
• Die Leute wollen wirklich wissen, *warum*. Warum sich die Mühe mit diesem ganzen Kram machen? Wenn Sie eine Website erstellen können, die alles Nötige mit WordPress erledigt, warum nicht einfach das tun? Ich habe am Ende meine Nutzung von WordPress aus funktionaler Sicht verteidigt. Wenn ich unbegrenzt Zeit und einen frischen Start hätte, selbst wenn ich bei WordPress als CMS bleibe, würde ich wahrscheinlich einen Weg einschlagen, zumindest etwas vorzurendern, wenn nicht alles zu entkoppeln und mein eigenes Frontend zu bauen und die Daten nur über APIs zu nutzen. Aber vielleicht die überzeugendsten Antworten auf das *Warum* liegen in *Geschwindigkeit*, *Sicherheit* und *Resilienz*, die alle sofort mitkommen, wenn Sie sich für JAMstack entscheiden. Es bietet eine verdammt gute Grundlage, auf der man aufbauen kann.