Eindrücke

Ich möchte an dieser Stelle nicht erklären, was unter dem Begriff JAMstack insgesamt zu verstehen ist. Weiter unten sind jedoch noch einige Quellen beigefügt, damit man sich etwas ins Thema einlesen kann.

Vielmehr möchte ich ein paar Eindrücke wiedergeben, die sich beim Arbeiten mit verschiedenen Ansätzen ergeben haben.

Content is king again

Mir gefällt besonders gut, dass mit dem JAMstack - Ansatz ein pragmatischer und lösungsorientierter Weg beschritten wird. Mit Generatoren für statische Websites wie etwa Hugo kann auf Basis eines unkomplizierten Ansatzes direkt mehr Zeit für die Struktur und Inhalte eines Webprojekts investiert werden. Für die lokale Entwicklungsumgebung ging das Einrichten von z.B. hugo, vuepress etc. sowohl auf Linux als auch Windows sehr schnell und es traten keine nennenswerten Probleme auf. Bei vielen klassischen Stacks und Technologien ist die Lernkurve und der Aufbau der technischen Infrastruktur ggfs. oft sehr groß, so dass die eigentlichen Inhalte nicht selten aus dem Fokus geraten. Bei einigen JAMstack-Ansätzen ist dies also meiner Meinung nach erfrischend anders.

Ich würde weiter sagen, dass sich hier für reguläre Websiteprojekte da facto Entwicklungskosten einsparen lassen, da Ergebnisse vergleichsweise effizient zu generieren oder auch zu pflegen sind.

Statisch ist irreführend

Bei Generieren statischer Seiten oder dem Begriff des Static Site Generators denkt man durchaus leicht an statische HTML-Seiten aus der Vergangenheit. Also an eingeschränkten Möglichkeiten, die unterschiedlichsten modernen Anforderungen zu erfüllen.

Hier finde ich, dass das Marketing klar versagt hat 😄 !!

Eine Webapplikation oder eine simple E-Commerce Website, die auf JAMstack-Ansätzen basiert, kann durchaus viele Funktionen und Anforderungsprofile abbilden (ein nettes Beispiel ist im contentful blog zu finden - Dynamic product management in a static e-commerce workflow).

Aus meiner Sicht steht der Ansatz nicht für heftige Limitierungen, sondern für bestimmte Best Practices. Die Frameworks oder Generatoren haben bestimmte Vorzüge oder Ziele anvisiert, wie Optimierung der Performance für die Build-Erstellung, was bei atomaren Deploys und je nach Projektumfang echte Relevanz besitzt. So lassen sich auf jeden Fall unterschiede in den vielen Ansätzen ausmachen. GatsbyJS knüpft recht nahtlos an die React-Community an, wodurch bspw. auf einen enorm großen Fundus an bereits existierenden Entwicklungen zurückgegriffen werden kann, etwa um eine Stripe-Integration für einen Shop vorzusehen. Andere Site-Generatoren sind ursprünglich für den Anwendungsfall optimiert worden, technische Dokumentationen auf Basis von Markdown-Files zu generieren. Die Bandbreite der Ansätze ist also groß und man sollte sich informieren, welcher Ansatz für die eigenen Vorhaben am besten passt.

Eine umfängliche Liste der Generatoren und Frameworks wird unter jamstack.org gepflegt. Ein Blick lohnt sich!

Wie so oft - auch eine Frage des Geschmacks …

Ich persönlich habe ja Gefallen an vueJS gefunden, so dass es für mich eine naheliegende Sache war, vuepress und gridsome neben z.B. vuetify auszuprobieren.

Die Präferenzen hinsichtlich Programmiersprache und sonstigen Mitteln im Einsatz spielen also natürlich eine subjektive Rolle. Weitere Unterschiede lassen sich ausmachen, wenn es um die Community und Tools im jeweiligen Ökosystem geht. Für den einfachen Einstieg eignen sich etwa auch die vielen Themes, Starter und Boilerplates, die auf dem ein oder anderen Ansatz andocken. Ich habe diese Seite hier auf Basis eines bestehenden Hugo themes gebaut (kudos an rhazdon!). Für die Ziele dieser Seite war es einfach bereits bestens geeignet.

Und bei aller Freude am Basteln, macht es eben total Sinn, für ein reguläres Webprojekt nicht immer das Rad neu erfinden zu müssen. So kann man sagen, dass sich ein Blick in die Community vor der Auswahl eines Frameworks oder Generators lohnt.

Piff Paff: Einfach mal deployen!

Für meine Zwecke (als 1-Mann-DEV) finde ich die Reduktion unnötigen Overheads wichtig. Z.B. wenn es um die end-to-end Abläufe von der lokalen Entwicklung bis hin zum production-Deploy geht. Wenn man etwa ein Projekt auf Netlify hostet, dann ist es wirklich absolut praktisch, ein git repository (z.B. auf github, bitbucket oder gitlab) einfach in den Fokus der Pipeline zu stellen.

Lokal wird entwickelt, ins remote repo committed und auf netlify wird die statische App samt aller assets gebacken. Fertig. Komplizierter geht es immer, aber mir kommt der git-Zentrismus hier absolut entgegen, um Prozesse auch schlank zu halten. Zum Hosting und Deployment sind in den hugo docs einige Beispiele beschrieben, hier etwa am Beispiel Netlify.

