Ist der Jamstack wirklich komplett das Ding?

In den letzten Wochen ist mir einmal mehr aufgefallen, wie vielfältig und wundersam unsere Webentwickler-Welt geworden ist!

Konnte man sich bis weit in die 2010er noch relativ schnell darauf verständigen, was ein Full-Stack-Entwickler können muss, um den allgegenwärtigen LAMP-Stack zu rocken (nämlich HTML, CSS, jQuery und PHP-Templating), hat sich seit geraumer Zeit eine parallele Kultur entwickelt, von der ich lange Zeit kaum etwas mitbekommen habe, nämlich die JavaScript-only Webentwicklung. Eine ganze Generation von Kolleg:innen ist hier herangewachsen, die gar nicht unbedingt mehr mit PHP-basierten CMSen schrauben wollen (oder können), sondern am liebsten alles komplett über JavaScript-Technologie abwickelt, und zwar sowohl beim Bauen der Website, als auch beim Deployment, Hosting – und sogar in den Tutorials.

Begonnen hat wahrscheinlich alles mit der Einführung von Node.js (2009) und npm (2010), mit deren explosionsartiger Ausbreitung und Erfolg die ganze Webdev-Welt umgekrempelt wurde. Es gibt heute kaum noch moderne Softwareprojekte fürs Web, die nicht Node als Basis verwenden, und sei es nur für Installation und Einbindung in den Buildingprozess.

Was die grundsätzliche Website/Webapp-Architektur angeht, gibt es gleich zwei parallel laufende Modelle, die beide nicht viel mit dem traditionellen WordPress/Joomla/Drupal-Ansatz zu tun haben.

Zum einen wäre da natürlich die Single-Page-Application (SPA), welche insbesondere mit dem Erscheinen von React (2013) und seinen jüngeren „Geschwistern“ Vue.js (2014) und Svelte (2016) für Aufsehen sorgte. Hier passiert quasi alles auf dem Gerät des Nutzers, welches sich erst einmal einen großen Batzen JavaScript herunterladen muss.

Zum anderen haben wir das Ideal des Jamstack aus dem Jahr 2016. Die Idee besteht darin, dass der Server nur noch stupide statische Seiten ausliefern muss. Bei Bedarf werden dann über Laufzeit-Javascript ganz präzise nur die gerade benötigten aktuellen Daten in die statischen Basis-Strukturen hineingeklebt – entweder über eine JSON-API, oder sogar gleich als HTML vorgerendert über SSR (Server-Side-Rendering).

Gerade das Thema Jamstack boomt seit 2022 extrem, und man kann das gut an der unfassbaren Anzahl von statischen Site-Generatoren erkennen, die auf Jamstack.org aufgelistet werden: Neben den Platzhirschen Next.js (2016), Nuxt (2016), Eleventy (2017) und Astro (2021) tummeln sich hier 350(!) weitere Softwareprojekte, die aus einer Dateistruktur eine statische Website generieren können. Manche sagen, dass dies insbesondere auf das Erscheinen von Vite (2020) zurückzuführen ist, mit dem das Builden und Serven so viel einfacher und schneller durchgeführt werden kann, dass sich ein Website-Framework quasi von selbst schreibt. Naja.

Ich blicke auf diese ganze Entwicklung mit dem Erstaunen eines Webentwicklers, der bisher ziemlich gut mit dem traditionellen LAMP-Stack zurechtgekommen ist. Ich kann natürlich verstehen, was der Reiz ist:

  • Neu ist immer besser: Warum schimmelige PHP-Templates verwenden, wenn man coole neue Spielzeuge mit Features wie „Component Islands“, „Partial Hydration“ und „Serverless Functions“ haben kann?
  • JavaScript only: Ich muss nur noch eine Sprache beherrschen, die ich für alle (wirklich alle!) Aspekte des Webentwickler-Daseins einsetzen kann.
  • Performance: Natürlich sind statische Dokumente das schnellste, was ein Server so ausliefern kann, und indem für dynamische Daten externe APIs genutzt werden, ist man für eine langsame UX nicht mehr selber verantwortlich – es sei denn, man baut diese API eben auch selber und hat dabei den Hut des Backend-Entwicklers auf.

Es gibt aber eine ganze Reihe von Aspekten, die ich durchaus kritisch sehe. Vieles davon ist natürlich Gewöhnungssache, aber ein paar Punkte meine ich doch ansprechen zu können.

