Dieser Artikel erschien ursprünglich auf Englisch unter jonoalderson.com. Er wurde mit freundlicher Genehmigung von Jono ins Deutsche übersetzt. Inhalt und Aussage stammen vollständig von ihm, wir haben lediglich die Sprache angepasst. Wir als Agentur finden den Artikel wichtig und gut. Deshalb möchten wir ihn auch einem deutschsprachigen Publikum zugänglich machen.

Die meisten Websites sind furchtbar.

Nicht nur langsam, sondern wirklich furchtbar. Überladen, fragil, völlig übertechnisiert. Sie laden langsam, bauen sich unvorhersehbar auf und verstecken ihren Inhalt hinter Megabytes an JavaScript. Auf dem Handy ruckeln sie. Sie frustrieren Nutzer und verwirren Suchmaschinen. Sie sind kaum noch zu pflegen. Und trotzdem nennen wir das Fortschritt.

Das Tragische daran: Es müsste nicht so sein. Früher war das Web schnell, stabil und robust. Doch wir haben es gegen einen JavaScript-Kargo-Kult eingetauscht.

Heute braucht es vier Entwickler, drei Frameworks und eine CI/CD-Pipeline, nur um eine Überschrift zu ändern. Eine einfache Webseite zu veröffentlichen ist zur Wissenschaft geworden.

Das ist keine Weiterentwicklung. Es ist selbst erzeugte Komplexität. Und wir haben sie zur Norm gemacht, weil wir irgendwann aufgehört haben, für Nutzer zu entwickeln und angefangen haben, für Entwickler zu bauen.

Wie wir hier gelandet sind

Etwa ab 2010 änderte sich etwas. Das iPhone war auf dem Vormarsch. Native Apps waren schlank, schnell, flüssig. Angular – das erste populäre JavaScript-Framework fürs Web – war gerade erschienen. Und plötzlich stand in jedem Website-Briefing derselbe Satz: „Kann das aussehen wie eine App?“

Entwickler, ausgestattet mit neuen Frameworks und guten Absichten, sagten: Klar. JavaScript konnte theoretisch nahtlose Übergänge und schicke Interfaces liefern. Also entwickelten wir in diese Richtung. Oder versuchten es zumindest.

Spoiler: Wir bekamen keine App-Performance. Und auch keine besseren Nutzererlebnisse. Was wir bekamen, war ein Wettrüsten der Komplexität.

Wir begannen, einfache Probleme – wie Navigation oder Layout – mit Werkzeugen zu lösen, die eigentlich für vollwertige Anwendungen gedacht waren.

Gleichzeitig wurde JavaScript mehr als nur eine Sprache fürs Frontend. Mit dem Aufstieg von Node.js wanderte JS auf die Serverseite – und mit ihm eine neue Welle an App-Entwicklern ins Web. Das waren keine Webdesigner oder Content-Publisher. Es waren Engineers, die darauf trainiert waren, Anwendungen zu bauen, keine Dokumente. Und sie brachten eine Architektur-zuerst-Mentalität mit: Patterns, State-Management, Dependency Injection, abstrakte Logik. Das Ergebnis? Ein schleichender kultureller Wandel – weg vom Bau einzelner Seiten, hin zum Engineering ganzer Systeme. Selbst dann, wenn der Nutzer einfach nur einen Artikel lesen wollte.

Und so haben wir die Spielregeln der Webentwicklung über Nacht neu geschrieben – basierend auf völlig anderen Bedürfnissen. Nicht Inhalt. Nicht Geschwindigkeit. Nicht Kompatibilität. Nicht Auffindbarkeit. Sondern: Code.

Je weiter wir diesen Weg gingen, desto mehr entfernte sich der Technologie-Stack von den Grundlagen. Semantisches HTML? Optional. Serverseitiges Rendering? Neu erfunden. Barrierefreiheit? Vielleicht, wenn Zeit bleibt. Performance? Egal, solange man Kosten sparen kann, indem man die Ladezeit auf das Gerät der Nutzer abwälzt statt auf den Server.

So wurde das Web nach und nach zu etwas, das man erst kompilieren muss, bevor man es veröffentlichen kann. Nicht weil die Nutzer es so brauchen. Sondern weil Entwickler wollten, dass es sich modern anfühlt.

Und für diese Entscheidung zahlen wir noch immer.

Der Kult der Developer Experience

Heute optimieren wir für „DX“ – die Developer Experience. Nicht für Nutzererlebnis. Nicht für Performance. Nicht für Ergebnisse.

