30 Jahre Webgeschichte anhand des `<br>`-Tags

 (artmann.co)
28 Punkte von GN⁺ 2025-12-17 | Noch keine Kommentare. | Auf WhatsApp teilen
  • Ein Artikel, der die Veränderungen vom statischen Web der 1990er über das JavaScript-zentrierte Web der 2010er bis zum Web des KI-Zeitalters der 2020er nachzeichnet und zusammenfasst, wie sich die Webentwicklung weiterentwickelt hat
  • Das Web, das mit dem &lt;br&gt;-Tag und FTP begann, erweiterte sich über PHP und MySQL rasch zu einer Plattform, die jeder bauen konnte
  • Mit Rails, Git und Heroku als Wendepunkten wurde die Webentwicklung in den 2000ern zu einer strukturierten, automatisierten und kollaborativen Industrie umgebaut und schuf die Grundlage für das Cloud- und Mobile-Zeitalter
  • Das Aufkommen von React und Build Chains, Docker sowie dem Node-Ökosystem in den 2010ern verankerte das Web nicht mehr als Dokument, sondern als vollwertige Anwendungsplattform
  • In den 2020ern verändern ChatGPT und Copilot die Art, wie Code geschrieben wird, und werden zu einem neuen Wendepunkt, an dem KI die Produktivität in der Entwicklung verstärkt
  • All diese Veränderungen hatten Komplexität als Preis und führten zu einem Demokratisierungsprozess des Webs, der mehr Menschen befähigt, Größeres zu bauen

The Static Web - Die Ära des statischen Webs

> "View Source was how you learned"

  • In den späten 1990ern (late 90s) war das Web ein Pionierfeld, von dem niemand wusste, was es einmal werden würde, und gerade diese Ungewissheit machte seinen Reiz aus
  • Persönliche Websites begannen nicht bei Unternehmen oder Organisationen, sondern auf persönlichen Servern und in einzelnen Verzeichnissen
    • Mit einem persönlichen Verzeichnis auf einem Unix-Server, HTML-Dateien und einem FTP-Client konnte man sich einen Platz im Internet schaffen
    • Schon mit einem einfachen Texteditor wie Notepad konnte man schreiben und Inhalte sofort veröffentlichen
  • Das Web dieser Zeit war ein kreativer Raum ohne Zensurinstanz oder Freigabeprozesse
    • Freies Veröffentlichen rund um Interessen wie Kochen, Dinosaurier oder Musik
    • Eine Struktur, in der man „das, was einen diese Woche interessiert“, sofort hochladen konnte
  • Gelernt wurde konsequent durch direktes Anschauen und Nachmachen
    • YouTube-Tutorials oder Stack Overflow gab es nicht
    • Wenn man wissen wollte, wie eine andere Website funktionierte, war Rechtsklick → View Source das grundlegende Lernwerkzeug
    • Für tiefergehende Inhalte lernte man aus echten gedruckten Büchern
  • Es war üblich, mit mehreren hundert Seiten starken Fachbüchern wie Core Java neben dem Rechner zu lernen und dabei zwischen Code und Buch hin und her zu wechseln
    • Eine langsame, aber nachhaltige Lernerfahrung
  • HTML war in einem Zustand, in dem Struktur und Stil vermischt waren
    • Tags wie &lt;table&gt;, &lt;font&gt; und &lt;center&gt; übernahmen zugleich Layout und Styling
    • Mit 1x1 transparenten GIFs (spacer GIFs) wurden Abstände justiert
    • Grob und ineffizient, aber es funktionierte
  • CSS gab es zwar, war aber faktisch noch nicht Mainstream
    • Das meiste Styling wurde über Inline-Attribute oder HTML-Tags selbst umgesetzt
    • Layouts löste man mit verschachtelten Tabellen
  • Dynamische Funktionen hatten eine extrem hohe Einstiegshürde
    • Selbst grundlegende Funktionen wie Gästebücher oder Besucherzähler erforderten CGI-Skripte
    • Sie mussten in Perl oder C geschrieben werden, und schon für die Verarbeitung eines einzigen URL-Parameters war viel Code nötig
    • Diese Komplexität begrenzte die Verbreitung des dynamischen Webs erheblich
  • Für das Problem gemeinsamer Layouts gab es kaum Lösungen
    • Header, Navigation und Footer wurden in jede HTML-Datei kopiert und eingefügt
    • Bei Änderungen mussten sämtliche Dateien angepasst werden
    • Es gab auch Ansätze, gemeinsame Elemente per &lt;iframe&gt; einzufügen, doch diese hatten große Nebenwirkungen
  • Browser-Kompatibilität war bereits ein ernstes Problem
    • Netscape Navigator (1994) und Internet Explorer (1995) lieferten unterschiedliche Rendering-Ergebnisse
    • Warnhinweise mit der Angabe bestimmter Browser und Auflösungen waren tatsächlich notwendig
  • Trotzdem hatte das Web dieser Ära eine enorme Anziehungskraft
    • Ohne Druck- oder Rundfunktechnik konnte man weltweit veröffentlichen
    • Das Web verwirklichte erstmals die Demokratisierung von Ausdrucksmöglichkeiten
  • Kostenlose Hosting-Dienste wie GeoCities (1994) und Angelfire (1996) boten Millionen Menschen Raum zum Gestalten
    • Über Webrings wurden Fanseiten und Communities miteinander verbunden
    • So entstand ein chaotisches, aber lebendiges Ökosystem
  • In Unternehmen gab es das Konzept eines „Web-Teams“ noch kaum
    • Wenn es überhaupt eine Website gab, wurde sie meist von „der Person, die sich mit Computern auskennt“, erstellt
    • Es war die Phase unmittelbar bevor Webentwickler als Beruf etabliert wurden
  • Die Werkzeuge waren primitiv und die Websites grob, aber
    • die Kernidee eines Raums, in dem jeder etwas bauen und teilen kann, wurzelte in dieser Zeit
  • Diese Ära, die mit dem &lt;br&gt;-Tag und viel Leidenschaft durchgehalten wurde, wurde zum Ausgangspunkt aller späteren Entwicklungen des Webs

