Features von übermorgen: Natives MVC in HTML6?

Sollte HTML5 doch nicht das Ende der Fahnenstange gewesen sein? Auf der Mailing-Liste der entsprechenden Arbeitsgruppe macht man sich Gedanken um Features eines eventuellen Nachfolgers.

Eigentlich war man sich ja im Allgemeinen einig, dass mit HTML5 die finale Version des HTML-Standards erreicht wurde und es keinen größeren Versionssprung (auf 6) mehr geben würde. Stattdessen sollten inkrementelle Updates zu dem "Living Standard" hinzukommen. Nichtsdestotrotz machen sich unter Entwicklern bereits Gedanken um einen eventuellen Nachfolger in Form von HTML6 breit. So auch letzte Woche in einem Blog-Post in der Mailing-Liste der W3C Web Hypertext Application Technology Working Group (WHATWG).

Der Post stammt von Bobby Mozumder und er führt dort vor allem folgenden Kritikpunkte bei der Entwicklung von Single-Page-Anwendungen auf:

• Alle modernen JavaScript-Frontend-Frameworks wie AngularJS, EmberJS etc. arbeiten mehr oder weniger nach den gleichen Prinzipien, wenn es um Single-Page-Anwendungen geht. Konkret meint er damit das immer gleiche Vorgehen, dynamisch Inhalte per JSON-APIs zu laden (Stichwort AJAX) und Inhalte einer Webanwendung dynamisch per JavaScript auszutauschen.
• Im Detail und bezüglich der zur Verfügung gestellten Features unterscheiden sich die Frameworks dennoch sodass man - falls man ein Framework wie Backbone.js oder Facebook React einsetzt - für andere Features, die durch diese Frameworks nicht abgedeckt werden, weitere Frameworks und Bibliotheken einbinden muss. Dies führt in Summe zu unnötig viel eingebundenem Quelltext.
• Frameworks wie AngularJS und EmberJS lassen sich nicht von heute auf morgen erlernen, die Einarbeitungszeit für Entwickler ist dementsprechend hoch.

Kurz gesagt: Der Aufwand im Allgemeinen ist für Entwickler seiner Meinung nach zu hoch. Stattdessen schlägt er vor, das dynamische Nachladen von Inhalten nativ in HTML zu integrieren. Sein Ziel: vollständige Single-Page-Anwendungen ohne den Gebrauch von JavaScript erstellen zu können.

Der Vorschlag sieht unter anderem vor, über ein neues Tag (<model>) verschiedene Objektmodelle direkt innerhalb des HTML-Codes definieren zu können und diese über ein ebenfalls neues Attribut model in entsprechend andere Stellen innerhalb des DOMs einzubinden. Ein Objektmodell kann dabei direkt innerhalb des <model>-Elements definiert werden, es soll aber auch möglich sein, über Anker-Elemente (<a>) die Daten eines Model über einen API Endpoint nachzuladen. Das Format ist in allen Fällen JSON.

Im Hinblick auf das Entwurfsmuster Model View Controller (MVC) würde der HTML-Code demnach nicht nur die View enthalten, sondern auch das Model (innerhalb der unterschiedlichen <model>-Elemente) sowie die Controller-Komponente (die erwähnten Anker-Elemente).

Die Reaktionen auf diesen Vorschlag halten sich momentan noch in Grenzen, auf Twitter findet man aber schon einige unter dem Hashtag #html6. Und auch in der Mailing List selber gibt es Antworten, wie die von Brian Kardell (dem Chair der Extensible Web Community Group beim W3C), der gegen den Vorschlag argumentiert. Er sieht die Herausforderung insbesondere darin, eine geeignete Abstraktion zu finden, sodass dennoch alle beliebigen Anwendungsfälle umgesetzt werden können ("It's rarely as simple as it appears at first blush").

Auch wenn der Ansatz durchaus interessant ist, stellt sich also die Frage, ob es in der Praxis so einfach bleiben und das vorgeschlagene Konzept für alle Anwendungsfälle ausreichen würde. Am besten ließe sich so etwas eigentlich durch ein Polyfill nachweisen, also über eine Bibliothek, die die vorgeschlagene Funktionalität mit heutigen Mitteln emuliert und zur Verfügung stellt. Google hat das beispielsweise bereits mit Polymer für Web Components gemacht. Erst auf diese Weise, also im praktischen Einsatz, könnte sich zeigen, ob der beschriebene Ansatz überhaupt tragfähig wäre.

Übrigens: Den aktuellen Stand dieses Vorschlags können Sie über dieses git-Repository nachverfolgen. ()