Moderne Frameworks verkaufen sich über ihre DX. Die Dokus sind schick. Das Onboarding läuft reibungslos. Die Tools sind smart, integriert, clever. Man kann mit einem CLI-Befehl eine neue App aufsetzen und sich produktiv fühlen, noch bevor eine einzige Zeile Inhalt geschrieben ist.

Aber gute DX garantiert keine gute UX. Tatsächlich ist ist genau das Gegenteil der Fall. Denn je angenehmer wir es Entwicklern machen, desto mehr Abstraktion fügen wir hinzu. Und jede Abstraktion schafft Distanz – zwischen dem, was gebaut wird, und denen, für die es gedacht ist.

Mittlerweile generieren Komponentenbibliotheken den Code für Buttons. Seiten-Metadaten werden in JavaScript-Funktionen verwaltet. Bildlade-Strategien verstecken sich in Konfigurationsdateien.

Alles ist für Entwickler optimiert – und für alle anderen ein Hindernis.

Das ist kein Zufall. Es ist kulturell bedingt. Wir haben eine Branche geschaffen, in der Komplexität gefeiert wird. In der Cleverness belohnt wird. In der technische Raffinesse mehr zählt als Klarheit, Nutzerfreundlichkeit oder wirtschaftlicher Erfolg.

Es ist einfacher, eine Diskussion mit einem Verweis auf SSR-Kompatibilitätsprobleme zu gewinnen, als einfach zu fragen: „Warum benutzen wir eigentlich React für einen Blog?“

Und so optimieren wir weiter für die falschen Dinge. Weil es sich gut anfühlt. Weil es Spaß macht. Weil es modern aussieht. Und weil uns niemand davon abhält.

Komplexität wird zur Norm

So beginnt die Spirale.

Wir tolerieren Komplexität nicht mehr – wir erwarten sie. Wir gehen davon aus, dass jede Website einen Build-Step braucht, einen Bundler, eine Hydration-Strategie, ein Routing-Layer, ein API-Layer, ein Design-System und irgendeine clevere Logik zur Cache-Invalidierung. Wir bauen mit Microservices, hosten auf Edge-Netzwerken und nutzen Deploy-Pipelines, nur um einfachen Content auszuliefern.

Egal ob Blogpost oder Onlineshop – der Stack ist derselbe. Schwer, abstrakt, bis an die Grenze der Nützlichkeit durchengineert.

Und niemand versteht ihn. Wirklich niemand.

Nicht die Marketer, nicht die SEOs, nicht einmal die Entwickler, die ihn vor sechs Monaten gebaut haben. Jedes neue Tool bringt neue Abstraktionen, neue Syntax, neue Denkmodelle. Eine einfache Änderung an einer Überschrift, einem Meta-Tag oder einem Layout wird zur dreistufigen Deployment-Orgie.

Es ist Wahnsinn.

Wir haben das Web neu gebaut wie ein Flugleitsystem – nur um ein paar Kilobyte Text auszuliefern.

Und das Schlimmste? Der Großteil dieser Komplexität existiert nur, um Funktionen nachzurüsten, die das Web früher von Haus aus mitgebracht hat: Routing, Metadaten, Caching, Templating, Layout.

Das ist keine Innovation. Wir bauen kaputte Versionen von Werkzeugen nach, die wir längst hatten – und das auch noch schlecht.

Der Stack baut sich selbst neu – nach seinem eigenen Bild

Spulen wir vor bis heute. Ironischerweise versucht das JavaScript-Ökosystem nach Jahren der Abstraktion und Komplexität nun fieberhaft, genau das zurückzubringen, was es unterwegs verloren hat.

Serverseitiges Rendering? Wieder im Trend. Routing? Sorgfältig verwaltet. URL-Strukturen, Metadaten, sogar HTML-Ausgabe – alles wird Stück für Stück neu aufgebaut. Ein Plugin nach dem anderen.

Und all das sieht immer mehr nach dem aus, womit wir ursprünglich angefangen haben: ein klassisches CMS, das HTML rendert, serverseitig ausliefert und in der Nähe des Nutzers cached.

Nur dass es jetzt langsamer ist, schwerer zu pflegen und von einem fragilen Ökosystem aus Packages, Compilern und Edge-Handlern abhängt.

Wir bauen Plattformen wie WordPress und seine Funktionen im Grunde neu – mit dem zehnfachen Aufwand, aber ohne die Benutzerfreundlichkeit.