Der Vorteil bei statisch generierten Websites ist natürlich auch, dass die generierten Dokumente auch einfach via sftp oldschool auf einen Server kopiert werden könnten, eleganter geht es aber natürlich anders.

Mini-Benchmark: Hugo-Blog vs. Worpress Blog

HUGO

Hugo muss man installieren, git und Go auch (falls nicht lokal vorhanden). Die Installation geht flott und klappte bei mir reibungslos sowohl unter Linux als auch Windows.

Nach der Installation erstellt man eine neue Seite, sucht sich z.B. ein passendes Blog-Theme aus und kann dann bereits mit der Erstellung von Inhalten beginnen Quick-Start Anleitung.

Danach kann man sich ein remote repository auf github einrichten und sich für eine Strategie bzgl. Deployment / Hosting entscheiden.

WORDPRESS

Bei Worpress stellt sich sicherlich erst die Frage, ob man einen Anbieter wählt, der eine Wordpress-Installation bereitstellt, hosted und updated oder ob man auf Basis eines lokalen Stacks wie z.B. Xampp in die Eigenentwicklung starten will.

Nehmen wir den teureren, aber einfachen Fall an: eine Wordpress-Installation wird von einem Anbieter bereitgestellt - dann beginnt nach der Bereitstellung das Einrichten der Wordpress-Installation.

Worpress bietet aufgrund seiner langen Historie einen riesigen Fundus (freier oder kostenpflichtiger) Plug-Ins, Themes und sonstigen Add-ons an. Das ist einerseits gut, macht es aber andererseits nicht immer einfacher, die richtigen Helferlein für ein konkretes Problem zu finden.

Wenn die Grundversion inkl. aller Erweiterungen steht, kann mit der Erstellung von Inhalten begonnen werden

Beide Varianten im Vergleich

Im direkten Vergleich ist Wordpress sicherlich auf den ersten Blick für viele Benutzer einfacher einzurichten, weil mehr Einstellungen über die UI (und nicht die Konsole) erfolgen.

Dass es eine visuelle Oberfläche gibt bedeutet aber nicht zwangsläfig, dass die Wordpress-Einrichtung für Laien einfach ist. Auch hier existieren viele Einstellungsoptionen, die für Neulinge Rätsel aufgeben können.

Um die Worpress-Installation auf dem lokalen Server anzupassen (z.B. ein eigenes Theme etc.) und später zu betreiben, ist zunächst ein klassischer Stack auf Basis von PHP und MySQL/MariaDB etc. nötig. Hier wirkt der Hugo-Ansatz ganz klar leichtgewichtiger und moderner. Go, git und Hugo sind schnell am Start und CLI-basiert sind die wichtigsten Dinge zu erledigen.

Insgesamt wirkt Wordpress zwar immer noch legitim, aber im direkten Vergleich ebenso altmodisch und überholt. Von der Installation bis zum Schreiben des ersten Posts schlägt sich Hugo aus meiner Sicht ebenfalls besser. Das ist aber letztlich von vielen Einzelheiten abhängig, z.B. welche Entwicklungen vorgenommen werden, welche Komplexität die eingesetzten Themes und Erweiterungen mitbringen und wie in beiden Fällen (Wordpress & Hugo) die Expertise desjenigen gelagert ist, der die Einrichtung durchführt.

Für den Produktiv-Betrieb sind zusätzlich wichtige Vorteile der statisch generierten Website (hier also auf Basis von Hugo) zu erwähnen - der Ansatz punktet in Sicherheit, Ladezeitoptimierung und auch SEO. Im Wordpress-Universum gibt es natürlich viele Erweiterung, um SEO oder Performance-Optimierungen vorzunehmen, doch unterm Strich sind die statischen Seiten hier quasi nativ im Vorteil. Insbesondere der Sicherheitsaspekt ist wesentlich - Wordpress wird seit Dekaden von Bots und Hackern akribisch auf alte und neue Schwachstellen untersucht. Bereits im Jahr 2000 wurde eines meiner Wordpress-Projekte von einer Defacement-Group angegriffen 😄 … Man muss bedenken, dass jedes Wordpress-Plug-In neben der jeweiligen Wordpress-Version selbst oder gar neben der zugrundeliegende PHP-Version stetig aktualisiert werden muss; in Summe ist das ein Dauerthema. Bei statischen Websites entfällt hier vieles, was die Angriffsfläche und Update-Marathons betrifft.

Mein subjektives Fazit

JAMstack wins!

Für mich siegt Hugo klar nach Punkten gegen Wordpress. Insbesondere dann, wenn man die lokale Entwicklung mit betrachtet. Hugo wirkt deutlich frischer, schlanker und punktet auch in Sachen Sicherheit oder SEO. Der klassische Platzhirsch Wordpress ist immer noch legitim, aber wirkt angestaubt und aufwändig.

Dazu möchte hier ergänzen, dass ich bereits viele Jahre mit Wordpress gearbeitet habe und es mir immer ein gutes Werkzeug war. Insofern ist mein Benchmark nicht als Kritik an Wordpress zu verstehen - auch heute setze ich immer noch gerne Wordpress ein.

Weitere Quellen zum Thema:

Eine Auswahl von Frameworks / Generators

Wordpress