Zwischen RapidClipse 3 und der neuen Version 4 ist sehr viel Zeit vergangen und in Sachen UI gibt es scheinbar keine Neuerungen. Der folgende Artikel erklärt die nicht ganz triviale Problematik und die Entscheidungen die wir treffen mussten.

HTML5 Oberflächen mit Vaadin

Für die Entwicklung moderner HTML5 Oberflächen setzt RapidClipse von Beginn an auf das UI-Framework Vaadin. Auch andere UI-Frameworks wären grundsätzlich für RapidClipse in Frage gekommen, z.B. das Java UI-Framework Google Web-Toolkit, das nach der Übergabe des Codes an die Community in GWT umbenannt wurde. Vaadin ist jedoch bis heute das einzige UI-Framework, das sowohl den Server-, als auch den Client-Teil zur Verfügung stellt und die permanente Kommunikation zwischen beiden Teilen vollautomatisch managed, sodass man sich als Entwickler nicht darum kümmern muss. Mit GWT ist das Ergebnis lediglich ein reiner Web-Client. Um den dazugehörigen Server und die Kommunikation zwischen Client und Server muss man sich als Entwickler selber kümmern. Darüber hinaus ist das Programmiermodell von Vaadin vergleichbar mit Java Swing, das im Java Umfeld auch heute noch weit verbreitet ist.

Das UI-Framework Vaadin besteht aus 2 Teilen:

• Java Server-Framework
• UI-Client mit JavaScript UI-Widgetset

Kurzer Rückblick - Die Ära Google Web-Toolkit bis Vaadin 8

Vor 12 Jahren haben die Vaadin-Entwickler das Google Web-Toolkit in das Vaadin Framework integriert, um das gesamte Vaadin UI-Frontend mit GWT zu erzeugen. GWT ist ein reines Java UI-Framework inklusive Pre-Compiler, der den in Java geschriebenen UI-Code nach JavaScript-Code compiliert, der dann im Web-Browser ausgeführt werden kann (der UI-Client). Der Vorteil für das Vaadin-Team bestand zum einen darin, dass GWT bereits alle wichtigen Browser-Optimierungen mitbringt, sodass sich weder das Vaadin-Team, noch Vaadin-Nutzer darum kümmern müssen. Zum anderen wurde GWT damals noch vollständig von Google entwickelt, das damit auch eigene, wichtige Applikationen entwickelt hat, was nicht nur die Möglichkeiten unter Beweis stellt, sondern auch bestmöglichen Support und Weiterentwicklung garantiert. Damit Vaadin-Nutzer mit GWT selbst aber nicht in Kontakt kommen, liefert das Vaadin-Framework ein bereits vorcompiliertes UI-Widget-Set mit. Da die GWT-Komponenten kein optisches Highlight waren, hat Vaadin dafür ein eigenes, modernes CSS-Theme entwickelt: das Vaalo-Theme. Zur Laufzeit wird der gesamte JavaScript-UI-Client dann dynamisch vom serverseitigen Vaadin Java-Framework erzeugt. Per Databinding werden die Vaadin/GWT-JavaScript-UI-Widgets im Browser mit dem Vaadin-Serverteil verbunden. Um die Übertragung von Daten kümmert sich der Serverteil vollautomatisch. Bis Vaadin 7 gab es keine Abweichung von dieser Architektur.

Immer dasselbe Problem mit UI-Frameworks

Seit eh und je ist UI-Entwicklung mit JavaScript-Frameworks eine große Herausforderung. Jedes JavaScript Framework bringt sein eigenes UI-Widget-Set, eine eigene Architektur und Programmiermodell mit. Das hat immer wieder dieselben Probleme zufolge. Entweder fehlen bestimmte Widgets, das Design gefällt nicht, die Entwicklung eigener UI-Widgets ist extrem kompliziert, die Framework-Entwickler wollen nach kurzer Zeit alles besser machen und brechen mit neuen Version die Abwärtskompatibilität, kommen mit Browser-Anpassungen nicht hinterher oder klammern bestimmte Plattformen und Versionen einfach aus oder das Framework wird gar nicht mehr weiter entwickelt. JavaScript-Frameworks die nicht mehr weiter entwickelt werden, sind jedoch bereits nach kurzer Zeit unbrauchbar und darauf basierende Web-Projekte müssen enorm aufwändig migriert werden. Durch zahlreiche neue Projekte bei Google wie AngularJS, Dart etc., flachte auch der anfängliche Hype um GWT stark ab. Heute hat GWT nur noch eine vergleichsweise geringe Bedeutung.