Schlimmer noch: Jede neue Schicht bringt neue Bugs, neue Kompatibilitätsprobleme und neue kognitive Lasten mit sich. Heute pflegen wir Hydrationslogik, Caching-Strategien und Build-Pipelines – nur um eine Homepage online zu bringen.

Es wäre lustig, wenn es nicht so erschöpfend wäre.

Das ist das Endstadium einer Entwicklerkultur, die vom Neuen besessen ist. Wir liefern keine besseren Websites aus. Wir erfinden grundlegende Infrastruktur neu – auf immer umständlichere Weise – und feiern dann, dass es irgendwie funktioniert.

Der Kreislauf aus Iteration und Instabilität

Der Stack kommt nie zur Ruhe.

Nichts ist stabil. Nichts ist fertig. Jeder Sprint, jede Roadmap, jedes Quartal bringt eine neue Initiative: Umstieg auf das neueste Framework, Einführung eines neuen Bundlers, Refactoring des Routing-Layers, Austausch der CMS-Integration, Neuaufbau des Caches.

Es hört nie auf. Und es bringt selten echten Nutzen.

Denn die meisten dieser Veränderungen lösen keine echten Nutzerprobleme. Sie beheben nur die Nebenwirkungen der letzten Architekturentscheidung. Wir iterieren nicht in Richtung Wirkung – wir iterieren, um nicht unterzugehen.

Während der Stack damit beschäftigt ist, sich selbst zu reparieren, kommt alles andere zum Stillstand.

Marketingkampagnen verzögern sich, weil die Komponentenbibliothek zu unflexibel ist. A/B-Tests werden gestrichen, weil die Analytics-Schicht nicht mit der Hydration-Strategie kompatibel ist. Content-Updates brauchen Tage bis zum Livegang. Einfache SEO-Anpassungen verschwinden im Backlog.

Und die Nutzer? Die können die Seite immer noch nicht laden.

Das passiert, wenn Komplexität zum Produkt wird. Wir optimieren nicht mehr für Ergebnisse. Wir optimieren die Optimierungsschicht.

Und dann fangen wir wieder von vorn an.

Kollateralschäden für Marketer und Nutzer

Diese ganze Komplexität frustriert nicht nur Entwickler – sie schließt alle anderen aus.

Marketer können keinen Text ändern oder Tests durchführen, ohne ein Ticket zu erstellen. Sie können keine Inhalte vorschauen, Layouts prüfen oder Seiten starten. Jede Änderung muss durch Entwicklerhände, Pipelines, Freigaben und Rebuilds.

SEOs kämpfen mit Rendering-Problemen, die sie nicht kontrollieren können. Seiten laden leer, zu spät oder gar nicht. Crawl-Traps entstehen. Metadaten verschwinden. Strukturierte Daten landen in einem JavaScript-Objekt – und werden vergessen.

Content-Strategen und Redakteure bearbeiten JSON-Blöcke, Markdown-Dateien oder Formularfelder im Headless-CMS – völlig losgelöst von dem, was Nutzer später tatsächlich sehen.

Selbst grundlegende Qualitätssicherung wird zur Herausforderung. Zeigt die Seite die richtige Überschrift? Funktioniert das Canonical-Tag? Man weiß es erst nach dem Deployment. Vielleicht.

Und die Nutzer? Die starren auf Lade-Spinner. Tippen auf kaputte Buttons. Warten darauf, dass der Zurück-Button sich fängt. Beobachten, wie sich Text verschiebt, während sich das Layout neu sortiert.

Das ist nicht die Zukunft des Webs. Das ist eine Katastrophe in Zeitlupe.

Wir haben Webseiten schwerer gemacht – schwerer zu veröffentlichen, schwerer zu finden, schwerer zu nutzen und schwerer zu pflegen. Und das alles im Namen moderner Entwicklung.

JavaScript ist mächtig – aber wird falsch eingesetzt

Lass uns eines klarstellen: JavaScript ist nicht der Bösewicht. Es ist mächtig. Es ist unverzichtbar. Es ermöglicht interaktive Elemente, dynamische Inhalte und Echtzeit-Updates. Es erlaubt uns, Werkzeuge zu bauen – nicht nur Seiten.

Richtig eingesetzt, bereichert es das Web.

Aber die meisten Websites müssen keine Werkzeuge sein. Sie brauchen keinen komplexen Zustand. Keine Echtzeitdaten. Kein dynamisches Routing. Sie sind keine Apps. Sie sind Broschüren, Kataloge, Portfolios, Artikel.

