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

 (artmann.co)
28 Punkte von GN⁺ 2025-12-17 | 7 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 -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 , und `` ü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 `` 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 -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 -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

7 Kommentare

 
ethanhur 2025-12-19

Ich habe es mit Vergnügen wie ein Geschichtsbuch gelesen.
 
zihado 2025-12-19

Damals, als man bei Cafe24 einfach ein Server-Hosting hatte, ZeroBoard hochlud und damit so etwas wie eine eigene Community aufbaute und seinen Spaß daran hatte, haha
 
lethee 2025-12-19

Ich habe den Artikel mit Vergnügen gelesen. Es fühlte sich an wie ein Lebensrückblick, der einem vor dem Tod durch den Kopf schießt, haha.
 
edunga1 2025-12-17

Hat Spaß gemacht zu lesen.
Wenn man zur Entwicklungsumgebung übergeht, kommen VS Code und LSP ins Spiel. Und dann lässt sich der Bogen sogar zu den Tools von vor dem KI-Zeitalter von Tabnine spannen.
 
aer0700 2025-12-17

https://de.news.hada.io/topic?id=21170
Es ist gut, das zusammen mit diesem Artikel zu lesen.
 
GN⁺ 2025-12-17
Hacker-News-Kommentare

  • Die Aussage, dass jede Seite denselben Header, dieselbe Navigation und denselben Footer brauchte, es aber keine Möglichkeit zum Teilen gab, stimmt nicht ganz. Webserver hatten Server Side Includes (SSI), und wenn man das nicht nutzen wollte, konnte man es auch einfach mit dem Befehl cat header body > file lösen. Relevante Dokumentation: NCSA SSI Tutorial (1997)

    • HTML wurde ursprünglich als SGML-basiertes Vokabular entwickelt, daher hatten SGML und XML Entity-/Textmakro-Funktionen, mit denen sich Dokumentfragmente wie gemeinsame Header oder Footer referenzieren ließen.
    • Vermutlich bezog sich der ursprüngliche Kommentar nur auf reines HTML.

  • Ich musste daran denken, dass es schön gewesen wäre, wenn der Artikel mit einem Satz wie „... und in all dem tut das bescheidene -Tag immer noch zuverlässig seinen Dienst“ geendet hätte.

  • In einer Firma, in der ich früher gearbeitet habe, nutzten wir bei Deployments ein System, das jedes Mal einen neuen Ordner anlegte und dann den symbolischen Link auf die neueste Version umstellte. Es war zwar manuell, aber ich empfand es als sehr elegante Lösung, weil auf jedem Server ein atomarer Wechsel möglich war und Rollbacks einfach waren. Zuvor mussten Dateien manuell auf Dutzende Server kopiert und 10 bis 20 Schritte von Hand ausgeführt werden; im Vergleich dazu war es deutlich sicherer und einfacher. Später habe ich Automatisierungstools ausprobiert, aber deren Konfiguration war so komplex und intransparent, dass der Deployment-Prozess am Ende eher noch anfälliger war.

  • Da steht, man habe für CGI-Skripte Perl oder C lernen müssen, aber ich frage mich, ob dafür wirklich Hunderte Zeilen nötig waren. In der Praxis kann man URL-Parameter auch mit einfachen C-Funktionen auslesen. Ich habe kürzlich sogar eine Umfrage-Website komplett in C gebaut, und dank einer HTML-Generierungsbibliothek, die ich früher geschrieben hatte, ging das ziemlich gut. Ich habe die CGI-Bibliothek des Betriebssystems refaktoriert, SQLite statisch gelinkt und alles als Single Binary ausgeliefert. Testen ließ sich das auch ohne Webserver über stdin/stdout. Mein Fazit ist: CRUD-Websites sind auch in C gut machbar, und weil HTML eine Baumstruktur hat, ist String Interpolation dafür der falsche Ansatz.

    • Der Code matcht den ersten Parameter, der auf `` endet, daher ist es möglicherweise keine exakte Übereinstimmung, und Percent-Encoding wird auch nicht verarbeitet.
    • Ich stimme der Aussage zu, dass String Interpolation ungeeignet ist, wenn HTML eine Baumstruktur ausdrückt. Trotzdem fühlt es sich so an, als wäre String Interpolation selbst nach 30 Jahren immer noch das gebräuchlichste Werkzeug.

  • Das war wirklich ein umfassender und gut geschriebener Artikel. Der Autor ist optimistisch, aber für mich wirkt Webentwicklung wie ein instabiler Turm aus aufeinandergestapelten Provisorien. Ich denke, die Webstandardisierung wurde von einigen wenigen Browser-Anbietern vereinnahmt, und statt Grundprobleme zu lösen, hat man nur immer neue Schichten darübergelegt. Auch die aktuellen generativen KI-Tools sind nur provisorische Lösungen, um diese Komplexität zu umschiffen. Am Ende wird dieser Turm irgendwann einstürzen.

  • Dieser Artikel wird vermutlich ein Klassiker werden. Er fasst die Geschichte der Webtechnologien, die heutige Entwickler oft verpasst haben, prägnant zusammen.

  • Beim Abschnitt „Virtual private servers changed this…“ fiel mir wieder ein: Tatsächlich war der erste VPS-Anbieter um 2001 wohl JohnCompanies, basierend auf FreeBSD jails. Die Kunden wollten Remote-Backups und bevorzugten rsync. Deshalb habe ich vier Jahre später die Domain rsync.net registriert (mit Erlaubnis der Autoren von rsync/samba).

  • Ich habe von 1998 bis 2012 Webentwicklung gemacht, und beim Lesen fühlte es sich wie eine Reise in die Vergangenheit an. Gleichzeitig ist es auch eine Zusammenfassung, mit der man die späteren Veränderungen auf einen Blick sehen kann.

  • Der Inhalt des Artikels stimmt fast vollständig mit dem Verlauf der Webtechnologien überein, an den ich mich erinnere. CGI vor PHP war zwar umständlich, aber dank mod_perl und FastCGI durchaus brauchbar. CGI in einer kompilierten Sprache zu schreiben, kam fast Masochismus gleich, und PHP war in dieser Hinsicht leichtgewichtig und machte Spaß. Ich habe mit Frontend-Entwicklung aufgehört, kurz bevor jQuery groß wurde.

  • Ein wirklich erstaunlicher Artikel. Er listet nicht einfach nur eine technische Chronik auf, sondern vermittelt den Zeitgeist jeder Epoche lebendig. Besonders beeindruckend fand ich, dass er den menschlichen Kontext festhält, der sonst meist nur mündlich weitergegeben wird. Statt nur zu kritisieren, warum die Cloud-Welt so komplex geworden ist, hilft er dabei, sie als historisches Ergebnis der Aufsummierung jeweils rationaler Entscheidungen zu verstehen. Man spürt die Ironie der Menschheitsgeschichte darin auch in der Technikgeschichte.
 
geekgig 2026-05-04

Da ich Web/Mobile nur aus der Ferne beobachtet habe
und mein Schwerpunkt im Leben vor allem auf PC-Apps (C++) lag,
ist das ein Artikel, der mir den gesamten historischen Wandel des Webs sehr gut erklärt.
Dadurch habe ich wohl ein wenig den Blick dafür gewonnen, die Inhalte, die ich nur bruchstückhaft kannte, miteinander zu verknüpfen.

Vielen Dank. ~~