Suche
Interview mit Bobby Mozumder

HTML6 im Gespräch: „Zu viele Leute hängen in ihrer JavaScript-Kuschelecke fest“

Moritz Hoffmann

© Shutterstock.com/Chimpinski
95278714

Das vor kurzem erschienene Proposal für HTML6 hat für einiges Aufsehen in der Szene gesorgt. Wir haben uns mit Bobby Mozumder, dem Verfasser des Proposals, zusammengesetzt und uns über die Zielsetzung für HTML6 und die Rolle von JavaScript im Web der Zukunft unterhalten.

Was würdest du Webentwicklern antworten, die meinen, dass HTML als Markup-Sprache entworfen wurde und das auch bleiben sollte?

Bobby Mozumder: Wenn man die strikte Definition von HTML als ausschließliches Markup für Textdokumente voraussetzt, dann hat sich HTML schon vor Jahrzehnten darüber hinaus entwickelt. HTML verfügt sowohl über viel verwendete interaktive bzw. non-text-Elemente wie <FORM>, <SCRIPT>, <CANVAS> oder <META>, als auch über Attribute wie DATA-*. Keines davon wird zur Textauszeichnung verwendet und keines davon existierte in der ersten Spezifikation von 1993.

Legt man aber einen weitergehenden Begriff von HTML zugrunde, einen Begriff, der auch die User Experience mit einschließt, dann reiht sich das neue Proposal in ein grundlegendes Benutzermodell ein: die Interaktion mit Hypertext. Dieses Proposal verbessert lediglich die im Modell vorgegebene User Experience, indem Seiten nun schneller laden können, ohne durch ein externes JavaScript-Framework laufen zu müssen. Tatsächlich durchbricht dieses JavaScript die Textauszeichnung.

Kommen wir zu deinen Beweggründe dafür, auf das beliebte dynamische JSON API Design Pattern zu bauen. Einige Kommentatoren beklagen, dass Sprach-Updates nicht von aktuellen Design-Trends bestimmt sein sollten.

Bobby Mozumder: Hier geht es um die Wiederherstellung der grundlegenden User Experience im Netz und nicht um die Übernahme des beliebten JSON API Design Patterns.

Es gibt immer noch ein grundsätzliches Problem mit der Benutzerfreundlichkeit im Netz. Dass man nämlich mit dem Klick auf einen Link den kompletten Reload der Seite veranlasst. Nach dem Klick folgt eine wenig elegante Verzögerung, weil der Server die gesamte Seite wiederherstellen und zurücksenden muss. Dieser Delay kann einen schlechten Eindruck von deiner Website vermitteln. Vergleiche das mal mit so etwas wie Instagram, einer genuinen App, die sich schnell, geschmeidig und sehr nutzerfreundlich anfühlt.

Um dieses Delays Herr zu werden, muss man ein JavaScript-Framework laden und dieses mit einem API-Server verbinden, um dann dynamisch neuen Inhalt zu laden.

Aber es gibt noch mehr Probleme mit diesem Ansatz. Die Frameworks sind nicht standardisiert, man muss also jedes Framework analysieren, eines davon aussuchen, und dann muss man dieses Framework lernen. Die Frameworks sind aber nicht einfach mit einer deklaratorischen Syntax zu bedienen, also muss man komplizierten JavaScript-Code einsetzen. Immerzu ändern sie sich, um Workarounds um die Beschränkungen von JavaScript aufzubauen. Und es dauert eine ganze Weile, bis sie vom JavaScript-Interpreter des Browsers geladen und kompiliert werden.

„Der Browser könnte all das für uns übernehmen“

Gemäß dem Proposal gibt es in HTML per Default eine Methode, um dynamisch Content nachzuladen – mittels modernen JSON- (oder XML-) APIs. Man muss das Markup nicht durchbrechen, kein großes externes JavaScript-Framework laden und speziellen Code für die Website schreiben. Der Browser könnte all das für uns übernehmen. Die dadurch gewonnene Zeit könnte man nutzen, um mehr spezifischen JavaScript-Code für die Website zu schreiben.

Was hältst du von dem Einwand, dass es schon vorher ähnliche, erfolglose Vorstöße in diese Richtung gegeben hat? Wie können wir mit Sicherheit sagen, dass dieser Ansatz mehr Erfolg haben wird?

Bobby Mozumder: Ich habe mir einige dieser Versuche angesehen, und es ist offensichtlich, warum sie gescheitert sind. Wahrscheinlich ist der größte Fehler, dass viele unter ihnen auf XML aufgebaut waren, das nicht gerade von einer größeren Webentwickler-Community genutzt wird. Einige, wie XSLT, hatten kein persistentes Objekt-Modell. Das waren größtenteils Layer für die Veränderung der Ansicht. Wenn man also etwas, auch nur ein bisschen Anspruchsvolleres als Zählen machen wollte, konnte man das nicht. Andere Proposals (MDV) erforderten noch immer JavaScript anstelle einer deklarativen Syntax.

Mit meinem Vorschlag ziele ich auf Feedback von der Community da draußen ab, und die Reaktion war bislang positiv. Ich habe versucht, es so einfach wie möglich zu halten. Ein Datenmodell kann mit

<MODEL class="myArticleData">

ausgezeichnet werden. Die Anker-Elemente würden benutzt, um Modelle mit Daten aus den API-Endpunkten zu füllen, wenn die Nutzer Links anklicken:

http://api.mywebsite.com/get-article" receiver="myArticleData">