Und für solche Anwendungsfälle ist der moderne JS-Stack vollkommen überdimensioniert.

Selbst E-Commerce-Seiten – mit Produktoptionen, Variantenauswahl, Warenkorb-Funktionen und Modalfenstern – benötigen keine vollständigen Frameworks. All das lässt sich mit schlankem, zielgerichtetem JavaScript umsetzen. Kein clientseitiges Routing. Keine Hydration. Keine Komponentenhierarchien.

Ein paar Zeilen gut geschriebenes Vanilla-JavaScript (oder ja, sogar jQuery) reichen für 95 Prozent dessen, was die meisten Websites wirklich brauchen. Schneller. Einfacher. Zugänglicher.

Modernes CSS kann mittlerweile vieles von dem, was früher JavaScript erforderte – wie Toggles, Modals oder sogar Karussells – ganz ohne Skripting übernehmen.

Und ja, manche Seiten haben tatsächlich komplexe Zustände auf der Client-Seite: Login-Zustände, Währungsumschalter, regionale Verfügbarkeiten. Aber selbst das lässt sich oft eleganter und performanter mit serverseitiger Logik oder einfachem asynchronem JavaScript und AJAX lösen. Wir brauchen keine reaktive Laufzeitumgebung, nur um einen „Angemeldet“-Button anzuzeigen oder zwischen USD und EUR zu wechseln.

Stattdessen greifen wir automatisch zu Frameworks. Wir nutzen React, um eine Kontaktseite zu bauen. Wir setzen Hydration-Strategien für statische Inhalte ein. Wir kompilieren, bündeln, transpilen und optimieren Code, der gar nicht nötig wäre.

Das ist nicht nur verschwenderisch. Es ist schädlich.

Wir verbrennen Nutzeraufmerksamkeit, Entwicklerzeit und Unternehmensressourcen – nur um eine Interaktivität zu simulieren, die niemand verlangt hat.

JavaScript sollte das Sahnehäubchen sein. Nicht der Kuchen. Und schon gar nicht der Ofen, das Rezept und das Spülbecken.

Das Machtproblem

Je komplexer der Stack wird, desto mehr Macht konzentriert er.

Marketer, Redakteure, SEOs, Designer – sie alle sind vom Prozess ausgeschlossen. Denn selbst einfache Aufgaben erfordern inzwischen technisches Know-how. Du willst ein Title-Tag ändern? Sprich mit dem Engineering-Team. Du willst eine Kampagne starten? Erstell ein Ticket und warte zwei Sprints.

Alles läuft über das Dev-Team. Das bedeutet: Sie entscheiden, was wichtig ist, was veröffentlicht wird und was auf unbestimmte Zeit nach hinten geschoben wird.

Und je mehr Komplexität sie einbauen, desto unentbehrlicher werden sie.

Das ist (meistens) nicht böse gemeint. Es ist ein strukturelles Problem. Der Stack wird von Entwicklern gebaut – für Entwickler. Wenn also etwas kaputt geht, geändert oder erklärt werden muss, geht es zurück zu denen, die es gebaut haben. Das festigt das Modell. Es vertieft die Abhängigkeit. Es rechtfertigt noch mehr Abstraktion. Und noch mehr Kontrolle.

Das ist kein rein technisches Problem. Es ist ein organisatorisches. Wir haben die Kontrolle über das Web denen überlassen, die die Maschine verstehen. Und die sind so damit beschäftigt, sie zu reparieren, dass sie gar nicht mehr fragen, ob wir sie überhaupt gebraucht hätten.

Websites, die funktionieren

Es gibt einen besseren Weg. Und dafür muss man weder das Internet neu erfinden noch zurück ins Jahr 2005.

Wir müssen keine CMS abschaffen. Wir müssen JavaScript nicht verbieten. Wir müssen nur aufhören, jede Website wie ein Softwareprodukt zu behandeln.

Die meisten Seiten müssen einfach nur schnell laden, leicht zu bedienen sein, in der Suche auftauchen und einfache Dinge ermöglichen – lesen, klicken, scrollen, kaufen. Mehr nicht. Und dafür haben wir längst die passenden Werkzeuge:

• Servergerendertes HTML
• Semantisches Markup
• Saubere URLs
• Schlanke Templates
• Edge-Caching
• JavaScript dort, wo es echten Mehrwert bietet

Ob das WordPress ist, Eleventy oder eine eigene Lösung: Es geht nicht um das Tool – es geht um die Haltung.