Web-Components - Endlich zukunftssichere HTML Oberflächen

Die Lösung der Problematik zueinander inkompatibler UI-Libraries soll ein neuer Standard lösen: Web-Components. Web-Components sind JavaScript UI-Komponenten, die auf einer vom W3C standardisierten Architektur basieren, ihren eigenen Code mitbringen und völlig unabhängig von einem bestimmten UI-Framework lauffähig sind, von allen Browsern unterstützt, gleich dargestellt werden und sich gleich verhalten, mit gewöhnlichen HTML-Tags in jede HTML-Seite eingebunden und damit auch zusammen mit jedem beliebigen JavaScript Framework kombiniert und somit Wiederverwendet werden können. Nervtötende und teure Migrationen von einem hippen UI-Framework auf das nächste werden damit endlich überflüssig. Web-Components werden bereits von den meisten Browsern nativ unterstützt. Das von Google entwickelte Framework Polymer sorgt dafür, das Web-Components auch in allen anderen Browsern funktionieren. Web-Components sind die UI-Technologie der Zukunft.

Vaadin beginnt mit der Entwicklung von Web-Components

Etwa ab 2014 hat Vaadin damit begonnen, an einem völlig neuen UI-Widget-Set zu arbeiten, das nicht mehr auf GWT basiert, sondern aus Web-Components besteht. Aus unserer Sicht war dies eine brillante Entscheidung. Vaadin hat sehr viel früher als andere UI-Framework-Hersteller den Vorteil von Web-Components erkannt und gehört damit zu den Web-Component Pionieren. Zudem hat Vaadin erkannt, dass man eine Web-Components Library nicht nur für das eigene Vaadin-Framework brauchen kann, sondern dass sie damit auch den gesamten Markt für JavaScript Libraries adressieren können. Vaadin hat deshalb beschlossen, die neuen Web-Components auch unabhängig vom klassischen Vaadin-Framework zu vermarkten. Es folgte die Aufsplittung in 2 unabhängige Produkte:

1. COMPONENTS - die reinen, client-seitigen Web-Components, die nun auch JavaScript Entwickler nutzen können und
2. FLOW – das ursprüngliche, serverseitige Vaadin Framework für Java Entwickler.

Neues Databinding für Web-Components

Um Web-Components im Vaadin-Framework nutzen zu können, musste Vaadin ein neues Databinding entwickeln. Doch anstatt UI-Komponenten und Databinding in einem Aufwasch auszutauschen, wurde mit Vaadin 8 zuerst das neue Databinding eingeführt. Mit Vaadin 10 sollten dann die GWT-Komponenten durch die neuen Web-Components ersetzt werden.
Für Anwender, die mit einem neuen Projekt starten wollen, ist es vorteilhaft, gleich das neue Databinding nutzen zu können. Für Anwender bestehender Vaadin 7 Projekte bedeutet ein neues Databinding Migrationsaufwand und der nachfolgende Umstieg auf Vaadin 10 erneut – also doppelten Migrationsaufwand.

Vaadin 8 - nur ein Zwischenschritt

Damit bestehende Vaadin 7 Projekt nicht 2 Mal migriert werden müssen, wurde für Vaadin 8 ein sogenannter Kompatibilitäts-Layer eingeführt, mit dem es möglich sein sollte, Vaadin 7 Anwendungen ohne Migrationsaufwand weiterhin mit Vaadin 8 betreiben zu können.
Mit diesem Feature wollten wir bereits 2017 RapidClipse 4 mit Vaadin 8 ausliefern. Allerdings mussten wir feststellen, dass der Kompatibilitäts-Layer wichtige Vaadin 7 Features überhaupt nicht unterstützt. Da zu dieser Zeit Vaadin 10 bereits in der Entwicklung war, haben wir uns dazu entschieden Vaadin 8 zu überspringen und auf Vaadin 10 zu warten - und damit RapidClipse 4 bis zur Freigabe von Vaadin 10 zu verschieben, bzw. solange zu warten bis Vaadin 10 erst einmal stabil ist.

Vaadin 10 – Einführung der neuen aber halbfertigen Web-Components  