Da wäre zum einen die Sache mit der Performance. Ich glaube nicht, dass eine gut gecachte Website, die von einem traditionellen serverseiten CMS ausgeliefert wird, spürbar langsamer ist als eine superoptimierte Jamstack-Website. Die von mir bevorzugten CMSe ProcessWire und Kirby bieten in der Basisversion sehr ordentliches Caching an. Es besteht aber auch die Möglichkeit, die Seiten tatsächlich statisch herausrendern zu lassen, damit wären diese CMSe nichts anderes als PHP-basierte Static Site Generatoren, jedoch mit dem entscheidenden Vorteil, dass ich ein sehr komfortables Backend für die Inhaltspflege bekomme.

Gerade dieser Punkt ist meines Erachtens das Hauptproblem bei sehr vielen der modernen dateibasierten Website-Frameworks: Der Aspekt der Inhaltspflege wird fast nicht besprochen. Man solle halt diese geilen Front Matter-Dateien anlegen, die dann per Git ins Repo pushen, und dann wird das von einem Buildingprozess auf die Livedomian deployed. Alles klar, damit können nur absolute Webnerds ihre Inhalte pflegen.

Normale Redakteure brauchen aber ein gutes CMS. Also sind wir gezwungen, ein sogenanntes „Headless CMS“ zu nutzen, welches Inhalte über eine schicke GUI pflegbar macht, und dann über eine Schnittstelle in strukturierter Form an die statische Jamstack-Website weitergibt. Theoretisch fein, aber so richtig komfortabel fühlt sich das dann nicht mehr an, wenn man damit auf agile Weise „On-the-fly-Templating“ betreiben will, wie ich das meistens bei meinen Kundenwebsiten tue: Hier mal schnell ein paar Felder im CMS ergänzen, flott das Template für die Ausgabe anpassen, schon beherrscht die Website ein paar neue pflegbare Datenstrukturen, und das alles quasi im laufenden Betrieb, wenn man möchte.

Meine Hauptsorge bei Nuxt & Co. ist aber etwas ganz anderes. Es gibt bei fast allen Website durchaus noch Stellen, wo die dynamischen Fähigkeiten eines Servers gefragt sind: Kontaktformulare, Volltextsuche und passwortgeschützte Bereiche, um nur drei Beispiele zu nennen. Für die braucht man neuerdings dann einen Node.js-Webserver. Und die sind durchaus nicht so allgegenwärtig, standardisiert und erprobt wie LAMP-Hosting, was man ja in akzeptabler Qualität als Shared Hosting für sehr kleines Geld überall bekommen kann.

Doch damit nicht genug, und hier wird es ein bisschen gruselig: Viele der neuen Frameworks werden von großen Hosting-Dienstleistern mitfinanziert. Next.js ist ein Vercel-Produkt, Astro nennt netlify als offiziellen Hosting-Partner, und Gatsby hat sich erst kürzlich komplett von netlify einverleiben lassen. Somit kann man sicher sein, dass die coolsten Funktionen (oder die einfachsten Methoden, bestimmte Funktionen zu nutzen), den Kunden dieser Hosting-Providern vorenthalten sind. Wenn ich also in Astro ein funktionierendes Kontaktformular haben möchte, werde ich selbstverständlich aus Bequemlichkeit die speziellen Formular-Funktionalitäten von netlify nutzen. Und damit meine Seite kaum noch zu einem anderen Hosting-Anbieter transferierbar machen.

Somit werden die neuen Webframeworks, wenn man nicht aufpasst, immer mehr zu proprietären Baukasten-Systemen der modernen Hosting-Provider. Und irgendwie habe ich da keine Lust drauf. Nichts gegen hochperformant ausgelieferte statische HTML-Seiten, die aus einem coolen Static Site Generator rausfallen, gerne auch partiell hydriert und mit scharf. Aber für die Art von Websites, die ich bisher gebaut habe, mit viel Inhalt, der von Laien gepflegt wird, und die auf einem Standard-Hoster läuft, bei dem ich auch mal mit der deutschen Hotline telefonieren kann, fühlt sich der moderne Weg, Websites zu bauen, ganz schön umständlich an.

Aber ich bin auch neugierig, mehr zu erfahren. Insbesondere wie alltagstauglich das alles ist, und welche Art von Websites total profitiert von den aktuellen Hype-Systemen? Erleuchtet mich gerne mit euren Kommentaren auf Mastodon!