Verkrüppeltes HTML

Über Twitter wurde ich heute auf einen Artikel bei Jaxenter aufmerksam. Björn Müller beschreibt darin einen Ansatz, um die Komplexität aus dem Fronend für Geschäftsanwendungen zu nehmen: RISC-HTML. Ich finde, es ist kein HTML mehr, eher ein sehr stark verkrüppeltes. Der Artikel ist nicht besonders lang und bleibt an der Oberfläche. Ich ging hingegen beim Lesen innerlich in die Luft. Deshalb konnte ich nicht anders, als einen ausführlichen Kommentar zu hinterlassen. Da ich mir dafür einiges an Zeit genommen habe, veröffentliche ich den Kommentar auch hier bei mir:

Der Artikel und der darin beschriebene Ansatz ist in vielerlei Hinsicht falsch. Und es ist bedauerlich, dass es im Jahr 2016 noch immer Entwickler gibt, die solche Thesen in den Raum stellen.

Grundproblem scheint mir zu sein, dass ein Backend und Frontend vermixt werden, die gleichen Anforderungen an die beiden Ebenen gestellt werden. Das ist fahrlässig. Backendentwickler scheitern deshalb immer wieder im Frontend, weil ihnen die Klarheit und Verlässlichkeit ihrer Welt fehlt. Wir haben im Frontend nicht den einen Endgegener, gegen den entwickelt wird. Ein Backendentwickler weiss, dass auf seinem Server Java 6 oder PHPn6 läuft und kennt den Sprachumfang, der er zu 100% ausnutzen kann. Es ist dabei gewährleistet, dass die Runtime diesen Code auch immer brav und korrekt interpretiert.

Im Frontend gibt es diesen paradiesischen Zustand nicht. Es wird ihn auch nie geben. Wir wissen nicht, wer mit welchem Browser unsere Seiten besucht. Der Besucher hat meist die Kontrolle über den Browser (ausser bei iOS), kann die Fenstergröße verändern, Schriftarten installieren und deinstallieren usw.
Und noch viel wichtiger: es gibt keinen Browser, der HTML, CSS oder JavaScript zu 100% verstünde. Jeder Browser hat zudem andere Fehler. Es gibt ausserdem viele Teile der Spezifikationen, die der Interpretation freien Raum lassen. Frontend und Backend unterscheiden sich also grundlegend in allen Belangen voneinander. Deshalb ist es auch selten eine gute Idee, wenn ein Entwickler in beiden Sphären intensiv arbeitet.

Eine viel schlechtere Idee ist es, wenn ein Backendentwickler versucht, das Frontend neu zu erfinden. Dann soll programmiert werden, wo nichts programmiert wird und da werden Sicherheiten gewünscht, die es nicht gibt. Genau in diese Kategorie scheint mir RISC-HTML zu fallen. Der Sprachschatz von HTML wird dabei auf DIV und INPUT reduziert. Keine Semantik mehr. Das soll die Arbeit vereinfachen und das Ergebnis sichern.

Nun, ich hoffe, die Kunden dieser Firma haben niemals eine Behinderung, bei der sie auf Hilfsmittel angewiesen sind. Sie werden sich nicht zurechtfinden. Der Ansatz hat also schonmal eine Diskriminierung von Blinden eingebaut.

Die Behauptung, die Firma habe eine neue Webtechnologie entwickelt, ist selbst in Sachen PR eine extrem dreiste Nummer. Es wurde nichts entwickelt, sondern zurückgebaut. Ein stolzes Gebäude wurde auf die Grundmauern runtergebrannt und diese noch auseinandergetreten.

Dabei wird gerne vergessen, dass Frontendentwicklung in einem ersten und zweiten Schritt nichts mit Programmierung zu tun hat. Es handelt sich erst einmal um schlichtes Handwerk. Es geht darum, Inhalte so zu verpacken, dass die Verpackungen den Sinn des Inhalts wiedergeben. Also markiert man Absätze mit den dazu passenden Tags, genauso wie ein Videoelement oder eine Liste. Dann malt man das ganze hübsch an (Design) und arrangiert es auf einer Webseite (Layout). Dafür nutzt man dann CSS, das wiederum nichts mit Programmierung zu tun hat.

Erst wenn man Inhalte live aktualisieren will oder etwas auf- und zuklappen will, benötigt man JavaScript. Erst dann kommen wir in den Bereich der Programmierung. Die beiden vorherigen Schichten lassen sich zudem nicht durch JavaScript ersetzen, wie uns der Autor offenbar weiss machen will. HTML muss entweder geschrieben oder nachgebildet werden. CSS muss mit JS geschrieben werden. Wo ist da der Nutzen?

In einem Kurs zu Angular JS und zwei anderen Frameworks habe ich der Entstehung einer Platzreseervierungs-Applikation beigewohnt. Am Ende kam ich zu dem Schluss – und konnte ihn mit einer Testseite beweisen -, dass für diese „Applikation“ keine Zeile JS erforderlich war. Anstatt DIVs zu verschachteln und mühsam zu klickbaren Objekten zu wandeln, nahm ich ein Formular und Checkboxen sowie deren Label. Checkboxen bringen kostenlos Zustände mit sich, die wir über CSS auslesen und visualisieren können und die automatisch alle wichtige Infos an das Formular übergeben. Aus der Sicht eines Programmierers mag dieser Ansatz langweilig sein, er ist aber der einzig vernünftige.