Mit Vaadin 10 hat Vaadin schließlich die auf GWT basierenden UI-Stack durch die neuen Web-Components ersetzt. Mit Version 10 konnte Vaadin jedoch keine, auch nur annähernd mit Vaadin 7 im Umfang gleichwertige Widget-Palette bieten. Für fast die Hälfte aller Vaadin 8 Komponenten gab es keinen Ersatz. Neben Komponenten wie Accordeon, DateTimeField, PopupView, ContextMenu etc. fehlten sogar elementar wichtige Komponenten wie Tree, CheckBoxGroup, RichTextArea und MenuBar.

RapidClipse 4 mit Vaadin 10 auszuliefern hätte bedeutet, dass man bei neuen Projekten mit gravierenden Einschränkungen im Vergleich zu RapidClipse 3 hätte leben müssen. Und die Migration bereits existierender RapidClipse 3 Projekte wäre einer kompletten Neuentwicklung der gesamten Oberfläche gleichgekommen – jedoch mit deutlich geringerer Funktionalität.

Web-Components erst heuer mit Vaadin 14 richtig fertig

Auf der Oracle Code One 2018 in San Francisco hat Vaadin kommuniziert, dass man voraussichtlich mit Vaadin 14 den Umfang der UI-Widget-Palette von Vaadin 8 wieder erreicht haben wird, die dank der sehr frühen Freigabe mit Vaadin 10, dann aber auch ausgereift und stabil sein wird. Vaadin 14 wird im Juni 2019 verfügbar sein.

Umstellung auf Web-Components kam zu früh. RapidClipse überspringt 5 Vaadin Versionen.

Es ist nachvollziehbar, dass Vaadin im super-kurzlebigem JavaScript-Umfeld durch die frühe Freigabe der neuen Vaadin Components möglichst früh einen Fuß in die Türe bekommen und möglichst der erste Hersteller einer umfangreichen Web-Components Widget-Palette werden wollte. Die neuen Web-Components aber auch so früh, halbfertig in das serverseitige Java-Framework Vaadin 10 zu integrieren, war für das RapidClipse Projekt sehr unglücklich, da wir unmöglich RapidClipse 4 mit Vaadin 10 ausliefern konnten. Da erst Vaadin 14 den nötigen Umfang besitzen wird, den wir für RapidClipse benötigen, haben wir uns dazu entschieden, die Vaadin Versionen 8, 10, 11, 12 und 13 zu überspringen.

Ausblick auf RapidClipse 5

Da mit Vaadin 14 nun bald eine vollständige und ausgereifte Web-Components Palette zur Verfügung stehen wird, planen wir, RapidClipse 5 mit Vaadin 14 auszuliefern und damit auch RapidClipse 5 auf Web-Components umzustellen.

Für den Umgang mit Web-Components muss der RapidClipse GUI-Builder vollständig überarbeitet werden. Die Entwicklungsarbeiten dazu laufen bereits auf Hochtouren. Da auch ein neues Databinding nötig ist, wurde bereits das gesamte RapidClipse Framework entsprechend auf die Möglichkeit zur Anbindung von Web-Components umgeschrieben.

Mit den neuen Web-Components werden mit RapidClipse entwickelte Oberflächen nicht nur sehr viel performanter sein, auch die Entwicklung mobiler Apps wird damit stark verbessert. Zudem wird die Einbindung beliebiger anderer Web-Components die Möglichkeiten mit RapidClipse insgesamt stark vergrößern.

Web-Components bilden den neuen Standard im Bereich Web-Frontend-Entwicklung. Mit einer auf Web-Components basierenden Web-Anwendung profitieren Sie von bisher, im Bereich Web-Entwicklung, nie dagewesener Stabilität und Investitionssicherheit.

RapidClipse 5 Vorstellung im September auf der XDEVCON 2019

Unser Ziel ist es, RapidClipse 5 auf der diesjährigen XDEVCON 2019 vorzustellen, die vom 24. bis 26. September 2019 in Düsseldorf stattfindet. RapidClipse 5 wird die bedeutendste RapidClipse Version seit Beginn des gesamten RapidClipse Projektes. Wenn Sie bereits mit RapidClipse entwickeln oder sich für RapidClipse interessieren, dann sollten Sie dieses Jahr in jedem Fall zur XDEVCON 2019 kommen. Die XDEVCON 2019 ist die große RapidClipse Konferenz. Hier erleben Sie bis zu 20 Vorträge zu RapidClipse - von der Einführung bis zu Experten-Themen sowie spannende Erfahrungsberichte großer RapidClipse Anwender und haben die Möglichkeit das RapidClipse Team persönlich zu treffen.

Jetzt gleich für die XDEVCON 2019 anmelden