Der LAMP-Stack und Web 2.0

"Everything was PHP and MySQL"

  • Auch nach dem Platzen der Dotcom-Blase im Jahr 2000 wuchs das Web weiter, und diese Zeit wurde zu einem Wendepunkt, an dem die Einstiegshürden für alle, die etwas bauen wollten, drastisch sanken
  • Der größte Durchbruch des statischen Web-Zeitalters war PHP (1995)
    • In einer Zeit, in der man für CGI Hunderte Zeilen in C oder Perl schreiben musste, war die Möglichkeit, URL-Parameter mit einer einzigen Zeile wie $_GET['name'] auszulesen, ein entscheidender Wandel
    • Keine Kompilierung, kein Speichermanagement, keine kryptischen Fehlermeldungen — einfach speichern und per Neuladen ausführen
    • XAMPP (2002) ermöglichte die gleichzeitige Installation von Apache, MySQL und PHP und vereinfachte damit den Aufbau einer lokalen Entwicklungsumgebung grundlegend
    • PHP löste erstmals wirklich das Problem der Layout-Wiederverwendung im statischen Web-Zeitalter
      • Mit einer einzigen Zeile wie include 'header.php' ließen sich gemeinsame Header und Footer verwalten
      • Die Erfahrung, mit einer einzigen Änderung alle Seiten zu verändern, war enorm aufregend
    • Trotz sprachlicher Schwächen lag die Stärke von PHP in seiner Zugänglichkeit
      • HTML und Logik waren vermischt, Funktionsnamen inkonsistent und die Sicherheits-APIs grob gestrickt, aber
      • man konnte es an einem Wochenende lernen und echte Services damit bauen
      • Mit Shared Hosting (5 $/Monat) sowie cPanel (1996) und phpMyAdmin (1998) als Standardausstattung sank die Hürde für den Einstieg ins Internet auf einen historischen Tiefstand
  • Die Datenbank, die zusammen mit PHP praktisch ein festes Gespann bildete, war MySQL (1995)
    • Fast alle Tutorials, Hosting-Angebote und CMS gingen von MySQL aus
    • Funktional war es ausreichend, doch bei der Verarbeitung internationalisierter Texte war es eine endlose Leidensgeschichte
    • Die Standardkodierung war latin1, und um UTF-8 korrekt zu verwenden, musste man
      • Datenbankeinstellungen, Verbindungs-Encoding und die HTML-charset-Deklaration sauber aufeinander abstimmen
    • Das Problem „ä statt ä“ blieb als symbolisches Trauma dieser Ära in Erinnerung
  • WordPress (2003) veränderte den Charakter des Webs selbst
    • Auch ohne Programmierkenntnisse konnte man nach einer 5-Minuten-Installation sofort veröffentlichen
    • Mit der Auswahl eines Themes und dem Schreiben von Beiträgen ließ sich eine Website betreiben
    • Die Demokratisierung der Website-Erstellung wurde damit praktisch Realität
    • Für nichttechnische Nutzer war WordPress eine Befreiung
      • Blogger, kleine Gewerbetreibende, Künstler und selbst Restaurants konnten nun eine Website haben
      • Mit dem „Blogger“ entstand eine neue Identität
      • Die Verbreitung ging so weit, dass das WordPress-Admin-Panel praktisch als „Website-Editor“ wahrgenommen wurde
    • Für Entwickler wurde WordPress fast zu einem Universalwerkzeug
      • Blogs, Portfolios, Unternehmensseiten, Communities und E-Commerce — alles lief auf WordPress
      • Mit WooCommerce (2011) wurde sogar E-Commerce absorbiert
      • Als Preis für die schnelle Umsetzung häuften sich Wildwuchs bei Plugins und technische Schulden durch Theme-Anpassungen an
  • Die Veröffentlichung von Gmail (2004) war das Ereignis, das die Möglichkeiten des Webs grundlegend neu definierte
    • Zu einer Zeit, als Hotmail und Yahoo Mail nur einige MB Speicherplatz boten
    • waren 1 GB kostenloser Speicher ein schockierender Wert
    • Die Botschaft „Nicht löschen, sondern suchen“ führte eine neue Nutzungsweise ein
    • Die eigentliche Innovation von Gmail war nicht der Speicherplatz, sondern das Erlebnis
      • Eine Oberfläche, in der man E-Mails lesen, schreiben und wechseln konnte, ohne die Seite neu zu laden
      • Konsequente Nutzung asynchroner Kommunikation auf Basis von AJAX (XMLHttpRequest)
      • Der Beweis, dass das Web nicht nur Dokument, sondern Applikation sein konnte
  • Google Maps (2005) hob diese Möglichkeit noch eine Stufe höher
    • Karten ließen sich per Klick und Drag verschieben
    • Natürliche Interaktion durch im Hintergrund geladene Tiles
    • Ab diesem Zeitpunkt etablierte sich der Begriff Web 2.0 endgültig
    • UI ohne Neuladen, abgerundete Ecken, Verläufe und Schatten wurden zur Grundsprache des Webs
  • Auch in Medien- und Social-Bereichen folgten entscheidende Veränderungen
    • Im Video-Bereich stellte YouTube (2005) die Verhältnisse auf den Kopf
      • Das Ende der Plugin-Hölle mit RealPlayer, QuickTime und Windows Media Player
      • Zwar Flash-basiert, aber mit dem Erlebnis „anklicken und sofort abspielen“
      • Video wurde nicht länger ein technisches Problem, sondern ein Ausdrucksmittel
    • Twitter (2006) präsentierte mit 140-Zeichen-Microblogging eine neue Form der Kommunikation
    • Facebook (2006) öffnete sich für allgemeine Nutzer, und soziale Netzwerke rückten in den Mainstream
    • Das Web wandelte sich von einem konsumorientierten Medium zu einer partizipativen Plattform
      • Es entstand eine Struktur, in der jeder zum Veröffentlichenden und Kreativen werden konnte
  • Trotz all dieser Veränderungen blieb JavaScript weiterhin schmerzhaft
    • Endloses Debugging wegen Unterschieden bei DOM-, Event- und AJAX-Implementierungen zwischen Browsern sowie Kompatibilitätsproblemen mit IE6
    • jQuery (2006) beendete dieses Chaos faktisch
      • $('#el').hide() funktionierte in allen Browsern gleich
      • $.ajax() vereinfachte asynchrone Kommunikation
      • Für viele Entwickler war jQuery praktisch gleichbedeutend mit JavaScript
        • Zugleich diente es als Puffer, der verhinderte, dass man die Browser-Funktionsweise direkt verstehen musste
    • Die Probleme dieser Ära wurden erst später als Probleme erkannt
      • SQL Injection und XSS waren bereits auf Tutorial-Niveau allgegenwärtig
      • Code, der Benutzereingaben direkt an Queries anhängte, war völlig üblich
  • Bei der Versionsverwaltung war Subversion (2000) der Mainstream
    • Commits waren schwergewichtig, Branches wurden gemieden
    • Ordnernamen wie final_final_REAL waren Alltag
  • Fehlende Standardisierung der Laufzeitumgebungen
    • Lokal lief Windows + XAMPP
    • Auf dem Server Linux + eine andere PHP-Version
    • „works on my machine“ wiederholte sich ständig
  • Auch ein Konzept für Package Manager fehlte
    • JS wurde als ZIP heruntergeladen und dann manuell im Ordner /js verwaltet
    • PHP-Bibliotheken wurden durch Kopieren von Dateien eingebunden
  • Teamstrukturen und Entwicklungsprozesse waren äußerst informell
    • Kaum Rollen wie PM oder EM
    • Keine Code-Reviews
    • Per FTP hochladen und direkt in den Betrieb übernehmen
    • Bei Störungen wurde direkt auf dem Produktionsserver spontan nachgebessert
  • Trotzdem war die Energie dieser Ära intensiv
    • Mit PHP und günstigem Hosting konnte jeder deployen
    • Das Gefühl verbreitete sich, dass man mit AJAX „echte Apps“ bauen kann
    • Durch soziale Plattformen konnte jeder ein Publikum haben
  • Dies war der Moment, in dem die Professionalisierung und Strukturierung der Webentwicklung gerade erst begann
    • Ruby on Rails (2004) deutete mit „Convention over Configuration“ bereits die nächste, stärker strukturierte Ära an
  • Die Entwickler dieser Zeit bauten das Web mit dem LAMP-Stack und jQuery-Plugins und zugleich mit der
    • Erwartung, „den nächsten großen Service zu bauen“

