HTML für operativ genutzte Geschäftsanwendungen
Warum laufen nicht mittlerweile alle Geschäftsanwendungen auf HTML-basierten Frontends – und zwar komplett, in allen Bestandteilen? Das hat auf der einen Seite natürlich chronologische Gründe. Viele Anwendungen sind in den 90ern entstanden und haben ein derart mächtiges Frontend, dass eine Ablösung wohin auch immer ein großes Risiko darstellt. Aber es hat auch inhaltliche Gründe: denn HTML – so akzeptiert, wichtig und gut es auch für manche Szenarien ist - hat immer noch Probleme, im Bereich komplexer Frontendszenarien eine attraktive Lösung darzustellen.
Nehmen wir an, Sie stellen ein Warenwirtschaftssystem her: Welche UI-Technologie würden Sie verwenden, wenn es darum geht, z. B. Endkunden in einem Shop die Waren zu verkaufen oder Lieferanten in Lagerbestände Einblick zu gewähren? – Ganz klar: HTML! Hier zählt "zero installation" verbunden mit einer bewussten, relativen Einfachheit der Szenarien.
Und welche UI-Technologie würden Sie verwenden, um interne Abläufe im Lager, bei der Disposition, im Bestellwesen, im Controlling abzubilden? – HTML? Oder doch lieber Java (SWT, Swing, FX) oder C#? Eine einfache Antwort fällt hier weniger leicht. HTML-basierte UI-Technologien drängen sich in komplexen, operativen Bereichen nicht mit der gleichen Vehemenz auf wie in anderen Bereichen.
Komplexe Oberflächen
Komplexe, operativ genutzte Frontends von Geschäftsanwendungen werden i. d. R. von Sachbearbeitern oder Power-Usern (Call Center) verwendet. Die Komplexität der Frontends entspricht der Komplexität der Aufgaben, die diese Personengruppen zu erledigen haben und kann deswegen entsprechend hoch sein. Dies bedeutet konkret:
- Viele Informationen, die gleichzeitig dargestellt werden.
- Komplexe Bedienweisen, wie z. B. Drag-and-drop, Zoomen, dynamische Tab-Steuerung, Wertauswahldialoge mit flexiblen Suchmöglichkeiten, Auto-Complete in Feldern
- Hohe Bedien-Performance
Vor lauter "Simplicity first" mag manch einer sich heutzutage fragen, ob es diese Szenarien wirklich überhaupt noch gibt...
Am meisten lohnt sich hier als Softwareentwickler der Blick auf den eigenen Arbeitsplatz: Für die komplexen, zentralen Dinge (Programmieren) hat man seine Power-Tools (Entwicklungsumgebung), liebt deren Konfigurierbarkeit und verteilt deren Informationen auf zwei oder mehr Bildschirme. Für die nicht ganz so zentralen Dinge (Projektrückmeldung, Reisekostenabrechnung, …) hat man in der Regel Web-Frontends, die dann hoffentlich so einfach sind, dass man bis zum "Speichern"-Knopf am Ende durchkommt.
Und genauso geht es dem Sachbearbeiter oder Power-User. Etwas pointiert gesagt: der will auch "Efficiency first“-Power-Tools für seine zentralen Aufgaben – und will in diesen Bereichen nicht abgespeist werden mit "Simplicity first"-Webseiten!
HTML-Probleme im Bereich komplexer Oberflächen
Warum also ist die Entscheidung für HTML in komplexen, operativen Szenarien immer noch mit einer großen Skepsis verbunden? – Nun, es sind die Erfahrungen, die man mit HTML im Laufe der letzten Jahre gemacht hat. Und neben allen positiven Erfahrungen gibt es auch eine Reihe negativer:
- Der Kampf mit Kompatibilitätsproblemen ist ein ständiges Ärgernis. Zwar haben sich W3C-Standards mittlerweile weitaus besser durchgesetzt als noch vor Jahren, aber dafür ist die Anzahl der Browser und Devices stark gestiegen – genauso wie die Komplexität des Standards. Und bitte nicht vergessen: Wir reden hier nicht über die einfachen Szenarien, sondern über komplexe Oberflächen! Und in diesen wird der Funktionsumfang von HTML entschieden intensiver genutzt.
- Es mag paradox klingen, aber immer noch hat HTML mangelnde Layouting-Fähigkeiten in bestimmten, aber wichtigen Bereichen. HTML ist noch immer eine Seitenbeschreibungssprache mit unbegrenzter Seitenlänge – und keine Bildschirmbeschreibungssprache. Einfache Anwendungsszenarien, wie mehrfach geschachtelte feste und flexible vertikale Bereiche (z. B. fixer Header/Footer mit variablem Content-Bereich), sind nur mit Schwierigkeiten umzusetzen.
- Frameworks im HTML-Bereich sind kurzlebig – verglichen mit dem Lebenszyklus einer Anwendung. Kein Wunder: in vielen HTML-Anwendungsszenarien sind die entstehenden Frontends genauso kurzlebig und werden regelmäßig durch Neuimplementierung ausgetauscht. Ein Austausch eines Frameworks im Bereich komplexer Sachbearbeiter-Frontends ist hingegen eine komplexe Operation und die Lust, solche Frontends alle Jahre neu zu implementieren, besteht bei Softwareherstellern in der Regel nicht.
- JavaScript als Programmiersprache im Client erfordert eine sehr hohe Disziplin aller beteiligten Entwickler und bietet nicht die langfristige Struktur, innerhalb der man umfangreiches, komplexes Coding abbilden will.
Eine klassische HTML-basierte Frontendentwicklung für komplexe Szenarien ist somit immer noch mit Risiken und hohen Entwicklungs- und Wartungskosten verbunden. Dazu kommt das Gefühl eines gewissen Kontrollverlustes, da Wartungsaufwände (z. B. durch einen neuen Browser/Device-Version) von außen aufgeprägt werden.
Also doch lieber native Technologien (Java, C#, …) für solche Szenarien?
Ein neuer Ansatz: RISC-HTML
Mit "RISC-HTML" gibt es nun einen neuen, auf dem Browser basierenden Ansatz, der für das Bereitstellen komplexer Frontends geschaffen wurde. Der Ansatz stammt von der deutschen Firma CaptainCasa und der zugehörigen Community und hat dort zu einer Ablösung vormals Java/JavaFX-basierter Anwendungs-Frontends geführt. "RISC-HTML" steht für "Reduced Instruction Set Client-HTML" und ist eine durchaus ernst gemeinte Analogie zur CISC/RISC-Diskussion im Bereich der Rechnerarchitekturen. Wagen wir also einen kurzen Sprung zurück:
CISC-Prozessoren ("Complex Instruction Set Computer") versuchten, möglichst viele Befehle direkt im Prozessor zur Verfügung zu stellen – nach dem Motto: Nur ein Befehl, der in der Hardware abläuft, ist ein guter Befehl. Konsequenz: Die Prozessoren wurden immer komplexer, konnten als Folge nicht hoch getaktet werden und Fehler im Schaltungsdesign der betreffenden Befehle waren nicht bzw. nur durch Austausch des Prozessors zu beheben. RISC-Prozessoren leiteten einen Paradigmenwechsel ein: der Prozessor führt noch grundlegendste Befehle aus, die Algorithmik eines komplexen Befehls (z. B einer Floating Point Operation) wird nicht im Prozessor abgewickelt sondern im Programm, das den Prozessor durchläuft. Ergebnis: ein wesentlich vereinfachtes Prozessordesign, wesentlich höhere Taktraten, wesentlich geringere Fehleranfälligkeit.
Die Gedanken zur Prozessorarchitektur lassen sich in frappierender Weise auf die Browserarchitektur übertragen. Der Browser ist mittlerweile ein komplexer "CISC-Prozessor" geworden, mit immer mehr HTML-Elementen und CSS-Funktionen. Jedes Element und jede Funktion ist hart im nativen Code des Browser verdrahtet. Im Fehlerfall ist ein Austausch des Browsers zumindest im Unternehmensumfeld ähnlich schwierig wie der Hardwareaustausch eines Prozessors.
Das RISC-HTML-Prinzip ist nun ein ähnlicher Paradigmenwechsel innerhalb der Betrachtung des Browsers, wie es das RISC-Prinzip bei Prozessoren war. Das RISC-HTML-Prinzip lautet: man reduziere die Nutzung des Browser auf diejenigen Elemente und Funktionen, die man minimal benötigt, um darauf aufbauend außerhalb der eigentlichen Browser-Verarbeitung höherwertige Oberflächenelemente ("Controls") zu bauen.
Für das Zusammenbauen grundlegender Oberflächenelemente genügen bereits sehr wenige Kernelemente, die vom Browser gefordert werden:
- DIV-Elemente – also rechteckige Bereiche mit/ohne Hintergrund und mit/ohne Text
- INPUT-Elemente – also Bereiche zur Texteingabe
Für diese Elemente wird als einziges Positionierungsmittel die absolute Positionierung gewählt (x,y,width,height,z). Alle höherwertigen Controls werden nun aus diesen Kernelementen zusammengebaut. Ein Button, ein Feld mit Eingabeunterstützung, ein Menu, ein Grid, ein Dialog – all diese Elemente materialisieren sich also intern in die genannten Kernelemente.
Jetzt muss es natürlich eine bestimmte Logik geben, die dieses "Materialisieren" durchführt – und diese Logik wird in Form von JavaScript-Bibliotheken zur Verfügung gestellt. Konkret: hinter z. B. einem Menu-Control steht ein JavaScript-Programm, das entsprechend Kernelemente zusammenfügt, so dass am Ende ein interaktives Menu an einer bestimmten Stelle gezeichnet wird.
Auf unterster Ebene gibt es einen "Microkernel", der nichts anderes macht, als den Zugriff auf die Kernelemente zu kapseln. Auf diesen Kernel greifen dann die Control-Implementierungen zu, angefangen von "kleinen" Controls (Button, Combo-Field, …), über Layout-Container, Grid/Tree Controls bis hin zu modalen/amodalen Dialogen. Die Controls sind letztendlich die Klassen, die dann dem Nutzer zum Bauen von Oberflächen zur Verfügung gestellt werden.
Vorteile der RISC-HTML-Methode
Bei der RISC-Methode wird die Algorithmik zur Bildung von Controls in eine JavaScript Library geschoben. Der Browser ist nur noch eine Rendering-Execution-Ebene für das simple Ausgeben von Kernelementen – und für das Empfangen entsprechender Events auf diesen. Der Browser wird nicht mehr in seiner vollen Bandbreite an Elementen genutzt (TABLE, TR, TD, UL, LI, …) sondern nur noch in restringierter Art und Weise (DIV, INPUT).
Die zentralen Vorteile der RISC-HTML-Methode leiten sich direkt aus dieser Benutzung ab:
- Kompatibilitätsprobleme gibt es per design praktisch nicht mehr. Die verwendeten Kernelemente sind so einfach, dass jeder moderne Browser diese rendern kann. Und zudem sind diese Kernelemente in einer Microkernel-Library gekapselt, so dass potenzielle Inkompatibilitäten sich nur auf dieser Ebene abspielen – und nicht auf der wesentlich umfangreicheren Control-Ebene darüber.
- Layouting-Restriktionen gibt es per design nicht mehr. Die Verantwortung für das Layouting liegt nun in den JavaScript-Controls. Jedes Control weiß, wie es seine Unterkomponenten anrichtet – und tut das durch das Setzen entsprechender Koordinaten. Dies gilt für den einfachen Button genauso wie für dann komplexere Layout-Container.
Und wie steht's mit der Performance? Immerhin werden ja nun Aufgaben, die vorher im nativen Browser abliefen, in eine JavaScript Ebene hineingeschoben. Die Antwort ist überraschend: die Performance auf den aktuellen Browsern ist außerordentlich gut! Hintergrund hierzu ist zum Einen, dass die Geschwindigkeit der JavaScript-Interpreter in den letzten Jahren dramatisch gestiegen ist. Und zum anderen scheinen es die Browser zu "lieben", auch in großer Anzahl "Rechtecke" absolut zu rendern – vermutlich mit einem recht direkten Draht zur ausführenden Grafikkarte.
... und Herausforderungen
Schaut man sich das HTML einer "klassischen" Webseite an, so erkennt man in diesem durch die Wahl der Elemente eine gewisse Semantik. Eine RISC-HTML-Seite hingegen besteht aus einer Vielzahl zusammengesetzter DIV-Elemente. Die Semantik, welches Control sich hinter einer DIV-Konstellation verbirgt, ist natürlich über Style-Klassen-Zuordnung ablesbar. Aber einige Tools, die auf die klassische HTML-Semantik setzen, greifen hier zunächst ins Leere. Hierzu gehören beispielsweise Crawler von Suchmaschinen oder auch Accessibility-Tools.
Immerhin: diese Problematik ist nicht neu im Web-Umfeld und taucht überall dort auf, wo höherwertige Controls aus HTML erstellt werden – und das ist mittlerweile fast überall.
Positionierung
RISC-HTML ist für die Entwicklung komplexer, interaktiver Oberflächenszenarien für Geschäftsanwendungen positioniert. Es wendet sich an Szenarien, in denen Langfristigkeit von entwickelten Oberflächen und Kompatibilität über Jahre hinweg ein große Rolle spielt.
RISC-HTML ist positioniert für Szenarien, in denen Oberflächen "entwickelt" werden – und ist nicht geeignet für Szenarien in denen Oberflächen per HTML "designed" werden.
CaptainCasa Enterprise Client
RISC-HTML ist zentraler Bestandteil des Rich Client Frameworks "CaptainCasa Enterprise Client". Hier löst der RISC-HTML Client die vorher genutzten Java-Swing und Java-FX Clients ab. Innerhalb dieses Frameworks steht der HTML-RISC-Client als äußerst reichhaltige Control Library zur Verfügung – und wird gleichzeitig in den Kontext einer serverseitigen Java-Interaktions- und Anwendungsverarbeitung eingebunden. Die Dialoge werden über ein enstprechendes Tooling (Wysiwyg-Editor) erstellt.
Das CaptainCasa-Framework steht ohne funktionale Einschränkungen kostenfrei zur Verfügung [1].
Fazit
Kann man mit klassischem HTML komplexe, operativ genutzte Frontends bauen? Es wäre töricht, hier "Nein!" zu sagen, denn es gibt ja durchaus Beispiele, die das belegen. Genauso töricht wäre es aber, zu verschweigen, dass HTML für diese Szenarien keine ideale Lösung ist – und dass das "zero installation" von HTML durchaus teuer erkauft wird und für den Softwarehersteller mit hohen Entwicklungs- und langfristigen Wartungsaufwänden verbunden ist.
RISC-HTML ist für diese Szenarien ein neuer Ansatz. Es nutzt den Browser als Execution-Plattform für grundlegende Rendering-Operationen und bildet die Control-Welt oberhalb des Browsers in einer JavaScript-Control-Library ab. Vorteile dieser Entkopplung sind eine sehr gute Browser/Device-Kompatibilität, das Überwinden von HTML-Layouting-Begrenzungen und eine sehr gute Frontend-Performance.
