Bereits in einem kürzlich erschienenen Artikel hier auf der Webseite habe ich vom Ausprobieren neuer Frameworks geschrieben - dieser Artikel behandelt ein weiteres...

Ich habe nach der Entdeckung von Vaadin zunächst einmal sehr euphorisch reagiert - schien es mir doch zu versprechen, dass ich als eingefleischter Desktop-Java-Programmierer kaum umlernen müsste um Anwendungen als Webanwendung zur Verfügung zu stellen.

Ich entschloss mich daher, diese Hypothese kleineren Tests zu unterziehen: Der erste Test war eigentlich nicht ernstzunehmen: Ich las die Playlists meines DVB-C->IP Umsetzers aus und erstellte daraus tabellarische Übersichten, denen ich in jeder Zeile das Senderlogo, den Namen des Senders sowie zwei Knöpfe spendierte: einen zum Abspielen des Streams und einen zum Einreihen einer Aufnahme nach Konfiguration einiger Eckdaten wie Startzeit und Dauer.

Nachdem ich dieses kleine Projekt für mich befriedigend abgeschlossen hatte, konnte ich darüber nachdenken ernsthaftere Tests ins Auge zu fassen. Ich habe bei mir auf der Festplatte noch ein Solitair-Spiel herumliegen, das eines meiner ersten vollständigen Programme in Java darstellt.

Ich nutzte die Zeit um zunächst die Abhängigkeiten von javax.swing.* in diesem Projekt in einigen wenigen Klassen zusammenzudrängen. Die Idee dahinter war, dass es mir damit gelingen sollte, die Mehrzahl der Klassen ohne nochmalige Anpassung in das neue Web-Projekt zu migrieren und nur wenige Klassen mit überschaubarem Aufwand von Swing zu Vaadin zu migrieren. Ich habe das Projekt nach anfänglichen Erfolgen zunächst ruhen lassen. Das soll nicht bedeuten, dass ich Vaadin für ungeeignet halte. Meine gewonnenen Erkenntnisse lassen mich aber zu dem Schluss kommen, dass einige meiner Grundannahmen falsch sind und ich den generellen Migrationsplan nicht mehr so aufrechterhalten kann wie gedacht.

Folgende Tatsachen brachten mich zu dieser Erkenntnis (Stand Version des Frameworks: 13.0.11):

Fehlende Unterstützung der mittleren und rechten Maustaste

Obwohl in der API die Möglichkeit angedeutet wird, bei ClickEvent die jeweilige Maustaste zu ermitteln, lösen aktuell die beiden genannten dieses Event gar nicht aus

Keine stabile Unterstützung von Doppelklicks mit der Maus

Ein ClickEvent erlaubt es, die Anzahl der Clicks zu ermitteln. Allerdings werden Doppelklicks nicht immer propagiert, so dass man auf diese Interaktionsmetapher in der Anwendung nicht zurückgreifen sollte.

Komplizierte Realisierung von GUI-Modifikationen aus dem Backend

Mein Projekt baut zunächst die GUI auf und lässt darin Platzhalter leer, deren Initialisierung längere Zeit in Anspruch nimmt, damit die Responsiveness für den Anwender besser wird. So etwas ist in Vaadin nur sehr schwer zu erreichen - entweder durch Hacks oder durch die Entwicklung eigener Komponenten - es war aber gerade mein Ziel, dass ein ausgewiesener Swing-Programmierer sich nicht mit Web-Frontends belasten müssen sollte.

Im Web gelten andere Timings beim Repaint

Die Struktur meiner Anwendung (ich lernte gerade programmieren!) baut den gesamten GUI-Inhalt bei jeder Interaktion (Karte bewegen) neu auf - am Desktop bemerkt das der Anwender nicht - im Browser ist das so langsam, dass es extrem auffällt. Daher muss zumindest zur Entschärfung dieses Effekts der Entwickler zunächst die Ursprungsanwendung umbauen...

Als Browser wurde für die Tests übrigens der zum Zeitpunkt des Verfassens dieses Artikels die aktuellste verfügbare 64-Bit-Firefox-Version 69.0 unter Ubuntu 18.04 benutzt.