Framework-Kriege

"Rails changed everything, then everyone copied it"

  • Ende der 2000er Jahre (late 2000s) wurden Webanwendungen immer größer, und die bisherigen PHP-Skripte sowie manuell geprägten Strukturen stießen an ihre Grenzen

  • Als Lösung dieser Zeit kam der Framework-zentrierte Entwicklungsansatz auf, und die prägende Kraft dieser Bewegung war Ruby on Rails (2004)

    • Der tatsächliche Einfluss von RoR entfaltete sich ab etwa 2007–2008 richtig
    • Mit der Philosophie „Convention over Configuration“ legte das Framework Dateistruktur, Benennung und Verknüpfungen stellvertretend fest
    • Entwickler mussten nur noch den Regeln folgen, und das wurde nicht als Einschränkung, sondern als befreiender Geschwindigkeitsgewinn wahrgenommen

  • Rails präsentierte anschließend in einem Paket Konzepte, die zur Grundgrammatik der Webentwicklung wurden

    • Migrationen, mit denen sich Datenbankänderungen im Code verwalten lassen
    • ORM, das die Abhängigkeit von SQL stark verringerte
    • Ein Entwicklungsablauf mit standardmäßig integrierten Tests
    • Die praktische Standardisierung der MVC-(Model–View–Controller)-Struktur
    • MVC war ursprünglich ein Konzept aus dem Smalltalk der 1970er Jahre, wurde aber durch Rails zur Grundform der Webentwicklung
    • Nach dem Erfolg von Rails übernahmen fast alle Sprachökosysteme diese Formel
      • Django (2005) etablierte die Rails-artige Struktur in Python, Laravel (2011) in PHP
      • CakePHP (2005) und CodeIgniter (2006) entwickelten sich ebenfalls in derselben Strömung
    • Die Produktivitätssteigerung war keine Übertreibung
      • Was ein einzelner Entwickler an einem Wochenende bauen konnte, entsprach früher Arbeit auf Teamebene
      • Im Startup-Umfeld war es das ideale Werkzeug für schnelles Experimentieren und Iterieren
    • Tatsächlich wuchsen mehrere bekannte Dienste auf Rails heran
      • Basecamp (2004), Twitter (2006), GitHub (2008), Shopify (2006), Airbnb (2008)
      • Rails wurde bald als Symbol für Startup-Geschwindigkeit wahrgenommen

  • Frameworks steigerten zwar die Produktivität, doch Deployment blieb weiterhin ein Flaschenhals

    • Im PHP-Zeitalter war Deployment per FTP-Upload üblich, mit einer Struktur, bei der ein einziger Fehler den Dienst lahmlegen konnte
    • Selbst in besseren Fällen wurden Arbeiten wie SSH + SVN pull + Apache-Neustart manuell ausgeführt
    • Getrennte Release-Verzeichnisse, das Umschalten symbolischer Links und ähnliche Verfahren waren durchweg Custom-Lösungen und fragil

  • Was dieses Problem grundlegend veränderte, war Heroku (2007), das sich ab etwa 2009–2010 ernsthaft verbreitete

    • Mit einer einzigen Zeile git push heroku main war das Deployment erledigt
    • Serverkonfiguration, Webserver-Neustart und Skalierung wurden von der Plattform übernommen
    • Heroku etablierte damit faktisch das Konzept, das später PaaS (Platform as a Service) genannt wurde
      • Entwickler wechselten in eine Rolle, in der sie sich nur noch auf Code statt auf Infrastruktur konzentrierten
      • Durch die Popularisierung der Prinzipien von Twelve-Factor App (2011) verbreitete sich ein Cloud-freundliches Denken mit zustandslosen Prozessen, konfigurationsbasierter Steuerung über Umgebungsvariablen und Log-Streaming

  • Im selben Zeitraum fand auch ein grundlegender Wandel der Zusammenarbeit statt

    • Git (2005) führte ein verteiltes Versionsverwaltungsmodell ein und machte freies Committen, Branching und Mergen lokal möglich; da die Kosten für Branches nahezu null waren, wurden Experimentieren und Zurückrollen alltäglich
    • Das bisherige Subversion (2000) war zentralistisch aufgebaut, Branches waren schwergewichtig und Merges gefürchtet, weshalb viele Teams auf trunk-basierte Entwicklung angewiesen waren
    • Git war eine Innovation auf Werkzeugebene, aber GitHub (2008) verankerte es kulturell, indem es öffentliche Repository-Erkundung, Fork-basierte Entwicklung und Zusammenarbeit rund um Pull Requests zusammenführte
    • GitHub standardisierte die Code-Review-Kultur
      • Vor dem Mergen eines PRs musste der Code zwingend von jemandem angesehen werden
      • Diese Praxis breitete sich auch in die interne Unternehmensentwicklung aus
      • Das Ende einer Zeit, in der Code direkt in die Produktion ging
    • Auch die Art, zu Open Source beizutragen, wandelte sich von Patches auf Mailinglisten hin zu PR-Einreichungen per Klick, was die Einstiegshürde deutlich senkte

  • Gegen Ende dieser Phase tauchten zudem Veränderungen auf, die die Identität des Webs erschütterten

    • Mit dem iPhone (2007) und dem App Store (2008) stiegen native Apps rasant auf
    • Das mobile Web war damals sehr schlecht. Die Erfahrung bestand darin, Desktop-Seiten verkleinert und mühsam anzusehen, mit horizontalem Scrollen sowie ständigem Zoomen
      • Manche bauten zwar separate mobile Seiten wie m.example.com, doch die Grenzen waren offensichtlich
    • Native Apps waren schnell, boten Offline-Unterstützung und Push-Benachrichtigungen, und mit dem Slogan "There’s an app for that" wirkten sie wie die Zukunft
    • Webentwickler gerieten in eine Identitätskrise: Sollte man beim Web bleiben? Objective-C lernen? Würde das Web verschwinden?

  • Als Antwort auf dieses Chaos erschien Responsive Web Design (2010)

    • Ethan Marcotte (2010) zeigte mithilfe von CSS-Media-Queries einen Ansatz, bei dem sich Layouts an die Bildschirmgröße anpassen, und wies damit den Weg zu einer gemeinsamen Codebasis für Mobile und Desktop
    • Anfangs verbreitete sich das Konzept wegen unreifer Tools und zusätzlichem Arbeitsaufwand nur langsam, doch die Richtung, in die das Web gehen musste, war klar

  • Bootstrap (2011) war der Auslöser dafür, dass responsives Webdesign in der Praxis wirklich genutzt wurde

    • Aus internen Tools bei Twitter hervorgegangen, bot es Grid-System, grundlegende Typografie und Formularstile auf einmal und lieferte damit auch Entwicklern ohne Designer sofort nutzbare UI
    • In der Folge sah das Web zunehmend ähnlich aus, doch für viele Entwickler war Bootstrap die erste Erfahrung mit einer Komponentenbibliothek und einem Designsystem
    • Dieser Strom führte später zur Verbreitung systematischer Designsysteme wie Material Design (2014)

  • Auch die Infrastruktur veränderte sich in derselben Zeit rasant

    • Statt physische Server im Voraus zu kaufen oder zu mieten, wechselte man zu Strukturen rund um virtuelle Server (VPS), wodurch sich Serverressourcen bei Bedarf erzeugen ließen
    • AWS (2006) war zwar zuerst da, war aber komplex und stark auf Enterprise ausgerichtet, sodass es für einzelne Entwickler eine hohe Hürde darstellte
    • DigitalOcean (2011) senkte mit 5-Dollar-Droplets, einer intuitiven UI und schneller Serverbereitstellung die Zugangshürde zur Infrastruktur stark und gab auch Einzelentwicklern eine Flexibilität, die zuvor eher Großunternehmen vorbehalten war

  • Das Problem der Dateispeicherung wurde faktisch durch Amazon S3 (2006) gelöst

    • Es bot einen unabhängig von der Serveranzahl skalierbaren Speicher und ein einfaches Modell, das nach dem Upload sofort eine URL zurückgab
    • Probleme mit Benutzer-Uploads, Backups und Dateiverwaltung in Multi-Server-Umgebungen wurden damit auf einmal bereinigt

  • Node.js (2009) war für Webentwickler ein weiterer Schock

    • Auf Basis der Chrome-Engine V8 konnte JavaScript nun auf dem Server ausgeführt werden; für Frontend-Entwickler wirkte das attraktiv, bei Backend-Entwicklern rief es Skepsis hervor
    • Das Non-Blocking-I/O-Modell zeigte Stärken bei Echtzeitanwendungen, weshalb die meisten Tutorials letztlich bei Chat-Apps landeten
    • In dieser Zeit war Node noch eher ein Objekt der Neugier als Mainstream in der Produktion; reale Dienste wurden weiterhin vor allem mit Rails, Django und PHP gebaut, und auch das npm-Ökosystem steckte noch in den Anfängen
    • Die eigentliche Wirkung von Node zeigte sich später allerdings zunächst weniger auf dem Server als vielmehr bei Build-Tools und als Laufzeitbasis für Entwicklungsumgebungen

  • Im Datenbankbereich gewann der NoSQL-Trend an Bedeutung

    • MongoDB (2009) erregte Aufmerksamkeit mit einem dokumentbasierten Datenmodell, flexiblen Schemas und einer JSON-freundlichen Struktur
    • Es war stark beim schnellen Prototyping, bei Skalierbarkeit und in der Kompatibilität mit dem JavaScript-Stack, passte aber nicht zu jedem Dienst
    • Häufig wurde es mit der Begründung gewählt, man müsse „vielleicht irgendwann skalieren“, nur um dann schon bei einigen tausend Nutzern die Grenzen bei Transaktionen zu spüren

  • Das Startup-Ökosystem trat in dieser Zeit in eine Phase ernsthaften Wachstums ein

    • Mit Marc Andreessens Erklärung "Software is eating the world" (2011) und der Verbreitung der Lean Startup (2011)-Methodik etablierte sich der Zyklus aus MVP → Messen → Iterieren

  • Mit der Reifung der Tools begann die Wettbewerbsfähigkeit kleiner Teams mit wenigen Personen tatsächlich zu funktionieren

  • Auch der Entwicklungsprozess veränderte sich

    • Agile Manifesto (2001) und Scrum wurden populär, wodurch Stand-ups, Sprints und Retrospektiven fast wie ein Standard eingeführt wurden
    • Es entstanden auch viele Teams, bei denen von den Prinzipien nur noch die Form übrig blieb
    • Code-Reviews und automatisierte Tests verschoben sich von einer Empfehlung zu einer grundlegenden Erwartung, und CI-Systeme führten Tests bei jedem Commit aus, was die Professionalisierung und Spezialisierung der Softwareentwicklung beschleunigte

  • Allerdings waren Rollen, die heute als selbstverständlich gelten, damals noch nicht etabliert

    • Stand 2012 waren Teams ohne Engineering Manager, Product Manager oder systematisches Backlog- bzw. Ticket-Management weit verbreitet
    • Kleine Teams und flache Organisationsstrukturen waren üblich, und es war nicht ungewöhnlich, dass ein „Senior Developer“ erst drei Jahre Berufserfahrung hatte

  • Um 2013 herum sah das Web völlig anders aus

    • Leistungsfähige Frameworks, einfache Deployments, kollaborative Code-Arbeit über soziale Plattformen, mobile Unterstützung, günstige Infrastruktur und die vollständige Verbreitung von JavaScript kamen gleichzeitig zusammen
    • Nachdem das Web die mobile Krise überwunden hatte, wurde es im Gegenteil noch stärker und war bereit für die nächste Phase: das Zeitalter, in dem JavaScript alles beherrscht

