Was herauskommt, wenn man den Browser mal ganz anders benutzt!

RISC-HTML: Web Frontends für Geschäfts- und Industrieanwendungen

Björn Müller

(c) Shuttertsock / Profit_Image

Es muss nicht immer der ganze Blumenstrauß an HTML5-Features sein. Gerade für Geschäftsanwendungen sind Dinge wie geringer Wartungsaufwand, Browser/Device-Kompatibilität, Update-Stabilität oft wichtiger als die Nutzung der brandneuesten UI-Spielerei. Björn Müller, W-JAX-Speaker und Geschäftsführer von CaptainCasa, stellt in diesem Artikel einen Ansatz vor, mit dem sich auch in der schnelllebigen Welt der Web-Entwicklung robuste Geschäftsanwendungen fürs Web realisieren lassen, die nicht bei jedem JavaScript-Framework-Update umgebaut werden müssen.

Take the „RISC“

Benutzeroberflächen für Geschäfts- und Industrieanwendungen haben einen wichtigen Anspruch: Sie sollen langfristig stabil laufen! Der Lebenszyklus solcher Anwendungen beträgt gerne 10 Jahre und mehr – und die Lust, hier Kernteile des Frontends alle drei bis vier Jahr neu zu entwickeln und sie permanent an wechselnde Browser bzw. wechselnde Frameworks anzupassen, ist gering.

Die CaptainCasa, ursprünglich zuhause im Bereich von Java-basierten Frontends, hat hier unter dem Namen “RISC-HTML” eine neue Web-Technologie entwickelt, die auf genau diese Belange von Unternehmens- und Industrieanwendungen eingeht.

Der Name “RISC” ist dabei Programm – und eine Analogie zur Prozessor-Diskussion der 90er Jahre (“reduced instruction set computer”). Das HTML des Browsers wird nämlich nicht in seiner vollen Bandbreite genutzt, sondern im Gegenteil: Die Nutzung beschränkt sich auf zwei Primitiv-Elemente (DIV und INPUT), die noch dazu auf allereinfachste Art und Weise angesprochen werden.

iamge1

RISC-HTML – Prinzip

Der Zugriff auf diese Primitiv-Elemente wird durch eine JavaScript-Schnittstelle (“Microkernel”) abgeriegelt. Auf Basis dieses Microkernels wurden nun die gewohnten “normalen” Controls – vom Button über das Grid über Layout Container bis hin zu Dialogen – als JavaScript-Bibliothek erstellt.

image2

Client-seitige Architketur

Vorteile der RISC-HTML-Methode

Diese Herangehensweise ist eine signifikant andere als die innerhalb gewohnter Frameworks angewendete: Versuchen diese, die Komplexität des Browsers handhabbar zu machen und dabei Kompatibilitätsprobleme innerhalb der zahlreichen HTML-Elemente durch eine darüber liegende Schicht auszumerzen, so wird bei “RISC-HTML” das HTML des Browsers nur zu einem Bruchteil genutzt. Der Browser wird zu einer “Rendering Execution Engine” und malt betreffende Primitiv-Elemente an die vorgesehene Stelle. Warum und wie sie dorthin kommen, das bestimmen die betreffende Control-Implementierungen.

 

Naheliegendes Resultat der RISC-HTML-Methode: zunächst eine Browser/Device-Kompatibilität, die nicht auf “testen, testen, testen” (compatiblilty by resources) beruht sondern konstruktiv bedingt ist (compatiblilty by design). Die Abhängigkeit zum Browser ist in einer minimalen „Microkernel-Implementierung“ enthalten – noch dazu werden vom Browser nur allereinfachste Dinge erwartet: das Zeichnen absolut positionierter DIV- und INPUT-Elemente.

image3

(Online) Demo Workplace

Dadurch, dass die Logik des Anordnens nicht mehr im HTML liegt, sondern in betreffenden JavaScript Controls, entfallen auch die Limitierungen, die man vom Browser in diesem Bereich kennt. Einfache Herausforderungen (z.B. vertikale Bereiche, die fix sind und vertikale Bereiche, die variabel gesized werden – und dies über mehrere Schachtelungsebenen), die über normales HTML nur unbefriedigend gelöst werden können, sind deswegen im RISC-HTML-Ansatz problemlos umzusetzen.

Am Überraschendsten aber ist die Performance des RISC-HTML-Ansatzes. Urheblich dafür sind zwei Dinge: Zum einen führt der Browser das simple Rendering “wahnsinnig” schnell aus. Zum anderen ist die Abarbeitungsgeschwindigkeit von JavaScript mittlerweile extrem hoch.

Der RISC-HTML-Ansatz ist überall dort geeignet, wo Frontends eher programmiert als designed werden. Typisches Einsatzgebiet ist die Entwicklung der operativ genutzten Dialoge einer Geschäfts- / Industrieanwendung (z.B. Sachbearbeiterdialoge).

Die CaptainCasa hat den Client ihres Rich Client Frameworks “Enterprise Client” mittlerweile komplett auf RISC-HTML umgestellt. Downloads, Online-Demos und weitere Informationen gibt es über http://www.CaptainCasa.com.

Verwandte Themen:

Geschrieben von
Björn Müller
Björn Müller
Björn Müller ist seit 2001 im Bereich von UI-Frontend-Architekturen aktiv – sowohl auf der HTML-/Ajax-Seite als auch auf der Java-Swing- und JavaFX-Seite. Seit 2007 entwickelt er aktiv innerhalb der CaptainCasa-Community ein Java-basiertes Rich-Client-Framework für umfangreiche Geschäftsanwendugen, den CaptainCasa-Enterprise-Client. Wurde bis 2016 clientseitig auf Java-basierte Technologien gesetzt, so erfolgte nun der geräuschlose Umstieg auf einen HTML5-basierten Client, basierend auf der sog. „RISC-Methode“.
Kommentare

Hinterlasse einen Kommentar

10 Kommentare auf "RISC-HTML: Web Frontends für Geschäfts- und Industrieanwendungen"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Frank
Gast

Die ganze Architektur erinnert ein wenig an JSF. Es ist sicherlich nicht schlecht und einfach zu nutzen.

Wer Oberflächen mehr programmieren als designen will, sollte vielleich dann auf Rich Client Frameworks wie Vaadin oder direkt auf GWT zurückgreifen.

Vaadien: https://vaadin.com/home

Jens Grochtdreis
Gast
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,… Read more »
Peter
Gast

Auf einen Blick u.a.

– Kein valider Quelltext,
– Bedienung der Seite ohne Maus schwierig, da ohne sichtbaren Focus
– Diveritis vom Feinsten
– fehlende Semantik an vielen Stellen
– aufgeblähter Quältext

Darüber hinaus muss man dem Kommentar von Jens zu 100% zustimmen.
TBL wird bestimmt beim Lesen des „innovativen Beitrags“ schlecht.

Marc
Gast
Wenn man nur einen Hammer hat, sieht alles aus wie ein Nagel. Von hinten durch die Brust ins Auge, sagt man bei uns. Wäre ja alles nicht so schlimm, wenn man damit die wesentlichen Vorteile der diversen HTML-Elemente (Semantik, Zugänglichkeit, eingebaute clientseitige Validierungen usw – alles in einer dem Nutzer bekannten Form) nicht verlieren würde – alles nachbauen in JavaScript? Wozu, wenn es bereits funktioniert? Im Übrigen sind es für gewöhnlich nicht die nächsten zehn Jahre, die Probleme machen – Millionen „alter“ Webseiten funktionieren bis heute – und wenn nicht, dann liegt es nicht am HTML! Ist die Erfindung von… Read more »
Dan
Gast
@Jens: Dir muss ich in vielen Punkten zustimmen, gerade wenn man Deine Aussagen im Kontext einer Website betrachtet. Dann ist der Ansatz mit RISC-HTML nicht sinnvoll. Wenn man den Kontext von einer Website zu einem Web Frontends für Geschäfts- und Industrieanwendungen (B2B) verschiebt, dann macht das durchaus Sinn. – Browser kompatibel: Sieht auf allen (modernen) Browser gleich aus (zero-installation, zero-maintenance) – Performance: auch bei der Darstellung sehr großer Eingabemasken oder langen Tabelleninhalten – Investitionssicherheit: denn neben HTML unterstützt das Framework CaptainCasa auch JavaFX und Swing. Man kann jederzeit (mit sehr wenig Aufwand) zwischen den Technologien wechseln – Umfangreiche Komponenten Bibliothek… Read more »
Jens Grochtdreis
Gast
Hallo Björn, hallo Dan. Mir ist schon klar, dass mit dem verkrüppelten HTML (a.k.a. RISC-HTML) keine normalen Webseiten, sondern Applikationen gebaut werden. Und es ist mir auch klar, dass es viele Widgets noch immer nicht gibt, obwohl man sich bei der Spezifizierung von HTML5 echt Mühe gab. Und all diese Widgets, die Björn genannt hat, gibt es schon in hundertfacher Ausfertigung, teilweise als Stand-Alone, teilweise als Bestandteil eines UI-Frameworks wie jQuery-UI. Eigentlich muss man also nur noch ein als gut befundenes UI-Element nehmen und einbauen. Stattdessen baut ihr alles selber, sicherlich als Closed-Source und vor allem nur für Euch. Bei… Read more »
Jens Grochtdreis
Gast

Noch ein Punkt zum Einsatzgebiet: ich finde es irrelevant, ob es sich um eine Webseite oder eine Applikation handelt. Beides basiert auf HTML. Das HTML nutzt man so weit es geht. Wenn HTML erweitert werden muss, nutzt man dafür JavaScript. Das ist kein neuer Ansatz, das machen wir schon immer so.

Frontendentwicklung ist wie Softwareentwicklung ein Handwerk. Und genau, wie der Verzicht auf Klassen und die Einführung von Spaghetti-Code bei einem Java-Entwickler sicherlich zu großer Aufregung führen würde, regt es mich auf, wenn jemand ohne Not Frontendtechniken verkrüppelt.

Stefan Tilkov
Gast

Eigentlich wollte ich einen langen Kommentar schreiben, aber dann habe ich den von Jens gesehen und schreibe einfach nur: +1