Warum sich statische Content-Management-Systeme nicht gegen dynamische durchsetzen können.

Jekyll & Wordpress sind wohl die bekanntesten CMS. Doch es ist ein Kampf zwischen David & Goliath, beziehungsweise ein Vergleich von statischen und dynamischen Webseiten.

Welchen Vorteil haben statische Webseiten?

Der klare Vorteil von statischen Webseiten gegenüber von dynamischen ist, dass die einzelne Webseite nicht beim Laden erst generiert werden muss. Das bedeutet, dass bei einem Aufruf der Inhalt von Datenbanken erst geladen werden und anschließend an den Besucher gesendet werden muss. Bei statischen Webseiten wurde dieser Prozess bereits vor dem erstmaligen Aufruf bereits vorher ausgeführt. Dadurch ergeben sich enorme Performancevorteile, da die Webseite bereits komplett als .html-Datei auf wem Webserver vorliegt.

Platzhirsche für statische Webseiten-Generatoren sind Jekyll, Hugo, Gatsby und dennoch sind diese meist nicht die erste Anlaufstelle für Einsteiger. NodeJS, CLI und YAML-Konfigurationsdateien erschweren den Einstieg ungemein. Gerade für technische Laien gibt es keine grafische Benutzeroberfläche.

Wobei doch eine grafische Benutzeroberfläche einfach zeitgemäß wäre!

Das Platzhirsch-CMS Wordpress...

Wordpress, als Vertreter der dynamischen Content-Management-Systeme, bietet bei vielen Hosting-Anbietern eine "One-Click"-Lösung, wobei diese von den Anbietern meist selbst bereitgestellt wird. Mit nur einem Knopfdruck und im Handumdrehen steht ein vollwertiges CMS mit grafischer Benutzeroberfläche für den Anwender zur Verfügung. Zum Schluss noch ein vorgefertigtes (meist kostenfreue) Designvorlage installieren und fertig.

Und das ganze ohne ein einziges mal in ein schwarz-weißes-Kommandozeilen-Fenster zu blicken!

Natürlich gibt es auch CMS, welche wiederum auf Jekyll und Co. aufbauen und eine Administrationsoberfläche bieten, allerdings können diese dann an Abo-Modelle geknüpft sein und als anfänglicher Nutzer wird man mit Preisen konfrontiert, wo man nicht einschätzen kann, was und ob es überhaupt notwendig ist. Aus Sicht für Freelancer oder Agenturen wiederum, ist dies allerdings eine gute Option statische Webseiten anzubieten und gleichzeitig dem Kunden eine "einfache" und nachhaltige Möglichkeit zu bieten, den Inhalt selbst zu bearbeiten.

Der große Nachteil (noch) ist allerdings der einmalige hohe Konfigurationsaufwand und auf lange Sicht die Orchestration von zwei unabhängigen Systemen.

Wordpress wiederum bietet alles aus einer Hand und wenn etwas fehlt gibt es dutzende Plug-Ins/Erweiterungen, welche integriert werden können. Somit muss nur ein System verwaltet werden. Der große Nachteil von Wordpress ist jedoch, dass dieses CMS schon von Beginn an viel zu viel mitbringt, was gar nicht vom Endanwender benötigt wird und deshalb auch den Ruf besitzt "überladen" zu sein. Zum Beispiel finden sich bei den allermeisten Wordpress-Webauftritten das Plugin Yoast für SEO und WPRocket für die Seitengeschwindigkeit.

Allein die Tatsache, das weitere Plugins notwendig sind, sodass die Webseite einigermaßen gut performt, spricht doch schon gegen den Einsatz von Wordpress, wenn es bereits bessere Alternativen gibt...

Dennoch ist die Community hinter Wordpress so stark und groß, dass es bereits für alle erdenklichen Probleme und Szenarien Lösungen gibt, da Wordpress auch bereits einige Jahre auf dem Buckel hat. Hingegen bei den jüngeren statischen Generatoren hat man vermeintlich kleine Communities und manche Probleme stecken noch in den Kinderschuhen, beziehungsweise liegen noch im verborgenen.

Die große Herausforderung besteht demnach darin, statische Webseiten Generatoren um eine benutzerfreundliche Admin-Oberflächen zu erweitern, sodass Endanwender hier selbst einfach interagieren können.

Mittlerweile gibt es auch Lösungsansätze, welche Backend-Funktionen wie Erstellung/Verwaltung von Inhalten von der Präsentation (Frontend) logisch trennen. Dieser Lösungsansatz wird meist auch unter den Namen Headless-CMS geführt. Beispiele sind sogenannte Headless-CMS wie Siteleaf oder Forestry (Abo-Modelle für statische Webseitengeneratoren mit Benutzeroberfläche). Weitere mögliche Anbieter von solche hybriden Lösungen sind Ghost als Blogging-Plattform, Netlify oder Strapi. Dieser Ansatz ist deutlich performanter im Vergleich zu rein dynamischen Content-Management-Systemen wie Wordpress, allerdings ist Grenze zwischen statisch und dynamisch sehr fließend, da dynamische Ansätze durch Caching halbwegs statisch gemacht werden können.

Doch einen reinen statischen Website Generator mit grafischer Oberfläche ohne komplizierte Orchestration sucht man aktuell vergeblich. Die Einstiegshürden von aktuellen statischen Generatoren müssen weiter abgebaut werden und um eine grafische Benutzeroberfläche erweitert werden. Es gibt bereits Ansätze wie Jekyll-Admin oder Softwaretools wie Publii, allerdings konnten diese in vielerlei Hinsicht nicht überzeugen. Sei es eine steile Lernkurve für Template Erstellung oder der reine Fokus auf Blogs.

Im Idealfall besitzen Anwender elementares Wissen im Bereich HTML, CSS und JS und dann wäre es vorteilhaft auf diesem Wissen minimal aufzubauen um den Einstieg für das Erstellen einer eigenen Seite möglichst gering zu halten.

Somit wäre der einfachste Weg über eine simple Struktur von Ordnern mit HTML, CSS und JS, welche der Anwender oder Kunde selbst versteht und managen kann. Eine Möglichkeit hierbei wäre der Einsatz von PugJS, eine hoch performante Template-Engine, die es sehr einfach ermöglicht HTML-Dateien zu generieren oder miteinander zu verschmelzen. Somit lassen sich einzelne HTML-Auszüge relativ einfach wiederverwenden. Zusätzlich gibt es Programme, welche eine grafische Benutzeroberfläche bieten, welche die Konfiguration und Ausführung übernehmen. Einige Programme darunter sind Prepros, Codekit oder Scout. Mit einem Mausklick werden dann die .pug-Dateien verarbeitet. Das einzige was Anweder:innen dann noch lernen muss, ist ein wenig die Sprache pug selbst (ursprungich Jade) und schon kann es los gehen.

Ein Grundgerüst (Vorlage), dass auf Pug und Prepros aufbaut ist Nagediy:

GitHub - kreativ-anders/Nagediy: boilerplate

(Eine kurze Anleitung befindet sich in der README.md Datei.)