Meine Reise durch die Evolution der Webentwicklung

------------- bis hierhin kaum automatisiertes Deployment möglich (z. B. über FTP)

------------- Versionierung

------------- automatisierte und idempotente Deployments möglich

Mehr Details und ausführlichere Infos gibt es unter anderem auf:

Wenn ich mich an die Anfänge meiner Tätigkeit erinnere, haben wir HTML, CSS, PHP und jQuery mit BBedit selbst geschrieben, gespeichert und manuell per FTP auf Server hochgeladen. Das Beste, was es damals gab, war das Programm Transmit, mit dem einzelne Ordner synchronisiert werden konnten. Alles war sehr fehleranfällig, ohne Versionierung und daher schwer bis gar nicht testbar – nur manuell. jQuery-Plugins wurden mit Abhängigkeiten zu unterschiedlichen jQuery-Versionen benutzt, die nicht unbedingt kompatibel waren. Man musste jedes Mal hoffen, dass die Webseite noch funktionierte, nachdem man Code hinzugefügt hatte. Was mich immer am meisten geärgert hat, war ein Flackern, sobald das JavaScript geladen wurde und über das PHP-gerenderte HTML noch extra DOM-Elemente legte.

Die folgenden Probleme sind meiner Meinung nach die größten beim klassisch gerenderten Web:

Nach meinem Studium habe ich in Hamburg bei AboutYou in einer IT-Agentur gearbeitet, die nach Scrum ihren Arbeitszyklus gestaltet und schon damals diverse Tools zum Bauen des Frontends benutzt hat. Da die Tools alle am Anfang ihres Lebenszyklus waren, mussten mindestens drei Package-Manager und Erweiterungen installiert werden, bevor die Webseite gebaut werden konnte. Gebaut? Ja, das war die Zeit, in der Grunt und Webpack eine moderne und strukturierte Frontendentwicklung ermöglicht haben. Vorbei waren die Zeiten mit unterschiedlichen Encodings und Zeilenumbrüchen. Was für ein Gefühl es war, lokal einen Befehl in der Kommandozeile aufzurufen und die zu entwickelnde Webseite auf dem eigenen Gerät zu sehen – heute Standard. Hier lernte ich zum ersten Mal Package-Manager und Versionierung kennen. Und noch ein Thema kam auf: IDEs für Webentwicklung. Bisher war der beste Freund der Inspektor im Browser, eine lokale, beim Entwickler stattfindende Überprüfung oder Unterstützung konnten bis dahin nur die „richtigen“ Programmiersprachen und die dazugehörigen teuren IDEs (z. B. IntelliJ) bieten. Mit Atom gab es eine IDE, die schnell startete, sich nur um Websprachen kümmerte und über Plugins erweiterbar war. Jetzt gab es Autovervollständigung für HTML/JS/CSS und über Webpack konnten alle Dateien optimiert, komprimiert und kombiniert werden.

Sehr gut! Viele Probleme der Vergangenheit sind verschwunden (Internet Explorer existiert nicht mehr, schlechte Kompatibilität der Browser) und es gibt eine Reihe von Möglichkeiten, Frontends mit Frameworks zu bauen, die alle ihre Vor- und kleinen Nachteile haben. Z. B. hat sich Visual Studio Code zum kostenlosen Nachfolger von Atom für die Webentwicklung mit noch mehr Möglichkeiten zur generellen Verbesserung gemausert. Frontend-Frameworks gibt es viele (und es kommen immer mehr dazu) – durchgesetzt haben sich aktuell React, Angular, Vue.js und Svelte.

Schauen wir uns hierzu den Ablauf einer klassischen Webseite an: Ein Endgerät ruft die URL unserer Seite auf. Der Server antwortet je nach Session/Cookie/Authentication mit einer Login-Seite oder dem gerendertem HTML eines PHP-Skripts. Evtl. wurde der Client auf eine andere URL umgeleitet. Das HTML wird vom Browser interpretiert und JS/CSS/Bilder werden nachgeladen. Das CSS sorgt für das Styling der Seite. Das ausgelieferte JavaScript wird interpretiert, verändert das DOM und lädt neue Daten nach, und das wiederholt sich, wie hier beschrieben. Alle Schritte benötigen Zeit und führen zu einer mehrsekündigen Wartezeit, bis die Webseite benutzt werden kann.

Der Client fragt den Server an und erhält HTML, JS und CSS sowie den Login-Status vom Backend, und zwar so aufbereitet, dass der Browser es direkt darstellen kann, ohne weitere Schleifen zu drehen. Weitere Inhalte werden z. B. als JSON nachgeladen und im Browser mit JavaScript gerendert. Zusätzlich gibt es für alle JS-Frameworks Bundler, die beim Bauen der auszuliefernden Dateien diese optimal aufbereiten, sodass der User innerhalb kürzester Zeit mit dem Frontend interagieren kann.

Mein Lieblings-Javascript-Framework ist React. Eine gute Übersicht über andere JS-Frameworks und was sie unterscheidet, findet ihr z. B. auf themer.dev. Von dieser Seite kommt folgendes Zitat: „Reacts change detection paradigm is straightforward: the application state is maintained inside the framework (with APIs exposed to the developer for updating it) so that React knows when to re-render.“ Und was heißt das jetzt? Nicht mehr der Browser oder das Backend entscheiden, auf welcher URL was passiert, sondern das Frontend. Und wenn im Frontend eine Aktion ausgelöst wird, entscheidet auch das Frontend, was passiert. Das heißt nicht, dass es kein Backend gibt oder dass z. B. Validierung nur auf der Frontendseite passiert. Sicherheit im Web sollte der wichtigste Aspekt sein.

Was sich für mich als Erfolgsrezept herausgestellt hat: Sich am Anfang eines Neu- oder Umbaus einer Seite viel Zeit nehmen, um passende Libraries/Frameworks zu finden, die einem das Leben erleichtern und diese zu benutzen (UI Components, Accessibility, Icons, etc.). Am besten auf bekannte Frameworks setzen, die regelmäßig aktualisiert/gewartet werden.

Das war die Reise durch 20 Jahre Webentwicklung – ich bin sehr gespannt, was in 20 Jahren im Web alles möglich ist.