In letzter Zeit habe ich mich hier, ausgelöst durch Joost de Valks “Wir brauchen keine CMS mehr“-These, die am Ende in EmDash gemündet ist, viel mit dem Online Content Management beschäftigt. Da trifft es sich doch gut, wenn Jono Alderson mitten in diesem Flow daherkommt und behauptet, es gebe im Grunde nur vier Arten von Websites, kategorisiert nach ihrem Zweck. Sie alle benötigen ein jeweils anderes System zum Management des dort veröffentlichten Contents.
- React für Websites, die selbst das Produkt sind: komplexe, interaktive Anwendungen mit tiefer Integration und Zustandsverwaltung. React ist dafür gebaut, Apps zu entwickeln, nicht Websites, die sich wie Apps verhalten wollen. Wenn die Website das Produkt ist, braucht man diese Architektur.
- Shopify für Websites, die verkaufen: E-Commerce-Systeme, bei denen Transaktionen, Zahlungsabwicklung und regulatorische Compliance im Zentrum stehen. Shopify löst diese Probleme als geschlossenes System besser als jede selbstgebaute Lösung, weil es genau dafür optimiert ist.
- Static für Websites, die sich selten ändern: statische Informationsseiten ohne komplexe Workflows. Wenn sich Inhalte kaum ändern, ist ein statisches Setup das schnellste, einfachste und zuverlässigste System. Kein Server, keine Datenbank, keine Angriffsfläche.
- WordPress (oder ähnliche CMS wie Drupal, Typo3) für Websites, deren Hauptzweck Publishing ist: kontinuierliche Content-Produktion mit komplexen Workflows, strukturierten Inhalten und vielen Beteiligten. Diese Systeme sind dafür gebaut, dass viele Menschen gleichzeitig Inhalte erstellen, bearbeiten und veröffentlichen können.
Es gibt noch eine fünfte Kategorie: Websites, die schnell aufgezogen wurden, aber nicht auf Dauer konstruiert sind. Wer v0, Lovable, Bolt oder sonstige AI-Builder nutzt, hat keine Architektur gewählt, sondern die Frage nach dem Zweck der Website umgangen. Diese Websites nennt Jono Alderson “disposable”, weshalb ich bei den vier Kategorien bleibe. Solange eine Wegwerfseite (mein Begriff, nicht Jonos) ausreicht, sind solche Systeme eine vollkommen legitime Antwort. Das Problem ist, dass sie eben oft nicht ausreichen oder die Anforderungen schneller wachsen, als diejenigen, die sie erstellt haben, antizipieren konnten.
Die Begründung ist logisch, die Empfehlungen sind für jeden nachvollziehbar, der professionell in dem Bereich tätig ist. Die Wahl des Systems ist keine technische Entscheidung, sondern eine architektonische.
Your choice of CMS is not a tooling decision. It is a constraint system. It decides what kinds of problems you can solve, which ones you will struggle with, and which ones you will never even see coming. It shapes how content is created, how it flows, who can touch it, how it evolves, and what breaks when the organisation changes. It quietly defines the ceiling of your ambition and the floor of your operational risk.
Jono Alderson
Jono Aldersons Analyse liefert systemische Argumente für eine Entscheidung, die bislang meist emotional oder aus der Annahme heraus getroffen wurde, man könne mit der eigenen Kompetenz, gerade bei Unternehmen, die in technischen Bereichen tätig sind, “control, modernity, and technical seriousness” erreichen. Die vier Kategorien sind nicht nur eine banale Kategorisierung, sondern ein Gedankenmodell, das zu einer ehrlichen Bestandsaufnahme in einer Frage zwingt: Was ist der Hauptzweck der Website? Es geht nicht darum, was sie alles können soll, sondern wofür sie primär existiert.
Wer glaubt, diese Watsche wäre es gewesen, irrt. Denn jetzt erst, die Hälfte von Jono Aldersons Artikel haben wir bereits hinter uns, kommt die eigentliche Eskalation. Alderson kritisiert Systeme, die versprechen, für alles eine Lösung zu sein: Page-Builder und Low-Code-Plattformen wie Wix, Webflow, Framer, Squarespace. Er nennt sie den “seductive middle ground”, den verführerischen Mittelweg. Diese Systeme bieten falsche Lösungen an, weil sie den falschen Lösungsweg stärken. Sie optimieren für das falsche Problem.
Die Probleme, die diese Plattformen lösen, sind Resultat einer Fehlentscheidung, die lange vor der Wahl des Systems getroffen wurde. Low-Code-Plattformen sind wie Gebäude, die schnell hochgezogen werden, ohne dass jemand gefragt hätte, was darin eigentlich stattfinden soll. Sie optimieren für den Moment der Erstellung, nicht für die Realität des Betriebs. Page Builder sind – das ist meine und nicht Jono Aldersons Meinung – noch viel schlimmer. Elementor, WPBakery, Divi oder Beaver Builder gehen nämlich noch einen Schritt weiter: Sie präsentieren sich als No-Code-Generallösung für eine riesige Auswahl von Problemen, während sie selbst diese Probleme verstärken, da sie die ihnen zugrunde liegenden Content-Management-Systeme zweckentfremden. Das ist, als würde ein Architekt ein Wohnhaus in eine Fabrik verwandeln, indem er einfach die Wände neu streicht und ein paar Maschinen hineinstellt. Die Struktur passt nicht zum Zweck, aber die Fassade sieht aus, als könnte es funktionieren.
Leicht ist das alles, einfach für Menschen, die “keine Ahnung von Programmieren haben”. Wir kennen dieses Argument. Diese simulierte Leichtigkeit ist allerdings nur ein Geschäftsmodell und nicht mehr.
There’s a class of tools which promise to sit neatly between all of this. Visual builders. Low-code platforms. Systems where designers can move fast, teams can ship without developers, and the interface feels like the product. […] In practice, these tools optimise for the moment of creation, not the reality of operation. They are excellent at producing a site quickly. […] The tools are designed to feel empowering. But they assume a level of simplicity which many organisations outgrow surprisingly quickly. […] These tools are not wrong. They are just optimised for a different kind of problem. One where speed of creation matters more than long-term coherence, and where the system is unlikely to be pushed very far.
Jono Alderson
Das Problem zeigt sich nicht sofort. Es wird übersehen, weil es unter Zeitdruck gar nicht erst Teil der Überlegungen ist. Erst später, wenn das Unternehmen wächst oder sich verändert, wird sichtbar, dass die Architektur nicht trägt. Das neue Problem, das aus der ursprünglich falschen Wahl erwächst, wird immer größer. Entweder man kapituliert oder man versucht, mit immer mehr Hilfskonstruktionen die Statik zu retten: Schwere Maschinen, die man in einer Fabrik vermuten würde, im vierten Stock eines Wohnhauses sind die Realität dessen, was Low-Code-Plattformen und Page Builder da draußen abbilden. Da wundert es nicht, wenn die Betreiber dieser Maschinen früher oder später über mangelnde Effizienz, Produktionsengpässe und “dieses merkwürdige Knacksen im ganzen Gebäude” klagen.
Wer in diesem Bereich tätig ist, kennt diese Klagen. Die Kundinnen und Kunden beschreiben Friktionsverluste, unerträgliche Komplexität, den Zwang, für jede Kleinigkeit jemanden mit Development-Erfahrung zu brauchen. Sie können nicht exakt benennen, was nicht passt, aber sie spüren es. Das Gebäude steht noch, aber es knarrt und hin und wieder springen Türen ohne menschliches Zutun auf. Der Strom fällt aus, man muss den Sicherungskasten versetzen, damit man schneller darauf reagieren kann.
Oft ist das Problem nicht der Stack selbst, sondern eine architektonische Entscheidung, die Jahre zuvor getroffen und nie revidiert wurde. Die Statik wurde nie nachträglich angepasst, obwohl sich die Nutzung längst geändert hat. Die schweren Maschinen im vierten Stock waren nie Teil des ursprünglichen Plans. Und meistens merkt man das erst, wenn es zu spät ist und Investitionen wie “Wir brauchen einen schnelleren Server” oder Entscheidungen wie “Die Agentur, die unsere Website betreut, tut nichts dagegen” sind häufig schon gefallen.
The trouble is that many teams don’t realise which problem they have until much later. […] Most “hybrid” websites aren’t really hybrids. They’re one dominant system with a secondary concern bolted on. A publisher adds commerce. A retailer adds content. A product adds marketing pages. […] Problems usually start when teams treat both as equal – and try to optimise the core architecture for everything at once. […] This is the pattern behind many of the struggles people attribute to specific tools. It’s rarely the platform. It’s the mismatch between the shape of the system and the way it’s being used. […] The safer move […] Decide what the system primarily is. Optimise for that. Let everything else be secondary, even if that means accepting some constraints.
Jono Alderson
Das ist das Paradox of Choice in seiner reinsten Form. Zu viele Optionen führen zur falschen Entscheidung, weil die eigentliche Frage nie gestellt wurde. Die meisten Teams wählen nicht das falsche System, weil sie die Technologie missverstehen, sondern weil sie sich selbst missverstehen. Entscheidungen werden häufig emotional getroffen: aus Vertrautheit mit einem bestimmten Stack, aus Betriebsblindheit, weil’s auf Reddit gerade populär ist, oder aus dem allerschlimmsten Grund, nämlich der gefährlichen Annahme, man könne jedes Problem mit der eigenen Kompetenz und ohne Zuhilfenahme von Profis lösen. (KI verschärft die Situation noch, weil sie denselben Irrglauben bestärkt.)
Es gibt vier Arten von Websites. Aber darum geht es nicht. Es geht darum, dass die meisten nicht die falsche Technologie wählen, sondern die falsche Frage stellen. Wer fragt “Welches System wollen wir nutzen?”, hat bereits verloren, denn die Architektur wird einzig durch die richtige Frage bestimmt. Man muss mit Jono Alderson nicht in der Wahl der Technologie übereinstimmen, aber man muss ihm darin rechtgeben, dass die Frage allesentscheidend ist. Und die entsteht in dem Moment, in dem man entscheidet, wofür man baut. Sie zu stellen, wäre grundsätzlich und immer die beste Lösung, aber wer verkauft heute schon “gute Lösungen,” wenn man sie auch “schnell” haben kann?
In der Hustle-Culture zählt Geschwindigkeit eben mehr als Klarheit, also bauen wir Wohnhäuser, die wir mit Industrierobotern füllen und Fabriken, in die wir Wohnungen hineinpressen. Und KI macht das noch einfacher – sowohl in der Machbarkeit als auch in der Vertretbarkeit. Denn sie schwächt den kritischen Blick, weil die Versprechungen der Technologie die Mühen des späteren Umbaus vernachlässigbar erscheinen lassen. Das geht natürlich alles lange Zeit gut, bis es eben irgendwann nicht mehr gut geht, das Gebäude knarrt und die ersten Risse im Gemäuer nicht mehr durch Anstrich allein wegzumachen sind. Dann sagt auch der motivierteste Baumeister zum Start-Up Founder mit engem Zeitplan: Ja dit wird teuer!