Auch das hier vorgestellte RISC-HTML würde diesen falschen Weg gehen. Anstatt einfach die mit HTML schon mitkommenden Controls und Sprachelemente zu nutzen, werden neue Konstrukte erstellt. Tausende Zeilen sinnlosen JS-Codes, die die endgültige Anwendung schön langsam werden lassen. Und es gibt kein Fallback für den Fall, dass das JS nicht komplett geladen wurde. Last but not least bedeutet diese Bibliothek einen Haufen Arbeit, den niemand bezahlen sollte. Denn es werden Elemente nachgebaut, die schon existieren.

Für eine Beispielapplikation unterstellt der Autor einen Lebenszyklus von 10 Jahren und mehr. Kritisch scheint ihm hier das Frontend zu sein. Es ist aber doch eigentlich nur die Darstellung der Aufbereitung, die auf dem Server passiert. Richtig entwickelt, habe ich eine Trennung von Geschäftslogik und Struktur. Die optische Aufbereitung kommt mit CSS sowieso separat. Dieser Ansatz der Trennung ist weder neu noch revolutionär. Deshalb kann ich darin keinen Grund dafür entdecken, HTML auf zwei Elemente einzudampfen und unnötig kompliziertes JS zu schreiben.

Ein Verkaufsargument scheint die Abwesenheit von Tests zu sein. Mich würde interessieren, ob der Autor auch auf Tests in seinen Java-Codes verzichtet und dies gegenüber seinen Kunden anpreist.

Der hier gezeigte Screenshot weist für mich auch nicht auf die Notwendigkeit der Verkrüppelung der Frontendtechniken hin. Das Design ist nicht besonders herausfordernd, nichts, was man nicht schon tausendfach gesehen hätte. Eventuell gibt es auch schon ein Fertigtemplate irgendwo, das man ein weing anpassen kann. Wenn man sich mit Frontendtechniken auskennt.

Und auch wenn „die Logik des Anordnens nicht mehr im HTML liegt, sondern in betreffenden JavaScript Controls“, wird am Ende immer HTML geschrieben. In diesem Falle halt ein wenig umständlich mit JS, anstatt einfach HTML direkt zu schreiben. Und natürlich kann man Oberflächen sortierbar und arrangierbar machen. Alles schon gesehen. Aber es gibt keine Notwendigkeit, deshalb alles in JS zu schreiben.

Der Autor schreibt auch, dass bestimmte Layoutansätze über HTML nur ungefriedigend gelöst werden können. Das untestütze ich zu 100%. Denn HTML macht da gar nichts. HTML sieht nicht aus, es gibt nur einem Datenstrom Sinn. Der Autor meint CSS. Doch wie es der Zufall will: auch mit JS muss man am Ende CSS schreiben. Es kann sein, dass man nur mit JS noch ein paar Zusatzbedingungen einfügen kann, die man mit CSS nicht managen könnte. Aber für die Gestaltung ist am Ende immer CSS zuständig. Auch wenn der ganze Kram in Typescript oder Babel oder sonstwas geschrieben wird.

Offenbar werde ich auch in Zukunft noch viele Möglichkeiten haben, Programmierern die Eigenarten, Schönheiten und Abgründe des Frontends zu erklären. Denn auch im Jahr 2016 hat sich noch nicht überall die Erkenntnis durchgesetzt, dass das Frontend eine eigene Disziplin ist, die mit den Augen eines Backendentwicklers falsch aussieht. Das liegt aber nicht an den Frontendtechniken.

5 Kommentare

  1. Sehr schöner Kommentar. Vor allem „Ein stolzes Gebäude wurde auf die Grundmauern runtergebrannt und diese noch auseinandergetreten.“ in Bezug auf HTML ließ mich schmunzeln. Welche neue Farbe aber die „beiden vorherigen Schichten“ bekommen sollen, erschließt sich mir nicht. Im Ernst: weismachen kommt von wissen oder weise, also nur mit einem s 😉 und wird zudem zusammengeschrieben. Wir könnten das auch zusammmen zusammenschreiben 😉

    Inhaltlich habe ich nichts hinzufügen. Außer vielleicht ein deutliches „Finger wech!“

    • Das Problem ist ja, dass ich mit Leuten wie Dir in diesen Fragen immer einer Meinung bin. Aber unwissende Kunden und sich selbst überschätzende Softwareentwickler kommen regelmässig auf die abartigsten Ideen. Die erreiche ich mit meinem Blog nicht. Und ich kann ja nicht auf allen Seiten dieser Welt rumstreifen und kommentieren. Ein solcher Text dauert ja auch. Ich denke immer, wir haben 2016 und fange dann leise an zu weinen. Vielleicht sollte ich mal ein total tolles Java-Framework entwickeln und ähnlich anpreisen? Ich kann NULL Java!

  2. Leider scheint es derzeit eine Mode für solchen Müll zu geben… 🙁