Bau für die Nutzer. Bau für Performance. Bau für Wartbarkeit.

Wähle Einfachheit statt Cleverness. Transparenz statt Abstraktion. Ergebnisse statt Architektur.

Wir können trotzdem modern arbeiten. Inhalte versionieren, Vorschauen teilen, gemeinsam entwickeln, iterieren. Aber das Fundament muss das Web bleiben – keine App, keine Shell, keine Simulation.

Es geht nicht darum, zurückzugehen. Es geht darum, den freien Fall zu stoppen.

Das Web kann wieder funktionieren. Wir müssen es nur zulassen.

Das Web zurückerobern

Wenn du das Gefühl hast, deine Website sei schwerer zu pflegen, als sie sein sollte – du bildest dir das nicht ein.

Wenn es Tage dauert, ein Title-Tag zu ändern, wenn Produktseiten ruckeln, wenn der Blog ohne JavaScript nicht lädt… dann ist das nicht „einfach so“. Das ist eine Entscheidung. Eine, die ohne dich getroffen wurde.

Also: Stell Fragen. Widersprich.

„Warum nutzen wir ein komplettes JS-Framework für eine fast statische Seite?“
„Warum kann ich diesen Inhalt nicht selbst bearbeiten?“
„Warum braucht es eine Build-Pipeline, um eine Überschrift zu ändern?“
„Warum ist das hier kein einfaches HTML?“

Du musst keinen Code schreiben, um Architektur zu hinterfragen. Du musst nur Ergebnisse zur Priorität machen.

Und denk daran: Komplexität ist nicht nur eine technische Last. Sie ist auch eine finanzielle. Mehr Entwickler. Langsamere Releases. Höherer Wartungsaufwand. Weniger Agilität. Wenn der Stack aufbläht, steigen auch die Kosten.

Schnellere Seiten. Einfachere Pflege. Bessere Rankings. Zufriedenere Nutzer.

Du darfst genau das fordern.

Denn das ist nicht zu viel verlangt. Genau dafür wurde das Web gebaut.

Es wird Zeit, bessere Standards einzufordern.

Stell mehr Fragen. Erwarte mehr. Dränge auf Ergebnisse statt auf Architektur.

Das Web ist nicht aus Versehen kaputt. Es wurde so gebaut. Aber wir müssen das nicht hinnehmen.

Das heißt nicht, dass Frameworks keinen Platz haben. Große oder verteilte Teams profitieren oft von einem architektonischen Gerüst, gemeinsamen Konventionen und modularen Ansätzen. Aber dieses Gerüst ist selten passend dimensioniert. Meist rechtfertigt es sich durch Wachstum – und schafft damit den Bedarf nach noch mehr Entwicklern, um die entstandene Komplexität zu pflegen.

Und ja: Frameworks können schnell, barrierefrei und SEO-freundlich sein. Aber mal ehrlich – sie sind es fast nie. Nicht da draußen in freier Wildbahn. Nicht ohne tiefes Wissen, viel Zeit und sorgfältige Umsetzung. Die meisten Entwickler wissen nicht, was sie nicht wissen. Sie verlassen sich auf Standardkonfigurationen und magische Middleware, die im Hintergrund die Basics zerstört.

Das Ergebnis?

• Zurück-Buttons, die nicht funktionieren
• Aufgeblähte Bilder
• Unzugängliches Markup
• URLs, die sich nicht wie URLs verhalten
• Metadaten, die verschwinden
• Inhalte, die man nicht kopieren kann
• Buttons, die man nicht mit der Tastatur erreicht
• Modals, aus denen man nicht mehr rauskommt
• Scrollpositionen, die einfach verschwinden
• Überschriften, die mitten im Lesen verrutschen
• Analytics, die nichts mit der Realität zu tun haben
• Vorschauumgebungen, die lügen
• Und Seiten, die irgendwann mal laden

All das ist reparierbar.
All das ist vermeidbar.
All das ist die Folge davon, dass wir Tools einsetzen, die nie für diesen Job gedacht waren.

Es geht nicht darum, zu Tabellenlayouts zurückzukehren oder JavaScript zu verbannen.
Es geht darum, bewusst zu bauen.

Zu verstehen, was das Web uns von Haus aus gibt – und der Versuchung zu widerstehen, es von Grund auf neu zu bauen.

Es geht nicht um Reinheit. Es geht um Ergebnisse. Nutze, was funktioniert.

Aber frag dich: Funktioniert es für deine Nutzer – oder nur für deine Entwickler?

---