Die Renaissance von JavaScript

"Everything is a SPA now"

  • Um 2013 herum hatte das Web durch Beispiele wie Gmail und Google Maps bereits bewiesen, dass es „echte Applikationen“ tragen konnte, doch der bisherige Ansatz aus jQuery + serverseitigem Rendering stieß zunehmend an seine Grenzen :contentReference[oaicite:0]{index=0}
  • Das Kernproblem war die Statusverwaltung (state)
    • In einer Struktur, in der der Server HTML erzeugt und jQuery Interaktionen ergänzt, wurde es rapide schwieriger, Daten und UI an mehreren Stellen konsistent zu halten
    • Je mehr derselbe Zustand in mehreren UIs gespiegelt werden musste – etwa bei Kommentaren, Zählern oder Benachrichtigungs-Badges –, desto stärker verhedderte sich der Code und verwandelte sich in eine Spaghetti-Struktur
  • Die gemeinsame Schlussfolgerung darauf war: Verschieben wir das gesamte Rendering auf den Client
    • Der Server wurde auf die Rolle einer API reduziert, die JSON zurückgibt
    • Im Browser verwaltet JavaScript die gesamte UI; die Struktur der SPA (Single Page Application) setzte sich durch
  • Die frühen SPA-Frameworks erschienen in genau dieser Phase
    • Backbone.js (2010) bot mit Modell- und View-Konzepten ein Mindestmaß an Struktur
    • Angular (2010) führte Two-Way Data Binding und Dependency Injection ein und versuchte einen Enterprise-orientierten Ansatz
    • Ember.js (2011) setzte mit dem Ziel „Rails für JavaScript“ auf starke Konventionen und brachte Routing, Daten und Templates komplett mit
    • Diese Frameworks waren ein Fortschritt, lösten aber das gemeinsame Problem der Komplexität bei der Synchronisierung von DOM und Daten nicht vollständig
      • Besonders Two-Way Binding erschwerte es, Update-Flüsse nachzuverfolgen, und erhöhte den Debugging-Aufwand
  • Der Wendepunkt war das Erscheinen von React (2013)
    • Als Facebook es als Open Source veröffentlichte, wirkte die JSX-Syntax wie eine Umkehr der Trennung von Zuständigkeiten und stieß zunächst auf Ablehnung
    • React schlug jedoch eine neue Denkweise vor: nicht das DOM direkt manipulieren, sondern das Ergebnis der UI abhängig vom Zustand deklarativ beschreiben
    • Der Kern von React liegt im deklarativen Modell und im Virtual DOM
      • Wenn sich der Zustand ändert, berechnet React nur die minimal nötigen DOM-Änderungen und übernimmt sie
      • Entwickler können sich auf die Statusverwaltung konzentrieren, ohne sich um DOM-Manipulationen kümmern zu müssen
    • Auch das Konzept der Komponenten war entscheidend
      • Die UI wird aus kleinen Einheiten wie Button, UserAvatar oder CommentList zusammengesetzt
      • Jede Komponente kann unabhängig gedacht und wiederverwendet werden
    • React verbreitete sich zunächst langsam und etablierte sich etwa 2015 im Mainstream
      • Vue.js (2014) bot ähnliche Konzepte in vertrauterer Syntax und stieg als Alternative auf
      • Die Framework-Kriege traten in eine neue Phase ein
  • Die Verbreitung von SPAs bedeutete eine explosive Zunahme der JavaScript-Menge
    • Das Problem war, dass das JavaScript, das Entwickler schreiben wollten, nicht dem JavaScript entsprach, das Browser verstanden
  • ES6 / ES2015 (2015) brachte große Sprachverbesserungen wie Arrow Functions, Klassen, Module und Promises
    • Callback-Hell und das Muster var self = this verschwanden, und JavaScript fühlte sich endlich wie eine moderne Sprache an
  • Doch die Browser-Unterstützung hinkte hinterher, und eine unveränderte Auslieferung war unmöglich
  • Babel (2014) löste dieses Problem als Transpiler, der modernes JavaScript in ES5 umwandelt
    • Der Preis dafür war, dass ein Build-Schritt in der JavaScript-Entwicklung unverzichtbar wurde
    • Die Zeit, in der Datei ändern und aktualisieren genügte, war vorbei
  • In diesem Prozess übernahm Node.js (2009) nicht als Server, sondern als Laufzeitumgebung für Entwicklungstools alle Entwicklerrechner
    • Selbst wenn das Backend nicht in Node geschrieben war, wurde die Installation von Node wegen der Build-Tools zur Pflicht
  • Auch die Build-Toolchain entwickelte sich schnell weiter
    • Grunt (2012) verwaltete als Task Runner komplexe Build-Schritte über Konfigurationsdateien
    • Gulp (2013) versuchte dies mit codebasierten Pipelines zu vereinfachen, blieb aber weiterhin komplex
  • Die entscheidende Veränderung kam mit Webpack (2014)
    • Nicht bloß ein Task Runner, sondern ein Module Bundler, der den Abhängigkeitsgraphen versteht
    • JavaScript, CSS, Bilder und Fonts wurden alle als Module behandelt
    • Konzepte wie Code Splitting und Hot Module Replacement wurden eingeführt
    • Der Preis dieser Leistungsfähigkeit war ein berüchtigter Konfigurationsaufwand
      • Webpack-Konfigurationen wurden zum Meme, und in jedem Team gab es „die eine Person, die das versteht“
      • Wenn diese Person ging, blieb die Konfiguration als Relikt zurück, das niemand anzufassen wagte
  • Gleichzeitig wuchs das npm-Ökosystem explosionsartig
    • Statt Bibliotheken direkt herunterzuladen, verlagerte sich alles auf npm install
    • moment, lodash und selbst winzige Utilities wie left-pad wurden als Pakete verteilt
    • Der left-pad-Vorfall (2016) machte die Verwundbarkeit des Ökosystems sichtbar
      • Durch das Löschen eines Pakets mit nur 11 Zeilen schlugen die Builds von Tausenden Projekten gleichzeitig fehl
      • Sogar React und Babel konnten nicht mehr installiert werden
      • npm griff beispiellos ein und stellte das Paket zwangsweise wieder her, um die Lage zu bereinigen
    • Die Bequemlichkeit blieb erhalten, aber die Realität der Dependency Hell wurde allen bewusst
  • 2016 erreichte die Komplexität ihren Höhepunkt
    • Der satirische Text „How it feels to learn JavaScript in 2016“ verbreitete sich stark
    • Die Erschöpfung darüber nahm zu, dass man für eine einfache Webseite unzählige Tools wie React, Webpack, Babel und Redux brauchte
    • Das Ökosystem veränderte sich so schnell, dass erlerntes Wissen rasch veraltete
    • Trotzdem waren die Ergebnisse eindeutig
      • Interaktive Web-Applikationen auf einem zuvor unmöglichen Niveau wurden machbar
      • Die Komplexität wurde als Preis des Ehrgeizes akzeptiert
  • Gleichzeitig begann Docker (2013), ein ganz anderes Problem zu lösen
    • Das Problem „works on my machine“ wurde mit Containern angegangen
    • Mit einem Dockerfile ließ sich die Laufzeitumgebung definieren und überall identisch ausführen
    • Anfangs war die Einführung wegen Performance-Problemen auf dem Mac und verwirrender Netzwerkkonfiguration nicht einfach
      • Mit Docker Compose, Docker Swarm und später Kubernetes (2014) begann der Orchestrierungs-Krieg
      • Um 2017 herum war zumindest klar, dass Container die Zukunft waren
  • Parallel dazu verbreitete sich der Trend zu Microservices
    • Er bot Vorteile wie Service-Trennung und unabhängige Deployments
    • Dafür entstanden neue Komplexitäten wie Service Discovery, Load Balancing und Distributed Tracing
    • Viele Teams erkannten erst später, dass sie die Komplexität des Monolithen gegen die Komplexität verteilter Systeme eingetauscht hatten
  • In dieser Zeit stieg die Reife von Web-Applikationen sichtbar an
    • Slack (2013) ersetzte E-Mail als schnelles, durchsuchbares Kollaborationstool
    • Figma (2016) drang als browserbasiertes kollaboratives Design-Tool in den Bereich von Desktop-Apps vor
    • Zusammen mit Notion (2016) und anderen bewies es, dass das Web Software auf Desktop-Niveau umsetzen konnte
    • Diese Beispiele lieferten eine Rechtfertigung für die Komplexität von React, Webpack und der Build-Toolchain
  • Auch die Organisationsstruktur trat in eine Reifephase ein
    • Um 2016 herum etablierten sich Product Manager und Engineering Manager als Standardrollen
    • Die anfangs flachen Teamstrukturen wandelten sich schrittweise zu prozessorientierten Organisationen
    • Scrum und agile Rituale verbreiteten sich breit und wurden je nach Team entweder zum Werkzeug oder zur bloßen Form
  • 2017 ging das Ökosystem allmählich in eine Phase der Stabilisierung über
    • React war de facto zum Gewinner geworden
    • ES6 war zur Standardsyntax geworden
    • Webpack und Docker wurden zwar schmerzhaft, aber als Standards akzeptiert
  • Der nächste Schritt war bereits angekündigt
    • Der Aufstieg von TypeScript
    • Meta-Frameworks wie Next.js
    • Einfachere Deployment-Erfahrungen
  • Doch dafür gab es eine Voraussetzung
    • Nur Entwickler, die das Chaos dieser JavaScript-Renaissance durchquert hatten, konnten zum nächsten Schritt weitergehen

