Peter Kröner, Webtechnologie-Erklärbär

Durch groben Leichtsinn kam ich vor etwas mehr als 10 Jahren zu der Aufgabe, das erste deutschsprachige Buch zu HTML5 zu schreiben, dessen erste Auflage vor genau 10 Jahren erschien. Ein paar Exemplare der ersten Auflage lagern sogar noch im Schrank meiner Eltern, aber dort verbietet sich aufgrund von Corona zurzeit jedweder Besuch. Doch auch die mir vorliegende zweite Auflage von 2011 kann als Leitfaden durch HTML5 und vor allem die Erwartungen an HTML5 von damals mit denen von heute zu vergleichen. Hat HTML5 wie geplant die Welt erobert? Haben sich die im Buch beschriebenen Technologien durchgesetzt? Schauen wir uns doch mal an, wie sich die im Inhaltsverzeichnis geäußerten oder zumindest angedeuteten Versprechen mit Realität decken.

Das HTML von HTML5

Vernünftiges HTML hat sich derart durchgesetzt, dass kaum jemand mehr darüber spricht. Der eigentlich größte Verdienst von HTML5 war die Formalisierung des zuvor uneinheitlichen SGML-Dialekts, der sich durch Browser-Konkurrenzkampf gebildet hatte. Heutzutage sind sich (die wenigen) verbliebenen Browser-Engines über die Verarbeitung von HTML-Syntax vollkommen einig und es gibt zumindest hier keine mir bekannten Inkompatibilitäten mehr. Das ist eine große Leistung, für die sich aber niemand interessiert – HTML ist einfach Infrastruktur. Spannend ist aber, wie sehr Web Components mit HTML5 zu kämpfen haben. Custom Elements müssen so gestrickt sein, dass sie das Verhalten vorhandener HTML-Elemente und des HTML-Parsers erklären können, doch beides sind Schlangengruben voller Inkosistenzen. Diese haben sich ergeben, weil im Zuge der HTML5-Formalisierung zwischen allen inkompatiblen Browsern der kleinste gemeinsame Nenner gesucht wurde und dabei die Bedürfnisse von nutzerdefinierten Elementen keine Rolle spielte. Ob aus Web Components angesichts dieser und anderer Herausforderungen nochmal was wird?

Semantisches HTML5

Die semantischen Elemente scheinen sich im Alltags-HTML der meisten Frontendler festgesetzt zu haben und versehen die immer noch allgegenwärtigen Div-Suppen mit einer gewissen Würze. Insbesondere vor dem Hintergrund der eingebauten ARIA-Features ist das ein größerer Pluspunkt. Der Outline-Algorithmus hingegen (Gegenstand der letzten Folge von Working Draft) scheint genau so moribund wie HTML5-Microdata und alle andere Formen von Semantic-Web-Lüftschlössern. In einer Welt der Tech-Monopole finden semantische Informationen nur noch in Form des Frondienstes für den Monopol-Lord (vulgo SEO) eine ökologische Nische, sind aber weit von dem entfernt, was die diversen Vordenker (und HTML5-Buch-Autoren, die darüber viel zu viele Seiten geschrieben haben) des Semantic Web sich einst ausgemalt haben.

HTML5-Formulare

Formulare sind und bleiben ein kompliziertes Thema. An manchen Stellen finden HTML5-Neuerungen wie Date-Picker und Formular-Validierung Anwendung, doch die handgeschriebene Re-Implementierung solcher Standards ist noch sehr verbreitet. Das mag daran liegen, dass Formulare ein inhärent so ausufernd-facettenreiches Thema ist, dass kein Standard der Welt jeden Use Case bedienen kann. Und obwohl zumindest die Validierungs-API erweiterbar ist, ist sie das wohl nicht in ausreichendem Umfang. Ich würde von einem ganz klaren Teilerfolg sprechen, aus dem man die Lehre ziehen kann, dass das Extensible Web Manifesto schon den richtigeren Weg ausleuchtet, als ein Default-Datumspicker. Letzteres ist wohl eine Zu-High-Level-API, die sich nie als der Standard durchsetzen wird, denn was die Webentwickler wirklich brauchen, ist das Inputmode-Attribut, um damit eigene Formularelemente zu bauen.

Offline-Webapps

Während uns Local Storage bis zum heutigen Tag begleitet (und dank Cookie-Bannern und GDPR prominenter ist als je zuvor), müssen wir den Application Cache von HTML5 ist als kompletten Griff ins Klo betrachten. Zum Glück ist er bereits durch Progressive Web Apps zu 100% abgelöst und stellt kein Problem mehr dar. Die API des Application Cache ist/war extrem verwirrend und bei meinen HTML5-Workshops damals war nur die Drag&Drop-API von HTML5 noch schwerer zu vermitteln. Und da wir gerade beim Thema sind …

Drag & Drop

Dateien per Drag & Drop hochzuladen ist auf dem Desktop mittlerweile auch bei Web Apps gängige Praxis, was 2010 noch lange nicht der Fall war. Dieser Teil der API ist auch nicht besonders schlimm missraten, der für Drag-Operationen zwischen Webseiten sowie Webseiten und anderen Programmen umso mehr. Allerdings scheint das auch keinen Entwickler zu stören und Nutzer scheinen dieses Feature nicht zu vermissen. Ich denke, dass wir uns an dieser Stelle bei der Smartphone-Revolution bedanken dürfen. In erster Näherung sitzt kein Mensch mehr an Desktop-Computern und hantiert mit Mäusen herum, und die wenigen solchen Power-User sind offenbar damit zufrieden, Drag & Drop für ihren E-Mail-Anhang zu verwenden. Passt schon.