Und dann, wenn die neuen Daten geladen sind, erhält das Dokument durch die Modellreferenzen ein dynamisches Update:

<ARTICLE model="myArticleData">
Mit diesem Proposal wird HTML zu einer Template-Sprache, und eben die kennt jeder, der schon einmal ein CMS oder ein JavaScript-Framework benutzt hat.
Vielleicht befürchten einige Leute, dass altbekannte Entwicklungsprozesse durch neue Innovationen unterbrochen werden. Wie viel Anpassungs-Arbeit würde deiner Meinung nach für Webentwickler anfallen, wenn HTML sich in diese Richtung entwickelt?
Bobby Mozumder: Man hat ja immer noch die Option, JavaScript zu nutzen, wenn man das möchte. Zum Beispiel, wenn man „myArticleDate“ in einem anderen Format umwandeln muss. JavaScript wird da sein, wann immer man es benötigt, und hoffentlich wird die endgültige Spezifikation ein großes Modell-API für weitere JavaScript-Funktionalitäten mit einschließen.

„…weil sie damit vertraut sind, oder wegen des soliden Designs?“

Entscheidend ist aber, dass Entwickler sich auch ansehen müssen, was sie tun. Dann erkennen sie, ob sie an etwas hängen, weil sie damit vertraut sind, oder wegen des soliden Designs. Natürlich freut sich ein Angular-Entwickler an Angular, aber Entwickler müssen sich Gedanken darüber machen, ob sie vielleicht einfach nur in ihrer Kuschelecke verharren wollen. Würde ein neuer User, wie z.B. ein Tumblr- oder WordPress-Blogger, das Proposal nicht praktischer finden als JavaScript und ein Framework zu lernen? Es gibt über 200 Millionen Tumblr-Blogs und über 75 Millionen WordPress-Seiten. Was soll den Usern dieser Seiten eine bessere Performance ermöglichen? Sollen die alle JavaScript und Angular lernen, nur um die User Experience ihrer Webseiten zu verbessern? Vielleicht haben sie andere Dinge, um die sie sich kümmern müssen.

Sollte nicht die herkömmliche Nutzerbedienung im Internet die beste User Experience bieten, in der man auch großartige Erfahrungen machen kann, ohne ein umfassendes JavaScript-Framework zu lernen und zu programmieren? Ich habe tausende Zeilen JavaScript geschrieben, aber ich habe einfach kein Bedürfnis danach, mehr JavaScript zu schreiben als nötig. Ich kann mir nicht vorstellen, wie ein neuer Nutzer reagieren würde, wahrscheinlich ist das der Grund dafür, dass eine breite Mehrheit von Websites eben nicht bis auf diese Ebene hin optimiert werden.

Die Projekte, an denen man arbeitet, sollten genutzt werden, um das eigene Produkt voranzubringen und nicht um grundsätzliche Mängel des Internets zu beheben. Wenn man sich so etwas wie Instagramm oder andere native Apps ansieht, dann übernehmen die auf eine ganz hervorragende Art und Weise Verantwortung für eine phantastische User Experience. Warum sind Websites nicht schon in der Grundeinstellung genau so?

Für welche Änderungen im Proposal wird sich das W3C besonders interessieren?

Bobby Mozumder: Auf den W3C-Mailing-Listen reden die Leute darüber, aber nichts läuft einfach von selbst. Das wird ein langer, schwieriger Prozess, in dem jeder (nicht nur ich) permanent auch mal Dinge durchdrücken muss, damit sie möglich werden – vielleicht über Jahre hinweg. Ich hoffe, dass sich andere Webentwickler auf den W3C-Mailing-Listen mit einbringen (public-html, whatwg) und dass sie ebenso im Sinne einer Implementierung Einfluss auf die Browser-Anbieter ausüben.

„Das wird ein langer, schwieriger Prozess“

Es gibt eine Menge von „Alles mit JavaScript!“-Vertreter auf den Mailing-Listen, die ganz eindeutig in ihrer Kuschelecke festhängen. Denen sollten die Leute E-Mails schreiben oder mit ihnen reden, um sie davon zu überzeugen, dass sich auch HTML weiterentwickeln sollte. Ich werde das alles nicht alleine machen können, das ist unmöglich. Und dann müssen wir immer noch eine umfassende Spezifikation definieren und anschließend die Browser-Anbieter von der Implementierung zu überzeugen.

Für die, die am Prozess mitwirken oder ihn einfach nur begleiten wollen, habe ich die neueste Version des Proposals auf https://github.com/mozumder/HTML6 zur Verfügung gestellt (über den „Issues“-Tab kann man das Proposal en détail diskutieren und, falls man das möchte, Tickets öffnen).

Auf jeden Fall aber sollten alle Druck auf die W3C und die Browser-Anbieter ausüben, um ein Projekt wie dieses möglich zu machen!

Aufmacherbild: html code von Shutterstock.com / Urheberrecht: Chimpinski
Das Interview führte Coman Hamilton
(jaxenter.com)
Übersetzung: Moritz Hoffmann

Mozumder_Bobby

Bobby Mozumder:
Bobby Mozumder ist Gründer und Herausgeber des FutureClaw Magazine, einem Fashion- und Medienunternehmen. Zuvor war er als Technischer Berater tätig.

Geschrieben von
Moritz Hoffmann
Moritz Hoffmann
Moritz Hoffmann hat an der Goethe Universität Soziologie sowie Buch- und Medienpraxis studiert. Er lebt seit acht Jahren in Frankfurt am Main und arbeitet in der Redaktion von Software und Support Media.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.