Das TypeScript-Zeitalter

"Types are good, actually"

  • Nach der JavaScript-Renaissance beruhigte sich das Wildwuchs bei den Tools, und TypeScript markierte den Wendepunkt, an dem das Ökosystem in eine Phase der Reife eintrat.
  • TypeScript (2012) führte statische Typen in JavaScript ein, wurde aber anfangs lange ignoriert, weil es der Philosophie dynamischer Sprachen zuwiderlief und einen zusätzlichen Build-Schritt erforderte.
    • Mit wachsender Größe von Anwendungen wurden die Grenzen dynamischer Typisierung immer deutlicher.
      • Nach Änderungen an Funktionssignaturen stieg der Aufwand, alle Aufrufstellen nachzuverfolgen.
      • Die Lesbarkeit litt, weil sich die Form von Objekten im Code schwer erkennen ließ.
      • Immer wieder führten einfache Tippfehler zu Störungen in Production.
    • Ab 2017–2018 verbreitete sich die Einführung von TypeScript rasant.
      • Refactorings wurden durch Autovervollständigung und statische Analyse deutlich zuverlässiger.
      • Interfaces übernahmen die Rolle einer erzwingbaren Dokumentation, die mit dem Code synchron blieb.
    • Die Akzeptanz durch zentrale Frameworks wirkte als Wendepunkt.
      • Angular setzte auf eine TypeScript-first-Strategie.
      • Mit ausgereiften Typdefinitionen für React und der auf TypeScript basierenden Neufassung von Vue 3 wurde es als faktischer Standard wahrgenommen.
      • Ab etwa 2020 wurden neue Projekte in reinem JavaScript kaum noch gewählt.
    • TypeScript verbesserte die Zugänglichkeit von Codebasen erheblich.
      • Neue Teammitglieder konnten allein durch das Lesen von Typdefinitionen das Domänenmodell verstehen.
      • Die geringere Abhängigkeit von implizitem Wissen senkte die Kosten beim Skalieren von Teams.
  • Die Verbindung mit VS Code (2015) veränderte die Developer Experience entscheidend.
    • Intelligente Autovervollständigung, Inline-Fehleranzeigen und verlässliche Refactorings wurden verfügbar.
    • Sublime Text und Atom verloren nach und nach an Einfluss.
  • Über React bildete sich eine weitere Abstraktionsschicht.
    • Als UI-Bibliothek bot React keine Standardlösung für Routing, Data Fetching oder SSR.
  • Next.js schloss diese Lücke als Meta-Framework, das dateibasiertes Routing, Server-Side Rendering, API-Routen und automatisches Code-Splitting standardmäßig mitbrachte.
    • Entsprechende Frameworks wie Nuxt, Remix, SvelteKit und Gatsby traten ebenfalls auf den Plan.
    • Im React-Ökosystem etablierte sich Next.js als faktische Standardwahl.
  • Mit der Verbreitung von Meta-Frameworks ließ die Erschöpfung durch fragmentiertes Tooling aus der vorherigen Ära deutlich nach.
    • Was früher das manuelle Zusammensetzen von webpack- und Babel-Konfigurationen war, wurde in sinnvolle Defaults integriert.
  • Auch Deployment-Umgebungen wurden radikal vereinfacht.
    • Vercel und Netlify boten mit einer bloßen GitHub-Anbindung automatische Deployments und Preview-Umgebungen.
    • Designer, PMs und QA konnten Änderungen vor dem Merge in einer realen Umgebung prüfen.
  • Der Einfluss von Heroku nahm ab, während neue PaaS-Anbieter wie Railway und Render aufstiegen.
  • Rund um AWS Lambda (2014) verbreitete sich das Serverless-Konzept.
    • Es bot nutzungsbasierte Abrechnung und automatische Skalierung.
    • Wegen Cold Starts, Herausforderungen beim State Management und Grenzen beim Debugging war es jedoch keine Universallösung.
    • Cloudflare Workers erweiterten das Modell um Ausführung am Edge.
  • Auch im CSS-Bereich vollzog sich leise ein Wandel.
    • Nach Sass und Less sowie einer Phase von CSS-in-JS wurde Tailwind CSS (2017) breit angenommen.
    • Der auf Utility-Klassen basierende Ansatz
      • beseitigte den Aufwand für die Benennung von Klassen,
      • verringerte Probleme mit Cascade und Specificity
      • und führte letztlich zu kleineren Stylesheets.
  • GraphQL (2015) erhielt viel Aufmerksamkeit als starke Lösung für Anwendungen mit komplexen Datenstrukturen.
    • Es bot Vorteile wie präzise Datenabfragen, typbasierte Schemas und ein starkes Tooling-Ökosystem.
    • Durch die Komplexität der Server-Schicht und die Schwierigkeit beim Caching war es für einfaches CRUD jedoch oft überdimensioniert.
    • Manche Teams blieben deshalb bei REST oder entschieden sich für einfachere Alternativen wie tRPC.
  • Der Wettbewerb bei der Container-Orchestrierung endete um 2018 herum mit dem Sieg von Kubernetes.
    • Mächtig, aber mit hohen Lernkosten und operativer Komplexität.
    • Für viele Teams war es eine überzogene Lösung und damit auch ein Hintergrund für das Wiederaufleben von PaaS.
  • COVID (2020) ließ die Nachfrage nach Webentwicklung sprunghaft ansteigen.
    • Remote-Arbeit, E-Commerce und Kollaborationstools wurden unverzichtbar.
    • Das führte zu explodierender Nachfrage nach Entwickler:innen und zu rasantem Wachstum bei Unternehmen für Entwicklungstools.
  • In Remote-Umgebungen gewann asynchrone Zusammenarbeit und Dokumentation stark an Bedeutung.
    • Code Reviews, PR-Beschreibungen und die Qualität interner Dokumentation wurden zu Schlüsselfaktoren.
  • Auch auf Organisationsebene setzte Reife ein.
    • Etablierte Engineer-Level-Systeme
    • mehr Anerkennung für den IC-Track
    • klarere Trennung der Rollen von PM, EM und Tech Lead
  • Developer Experience (DX) wurde als eigenständiges Investitionsfeld wahrgenommen.
    • Interne Plattform-Teams, schnelle CI und besseres Onboarding wurden zu zentralen Produktivitätsfaktoren.
  • Um 2022 erreichte die Webentwicklung einen komplexen, aber beherrschbaren Zustand.
    • TypeScript als Standard-Default
    • ein um Next.js zentriertes Ökosystem
    • automatisiertes Deployment und ein ausgereiftes Tooling-System
  • Und dann änderte sich alles: Ein Unternehmen namens OpenAI veröffentlichte etwas namens ChatGPT.

