Kurz bevor AI das “Only Topic” geworden ist, versuchte die Webdevelopment Agentur Szene, das Thema Headless bei ihren Kunden zu platzieren. Das schlagende Argument war hier die Performance mit der Ergänzung, externe SaaS Provider direkt zu integrieren. Von der Möglichkeit, dann auch eigene Apps für Apple und Android bereitzustellen, wurde schnell abgerückt. Auch, weil es technologisch von ihnen nicht geliefert werden kann und der Bedarf bei den Kunden einfach nicht gegeben ist. Das Thema landete auch bei mir. Vor allem als Sachverständiger und Experte wurde ich dazu gefragt: Brauche ich das? Performance Probleme wird das nicht lösen. So meine knappe Antwort. Dann habe ich aber 4 Monate intensiv in einem Contentful Projekt programmiert. Und jetzt werden wir unsere Chancen mit dem ASTRO JS Framework nutzen. Am Anfang gehe ich erstmal auf Vorbehalte ein und begründe sie auch.
Headless ist eine echte Trennung von Frontend und Backend und lässt Teams nach vorne kommen
Lasst mich ein wenig ausholen. Eine Internetseite, egal ob Content oder Commerce, besteht aus Daten, die in einzelne Views, in weiteren Templates genannt, gebracht und dann gerendert werden. Das bedeutet für die Entwicklung, dass diese nur in lauffähige Systeme gebracht werden können. Dabei müssen Dateien direkt in dem System bearbeitet werden. Das stellt schon eine große Hürde für alle, die am Frontend arbeiten, dar. Aber noch viel schwieriger ist es, die jeweilige Template Engine und die Struktur, in der sie sich befinden, zu verstehen. Dazu kommen noch Eigenheiten der Systeme, die leider sehr viel Erfahrung benötigen. In der Folge sitzen Frontend Devs buchstäblich immer rum und warten auf fertige Stände. Eine extreme Ressourcenverschwendung und eine hohe frustrierende Belastung. Wäre das von einander getrennt, könnte deutlich besser miteinander gearbeitet werden. Die Vorteile würden alleine mehrere Blog Posts füllen. Galaktisch.
Wer die Möglichkeiten von Headless nicht nutzt braucht sie auch nicht
Vielleicht wart ihr mal damals vor der Welt, in der es nur noch künstliche Intelligenz gibt, auf einem Meetup zum Thema Headless von jemandem, der Marketing macht. Das war eines der wichtigsten Argumente, dass die Webseite auch über die API als echte App zur Verfügung gestellt werden kann. Nun ehrlich gesagt, wer will denn bitte eine Webseite als App. Haben sie nicht in den Jahren davor Responsive Design – RWD – genau für diesen Zweck angepriesen. Kurz darauf kommen dann Möglichkeiten der Integration weiterer API-Schnittstellen. Kommende Meetups, die eigenen Workshops direkt vom Anbieter, Wetterprognosen, Wasserstände und Temperaturen, Formulare aus CRM Systemen etc. Aber all das erfordert keine Integration in ein Frontend, sondern kann auch im Backend und an jeder anderen Stelle implementiert werden. Einen echten Vorteil bietet die Implementierung in ein Frontend nicht, vor allem, weil hier dann auch ein Caching implementiert werden muss. Ich habe dafür noch keinen echten Usecase gefunden.
Performance hat nichts mit Caching zu tun und die Probleme können nur da gelöst werden, wo sie auch sind
Ein weiterer Mythos, der gerne vorgeschoben wird, ist Performance. Hier wird die Schuld direkt im jeweiligen System gesucht. Z.B. TYPO3 ist viel langsamer als WordPress. Das ist völliger Quatsch. Aber in beiden Systemen kann individuelle Programmierung zu starken Performance Einbrüchen führen. Die Antwort hier sind statische Caches. Im Grunde wird der erzeugte HTML abgelegt. Andere Probleme sind zu große Bilder, zu viel HTML, zu viel CSS, Javascript etc. Kurz gesagt: Frontend-Probleme. Und wie sollen die jetzt durch Frontend Developer gelöst werden? Das entscheidende Problem ist, das HTML wieder an dem Frontend zu cachen. Das eigentliche Problem ist dabei die schnelle Bereitstellung der Daten mit einem performanten Frontend. Und das löst kein Headless. Ganz im Gegenteil. Das Backend muss für Aktualisierungen sogar sehr kompliziert über Webhooks mit dem komplett entkoppelten Frontend kommunizieren. Performance ist ein komplexes Thema. Dafür müssen alle Komponenten und ihre Verbindungsstücke sehr gut getuned werden. Ein komplett neue Technologie ins Rennen zu werfen ist hier falsch und auch fahrlässig. Das kann viel Frust und Enttäuschung bringen.
Legacy Systeme können barrierefrei werden und das ist eine echte Chance für uns alle
Ich habe mich seit über 20 Jahren auf das Thema Testing und Refactoring spezialisiert und an über 300 Webprojekten gearbeitet. Echte Probleme machen dabei historisch gewachsene Projekte. Nehmen wir mal die Seite des Duisburger Schwimmverein 1898. 30 Redakteurinnen schreiben in ca. 8 Jahren über 1000 Artikel und laden ca. 15 GB Bilder in das System. Das ganze wurde mit TYPO3 erstellt. Die Sprünge in dem System und die starke Entwicklung hat es mir nicht erlaubt, Schritt zu halten. Aber auch die Größe habe ich nicht verstehen können. So ähnliche Probleme gibt es überall. Die Komplexität des Projektes macht Updates zu aufwändig. Davor kann sich kein System schützen. Aber genau da besteht echt Hoffnung. Alle Systeme können in einen Headless Modus versetzt werden. Und von da kann man dann ein ganz neues Frontend nutzen. Das bedeutet State of the Art Technologie 2024 und noch besser barrierefreies Webdesign. Denn das lässt sich aus oben genannten Gründen nicht mehr in ein Legacy System implementieren.
Statisches Caching auf einem komplett neuen Level Serverless, Headless
Wozu genau braucht eine Internetseite eine Datenbank, einen Webserver und eine Programmiersprache? Vor allem damit der Inhalt der Webseite gepflegt werden kann. Betrachtet man daraus, wie oft sich Seiten tatsächlich redaktionell ändern, fällt schnell auf, daß ganz viele Seiten keine Änderungen haben. Daher ist der technologische Aufwand, der ständige Änderungen ermöglicht, auf Live Systemen gar nicht erforderlich. Dazu ist ein solches System auch immer ein erhebliches Sicherheitsrisiko. Das sieht man gerade am Beispiel von WordPress Webseiten. Hier hat man schon sehr früh angefangen, komplett statische Exports verfügbar zu machen. Sie sind super sicher und super schnell. Lösungen dafür müssen immer zusätzlich in Form von Plugins, oder in anderen System Extensions oder Bundels genannt, implementiert werden. Das Astro Framework bietet diese Funktionen out of the Box. Damit ist es dann möglich Webseiten viel sicherer, einfacher, schneller und deutlich günstiger zu hosten. Das ist die Zukunft, für zufriedene User und einen besseren Planeten.
Fazit zum Astro Framework und einem technologischen Schulterblick
Kurz gesagt, es lohnt sich. Das Astro Framework ist mehr als nur Javascript Framework. Es bietet sehr viel Funktionen und kann sich auch mit einer Vielzahl von Headless CMS verbinden und ermöglicht ein Serverless Hosting. Dazu kann es mit jeder Frontend-Technologie wie React, Vue, Svelte oder Angular auch parallel betrieben werden. Mit der extrem schnellen Astro DB hat man alles zusammen, was man für Webentwicklung braucht. Auf unserem YouTube Kanal haben wir eine Playlist zum Astro Framework als live Coding Tutorials veröffentlicht. Schaut euch das mal an.
