Warum die Geschichte des Webs mehr ist als eine Tooling-Geschichte

Letzte Woche stieß ich auf einen Artikel, der sich "The Descent" nennt – eine generated Story, die gerade in Entwickler-Kreisen die Runde macht. Die Kernthese klingt sauber: Früher war alles einfacher. Entwickler schrieben HTML, luden per FTP hoch, und dann wurde alles immer komplizierter. Ein aufgeräumtes Narrativ. Ein ordentlicher Zeitstrahl. Perfekt für Twitter-Pulls.

Das einzige Problem: Es ignoriert die Hälfte der relevanten Stimmen.

Was um 2008 wirklich passierte

Der Artikel nutzt 2008 als Ausgangspunkt. Angeblich saß damals jeder vor einem FTP-Upload und starrte auf eine Fortschrittsanzeige. Ich war 2008 jedenfalls nicht dort. Ich saß mitten in WordPress-Template-Dateien und baute Websites, auf denen meine Kunden sich einloggen, Inhalte schreiben und veröffentlichen konnten – ohne zu wissen, was FTP überhaupt bedeutet.

Ich war damit nicht allein. Die CMS-Ära war keine Randnotiz in der Geschichte. Sie war der Moment, in dem das Web Publishing im großen Stil demokratisiert hat. Menschen, die nie eine Programmiersprache lernen würden, konnten plötzlich eigene Websites betreiben. Das war keine Komplikation. Das war der Durchbruch.

Die vergessene Lernplattform: MySpace, Neopets und die Kunst des Self-Taught-HTML

Was das "The Descent"-Narrativ komplett unterschlägt: Millionen von Menschen lernten HTML und CSS, bevor sie jemals einen Code-Editor angefasst haben. Sie lernten es auf MySpace. Dort bedeutete "Profile anpassen" inline Styles schreiben und herausfinden, was passiert, wenn man zu viele Marquee-Tags ineinander verschachtelt. Sie lernten es auf LiveJournal, wo die Textbox ihre IDE war und der Speichern-Button ihr Deployment-Workflow.

Neopets. LiveJournal. Frühes Blogger. MySpace. Das waren keine sozialen Netzwerke. Das waren praktische Web-Development-Bootcamps, verkleidet als Unterhaltung. Man wollte einen eigenen Cursor? Also hat man CSS gelernt. Man wollte seinen Namen in einer besonderen Schrift? Font-Tags waren die Lösung – und man fühlte sich ziemlich schlau dabei.

Diese Phase ist wichtig, weil sie zeigt: Web-Development-Kenntnisse haben sich durch Zugänglichkeit verbreitet, nicht durch formale Ausbildung oder professionelle Tools. Das Web hat sich selbst beigebracht.

Flash und der Traum von App-ähnlichen Erlebnissen

Dann war da Flash. Der ursprüngliche Artikel erwähnt es kaum. Das ist, als würde man über moderne JavaScript-Frameworks reden, ohne jQuery oder Node.js zu nennen. Flash war das, worüber Entwickler in den späten 90ern und frühen 2000ern interaktive Erlebnisse lieferten, die mit reinem HTML und CSS nicht erreichbar waren. Animationen. Streaming-Video. Web-Apps mit State. Flash konnte das.

Das iPhone hat Flash getötet, klar. Aber davor hat Flash die mentale Vorstellung einer ganzen Generation geprägt, was ein Web-Erlebnis sein könnte. Flash bewies: Nutzer wollen App-ähnliche Interaktionen – und zwar bevor die Browser das technisch hergaben. Die Nachfrage kam zuerst. Die Technologie folgte.

Wenn man diese Geschichte versteht, wird klar, warum Entwickler Ende der 2000er so aufgeregt auf JavaScript-Frameworks reagierten. Endlich hatten wir die Browser-APIs, um zu bauen, was Flash versprochen hatte.

Warum "Tooling erzeugt Tooling" eine unvollständige Geschichte ist

Die "The Descent"-These behauptet: Moderne Frontend-Komplexität existiert, weil jede Lösung neue Probleme schafft, die neue Lösungen brauchen. Nicht falsch. Aber es ist, als würde man erklären, warum Städte Staus haben, indem man beschreibt, wie jede neue Straße mehr Verkehr erzeugt. Technisch korrekt. Verfehlt die menschlichen Gründe, warum Menschen weiterhin Städte bauen.

Die echten Treiber der Web-Development-Evolution sind vielfältiger:

Das Web-Plattform selbst. Browser-Fähigkeiten haben sich erweitert. WebGL machte 3D möglich. Service Workers ermöglichten Offline-Erlebnisse. WebAssembly öffnete neue Performance-Türen. Jede Erweiterung dessen, was Browser konnten, lud neue Tools ein, diese Möglichkeiten auszunutzen.

Kulturelle Gespräche. Konferenzen, Blogposts, Stack-Overflow-Threads und später Reddit und Twitter haben geprägt, wie Probleme gerahmt wurden und welche Lösungen sich durchsetzten. Die "Best Practices", die wir zitieren, wurden nicht entdeckt – sie wurden verhandelt, manchmal jahrelang diskutiert, und schließlich in Konventionen gegossen.

Wirtschaftliche Realitäten. Unternehmen sind gewachsen. Engineering-Teams von drei auf dreihundert Leute. Die Probleme, die zählten, verschoben sich von "Wie bauen wir dieses Feature?" zu "Wie maintainen wir diese Codebase über zwanzig Engineers hinweg?" Tooling folgte dem Geld und den Schmerzpunkten.

Mentale Modelle und Prinzipien. DRY, KISS, YAGNI, die LIFT-Namenskonvention – diese Ideen kamen nicht aus dem Nichts. Sie kristallisierten sich aus Jahren, in denen Entwickler Schmerz erlebten und ihm einen Namen gaben. Sie wurden das Vokabular, das neue Entwickler erbten.

Das Pendel-Narrativ behandelt Frontend-Geschichte als Schleife. Ich würde argumentieren: Es ist eher eine Spirale. Wir kommen zu ähnlichen Ideen zurück, aber auf höherem Niveau, mit mehr Kontext, besserem Tooling und manchmal – aber nicht immer – mehr Weisheit.

Was das für Entwickler heute bedeutet

Wenn du heute als Entwickler baust, existierst du an einem bestimmten Punkt auf dieser Spirale. Du hast Zugang zu Frameworks, Tooling und Möglichkeiten, die Entwickler 2008 sich nicht vorstellen konnten. Gleichzeitig stehst du vor Problemen, die sie nicht hätten vorhersehen können.

Die Erkenntnis sollte nicht sein, dass Komplexität schlecht ist oder einfache Tools immer besser. Die Erkenntnis ist: Die Tools, die du benutzt, sind Antworten auf reale Probleme. Und diese Probleme zu verstehen – woher sie kamen, wer sie erlebte, welche Lösungen zuerst ausprobiert wurden – macht dich zu einem besseren Praktiker.

Wenn dein Build-Pipeline crasht, kämpfst du nicht gegen willkürliche Komplexität. Du stehst an der Schnittstelle von Jahren voller Entscheidungen, getroffen von Menschen, die versucht haben, reale Probleme unter realen Constraints zu lösen.

Über KI-generierte Geschichte (inklusive dieser)

Hier die unbequeme Frage, die "The Descent" aufwirft: Was passiert, wenn die Geschichte der Webentwicklung von Systemen geschrieben wird, die auf dem Web trainiert wurden? Der ursprüngliche Artikel war teilweise generiert. Meine eigenen Ideen hier sind geprägt von dem, was ich gelesen habe – und das ist zunehmend KI-beeinflusster Text.

Wir sollten nachdenklich damit umgehen. KI-Systeme können existierendes Wissen synthetisieren, aber sie erleben nicht den Schmerz, um 2 Uhr nachts ein Production-Issue zu debuggen. Sie erleben nicht den Triumph, etwas zu shippen, das tatsächlich für Nutzer funktioniert. Geschichte von KI geschrieben könnte kohärent sein, aber hohl.

Das bedeutet nicht, dass wir KI-Unterstützung ablehnen sollten. Es bedeutet: Wir sollten in den menschlichen Erfahrungen verwurzelt bleiben, die die Tools geformt haben. Mit Senior-Developern sprechen. Primärquellen lesen, wenn möglich. Die Probleme selbst erleben, wenn es geht.

Das Web ist nicht durch Tooling zu dem geworden, was es ist. Es ist durch Menschen geworden – chaotische, meinungsstarke, collaborative, manchmal frustrierte Menschen –, die über Jahrzehnte zusammen Probleme gelöst haben.

Wir waren alle dabei. Wir haben nur aus verschiedenen Ecken derselben sich entwickelnden Plattform zugeschaut.

Welche Äras vermisst du in den gängigen Erzählungen über Webentwicklung? Schreib mir auf X – lass uns unsere Geschichte vergleichen.