Der Moment der AI

"Wait, I can just ask it to write the code?"

  • Mit dem Start von ChatGPT (2022) veränderten sich die Regeln der Entwicklung: Allein durch eine Frage erhielt man Erklärungen, Code und Debugging-Ergebnisse.
    • Von Erklärungen zur Quantenphysik bis zum Debugging von Python war vieles möglich, und der eigentliche Schock war, dass es zwar nicht perfekt, aber gut genug für den praktischen Einsatz war.
    • Entwickler:innen begannen sofort zu experimentieren, und das Schreiben von React-Komponenten, die Analyse von Fehlerursachen und die Umwandlung von Code zwischen Sprachen wurden innerhalb von Sekunden möglich, ohne Dokumentationen oder Foren durchsuchen zu müssen.
  • GitHub Copilot (2022) brachte Codegenerierung in Form von Autovervollständigung direkt in den Editor und verbreitete eine extrem leistungsfähige Autocomplete-Erfahrung, bei der schon Kommentare Implementierungen vorschlagen konnten.
    • Die neue Meta-Fähigkeit, AI-Vorschläge schnell zu bewerten, zu übernehmen, anzupassen oder abzulehnen, wurde zu einer Kernkompetenz von Entwickler:innen.
  • Wiederkehrende Boilerplate, das Schreiben von Tests und der Umgang mit Edge Cases wurden massiv beschleunigt, sodass Entwicklung ohne Unterbrechung des Flows möglich wurde.
  • Cursor (2023) integrierte AI nicht als Feature, sondern als Grundannahme in die IDE: Refactoring-Anfragen nach Codeauswahl, dateiübergreifende Änderungen auf Basis natürlicher Sprache und Gespräche mit der Codebase wurden möglich.
  • Dieser Wandel erschütterte die Bedeutung von Seniorität, tatsächlich wuchs aber vor allem die Bedeutung der Fähigkeit, zu entscheiden, was gebaut werden soll, und Anforderungen, Einschränkungen und Nebenwirkungen zu beurteilen.
    • AI kann Code schreiben, aber sie definiert das Problem nicht und wählt auch nicht die richtige Richtung.
  • Zwar gab es extreme Reaktionen zwischen dem „Ende des Programmierens“ und einem „nutzlosen Hype“, das tatsächliche Ergebnis war jedoch eine Produktivitätsverstärkung für Entwickler:innen, die AI nutzen.
  • Die Einstiegshürde für persönliche und Side Projects sank drastisch, sodass auch Bereiche, die man früher nicht versucht hätte, etwa ML, Games oder neue Frameworks, über dialogbasiertes Lernen zugänglich wurden.
  • Dieser Trend beschleunigte die lange Ausrichtung des Webs auf die Demokratisierung des Erschaffens.
    • Der Schwerpunkt verlagerte sich vom Wissen, wie man Code schreibt, hin zu dem Wissen, was man überhaupt bauen möchte.
  • Auch Nicht-Entwickler:innen beteiligten sich an der Erstellung von Prototypen, und PMs, Designer:innen sowie Domain-Expert:innen bauten direkt eigene Tools, wodurch die Grenze zwischen technisch und nicht technisch verschwamm.
  • Mit dem Anstieg von Indie Hackern und Solo Buildern wurde eine Umgebung real, in der man auch allein ein substanzielles Produkt entwickeln kann.
  • Gleichzeitig verstärkten React Server Components, htmx, verbesserte CSS- und JavaScript-Standards sowie Tools wie Bun den Trend, „lieber die Plattform selbst zu nutzen“.
  • Nach dem großen Einstellungsboom von 2022–2023 wurde der Markt durch Restrukturierungen erschüttert, doch AI ersetzte Entwickler:innen nicht, und die Fähigkeit, AI zu nutzen, wurde zur grundlegenden Erwartung.
  • Im Jahr 2025 befindet sich die Webentwicklung von der Idee bis zum Deployment in ihrem historisch schnellsten Zustand, und
    • in einer Umgebung, in der Cloud, Frameworks und AI zusammenwirken, ist der Einzelne mächtiger als je zuvor als kreativer Schöpfer.
  • Das Versprechen des Webs, das mit dem <br>-Tag begann – „Jede:r kann etwas bauen und teilen“ – setzt sich im AI-Zeitalter in noch stärkerer Form fort.
  • Jetzt ist wirklich eine großartige Zeit für Webentwicklung.

Verwandte Beiträge

Noch keine Kommentare.

Noch keine Kommentare.