Das WTF zum Wochende

[Auge]

Hallo

Das Beste, was dieser Artikel hervorgebracht hat, ist der Kommentar von Jens Grochtdreis. Auch lesbar in seinem Blog.

Vermutlich hat er zum Großteil recht, aber andererseits geht er mit einer Muss-überall-laufen-Ansicht an die Sache ran, der RISC-HTML-Erfinder hat jedoch nur eine Lösung für einen begrenzten Nutzerkreis im Blick gehabt.

In diese Richtung habe ich nach den ersten zwei Absätzen auch gedacht. Im Firmenumfeld mit seinen vorgeschriebenen Programmen ist die Verwendung von Bleeding-Edge-Techniken nicht unbedingt empfehlenswert. Das gilt natürlich auch für Webanwendungen.

Und soweit ich las, war der Ansatz von RISC-HTML auch nicht die Rettung der gesamten Menschheit, sondern "Benutzeroberflächen für Geschäfts- und Industrieanwendungen", also eine mehr oder weniger private Angelegenheit.

Eben.

Ob RISC-HTML für den vorgesehenen Einsatzzweck tauglich ist oder nicht, kann und mag ich nicht beurteilen.

Naja, abseits der Tauglichkeit, die für die Einsatzzwecke gegeben sein mag, ergeben sich doch ein paar Ungereimtheiten.

Inkompatibilitäten vermeiden zu wollen, wo keine sind, ist Schwachsinn. Das Argument, die Kastrierung des HTML-Sprachumfangs auf zwei Elemente (<div> und <input>) sei wegen der herbeigesponnenen Browserinkompatibilitäten nötig, ist angesichts der Tatsache, dass selbst mittlerweile zu Recht ausgestorbene Browsergenerationen wesentlich mehr als diese zwei Elemente problemlos verstehen, ein unverständliches Scheinargument.

Zumal der propagierte Vorteil, die UI mit JavaScript zu erstellen, völlig am Thema vorbeigeht. Auch dort fällt nur HTML (und CSS) raus. Dass die Software des Autors die Funktionen der nicht verwendeten HTML-Elemente mit JavaScript neu implementieren muss, weil selbst „ungefährliche“ HTML-Elemente nicht verwendet werden können, ist mMn geradezu ein Treppenwitz. Vollends albern wird es bei der Überlegung, dass das eine oder andere Zielsystem mit Teilen des zu verwendenden JavaScript-Codes nicht zurecht kommt, obwohl die damit simulierten HTML-Elemente zuverlässig funktionieren würden.

Sich bei solchen Anwendungen auf Elemente und Funktionen zu beschränken, von denen man weiß, dass sie auf der Zielplattform zuverlässig funktionieren, ist mMn sinnvoll. Sich aber unnötigerweise auf fast nichts zu beschränken und alles Andere, das man wegelassen hat, nachzubauen, ist einfach nur grober Unfug.

Tschö, Auge