Video und Audio

Großes Trara um Flash-Killer und Video-Codecs, und hinterher hostet sowieso jeder seinen Content beim Plattform-Monopolisten du jour. Was kümmern die Details der Video-Player-Implementierung, wenn die tatsächliche Einbettung (sofern man sowas überhaupt noch macht) per Youtube-Iframe erfolgt? Das Web von heute ist wahrlich etwas ganz anderes als vor 10 Jahren und niemand hostet heutzutage mehr seine eigenen Videos. Podcasts werden noch individuell gehostet und per Audio-Element in Webseiten eingebunden, aber bis sich das auch erledigt hat, wird es nur eine Frage der Zeit sein.

Web Workers

Auch wenn einige wenige mit zunehmender Lautstärke für die Vorzüge von Web Workers agitieren, so haben sie sich nicht wirklich im Webentwicklungs-Alltag festgefressen. Ich schätze das liegt daran, dass der Tradeoff zwischen Einsatz und Ertrag nicht besonders attraktiv ist. Frontend-Entwickler müssen langsame, lang laufende Funktionen mühsam vom DOM und anderen Browser-APIs entkoppeln – und das setzt voraus, dass Frontend-Entwickler überhaupt mit solchen Funktionen befasst sind und nicht etwa ein wie auch immer geartetes Backend. Häufig scheint es das nicht zu geben.

Fazit und Ausblick

Was kann man über HTML5 10 Jahre später sagen und welche Lehren lassen sich ziehen? Ich würde es mal so zusammenfassen:

• HTML ist wie geplant eine vernünftig definierte und implementierte Auszeichnungssprache geworden. Auch ohne die Konsolidierung am Browser-Markt hätten/haben wir heute eine Situation, in der jeder Browser jedes HTML exakt gleich verarbeitet.
• Diverse Features wie Formulare und Offline-Support sind (zumindest in Teilen) an ihrer High-Level-Fehlkonzeption gescheitert. Low-Level-APIs sind das, was Webentwickler wollen, denn nur so können sie ihren Job machen und damit auch die Web-Plattform als ganzes relevant halten.
• Semantik und Drag & Drop sind Opfer des Zeitgeists, der sich nicht mehr für Open Web interessiert und viel mehr sein Smartphone als seinen großen Desktop-Rechner nutzt.

Als die dem Ganzen zugrundeliegenden Trends würde ich zum einen Marktkonsolidierung (bei Browsern wie Plattformen) und auf der anderen Seite des Webentwicklers berechtigte Vorliebe für Low-Level-APIs ausmachen. Wenn wir mal annehmen, das sich daran nichts weiter ändert, würde ich mich auf folgende Vorhersagen für 2030 einlassen:

• Web Assemby wird die Web-Welt auf dem Kopf stellen. Es ist schließlich die ultimative Low-Level-API, die das Web zu einer komplett technologieunabhängigen Content-Delivery-Plattform macht. Es fehlt vermutlich noch der eine oder andere Katalysator (eine CRUD-Webapp mit Rust zu schreiben erscheint mir nicht sonderlich sinnvoll), aber der wird sich schon noch einfinden. JavaScript wird noch als allgemeine Scriptsprache eingesetzt werden (ein bisschen wie Perl) und TypeScript wird einen Status wie CoffeeScript genießen.
• Progressive Web Apps werden es schwer haben. Sie sind weniger Zu-High-Level als der Application Cache, aber sehr auf die Mobile-Plattform der Gegenwart fokussiert. Sollte sich die Plattform von ihrem heutigen Ist-Zustand wegbewegen, wird es für Webstandards schwer, sich dem anzupassen – das cross-kompilierte Web-Assemby-Produkt könnte einen Wettbewerbsvorteil haben. Außerdem mag es daran liegen, das ich seit Beginn der Corona-Pandemie keinen ICE mehr von innen erleben musste, aber könnte es nicht vielleicht doch möglich sein, das Land in endlicher Zeit so weit mit Mobilfunkmasten zuzupflastern, dass kaum jemand mehr Offline-Webapps braucht? Wäre doch ein denkbares Post-Corona-Konjunkturprogramm, nur nicht für PWA-Entwickler.
• Unabhängiges Podcasting und damit das letzte Refugium von RSS-Feeds und Audio-Elementen ist dem Untergang durch Monopolisierung geweiht und wird in 10 Jahren keine Rolle mehr spielen. Bisher hat es noch kein Spotify o.Ä. geschafft, das Youtube für gesprochenes Audio zu werden, aber Risikokapitalgeber haben tiefe Taschen und scheinbar nichts Besseres vor.

Das mutet alles etwas apokalyptisch an, aber andererseits sind Vorhersagen nicht meine Stärke. Immerhin habe ich mal ein ganzes Buch über revolutionäre neue Web-Zukunftstechnologien geschrieben und es für sinnvoll erachtet, Seite um Seite über Microdata und Video-Codecs zu referieren. Vielleicht liege ich ja wieder komplett falsch! Wir lesen uns (spätestens) in 10 Jahren wieder und vergleichen.