Suche
GXT gegen das Rentier

GXT versus Vaadin: Zwei Webframeworks im Vergleich

Holger Herrmann

© Shutterstock.com / Adam Vilimek

Die wachsende Beliebtheit von Webanwendungen für Unternehmen hinterlässt Spuren: Allein Wikipedia listet über 50 Web Application Frameworks auf (wobei GXT erstaunlicherweise nicht darunter ist). Die Benutzerzahlen steigen, und auf der Java-Konferenz JAX kann man am Web UI Day viele Talks zum Thema hören. In diesem Artikel stelle ich das Framework GXT der Firma Sencha neben den „großen Bruder“ Vaadin des gleichnamigen finnischen Unternehmens und beleuchte die Architekturen sowie die ersten Schritte mit den Frameworks bis hin zu einer funktionierenden Webanwendung.

Waren bislang Fat Client Applications auf einem Desktop-PC der Standardfall, so kommt heute immer mehr eine Thin-Client-Architektur zum Einsatz. Dieser Trend wird nicht zuletzt von der Cloud getrieben, die verspricht, alle Anwendungen zu jeder Zeit und überall verfügbar zu machen. Natürlich möchte man auf Clientseite in Sachen Performance, Usability und Design möglichst keine Abstriche machen. An dieser Stelle setzen die immer populärer werdenden Web-Application-Frameworks an: Mit ihrer Hilfe soll eine Thin-Client-Anwendung mit dem Look-and-Feel einer Desktopanwendung erstellt werden.

In diesem Artikel zeige ich die ersten Schritte mit zwei der großen Web Application Frameworks: Vaadin 7 und Sencha GXT (in der Version 3.1). Beide bauen auf dem Google Web Toolkit (GWT) auf. Die Besonderheit daran ist, dass der Entwickler sowohl den Servercode als auch den Code für den Client in Java schreiben kann. Der GWT Compiler übersetzt den Clientcode automatisch nach JavaScript, sodass er problemlos in allen gängigen Browsern laufen kann.

GXT: Clientbasiertes Webframework

Die Firma Sencha aus den USA hat mit ihrem Produkt „Sencha GXT“ ein leistungsstarkes Webframework auf Basis von GWT auf dem Markt. Nach eigener Aussage ist Sencha GXT „the fastest, most powerful way to create rich web-based applications using Java“. Mit diesem Framework wird das Verfahren aufgegriffen, mithilfe des GWT Compilers browserbasierte Anwendungen in Java zu schreiben. GXT-Anwendungen unterstützen die Browser Safari 6+, Firefox, Internet Explorer 8+, Chrome und Opera 12+ [1]. Die gewünschte Browserunterstützung muss – wie bei GWT – beim Kompilieren des Clientquellcodes festgelegt werden. Ebenfalls wie bei GWT gibt es die Möglichkeit, die Anwendung im „Hosted Mode“ (Dev Mode) zu starten. In diesem Fall wird der Clientcode erst zur Laufzeit nach JavaScript übersetzt, sodass es möglich ist, den Clientcode als Java-Code zu debuggen. Das ist bei deployter Anwendung nicht mehr möglich, da der Code bereits nach JavaScript übersetzt wurde. Eine Übersicht über die Architektur einer GXT-Anwendung gibt Abbildung 1.

Abb. 1: Anwendungsarchitektur Sencha GXT

Abb. 1: Anwendungsarchitektur Sencha GXT

Sie unterscheidet sich zunächst nicht von einer „reinen“ GWT-Anwendung. Lediglich im Browserteil ist die Ergänzung „GXT“ ersichtlich. Die GXT-Bibliotheken werden beim Erstellen der Anwendung genau wie die GWT-Komponenten eingebunden. Darauf aufbauend können wiederum spezifische Erweiterungen entwickelt werden.

Als Client wird ein Standardinternetbrowser verwendet, in dem der Clientcode der Anwendung läuft. Dieser enthält die GWT- und GXT-Clientcodeteile, die vorab in JavaScript übersetzt wurden. Mittels asynchroner Remote Procedure Calls (RPCs) werden Anfragen über das Netzwerk an den Webserver gestellt. Zum Einsatz kommt hier die in GWT implementierte AJAX-Technologie. Der Webserver verarbeitet die Anfrage, ggf. unter Zugriff auf ein separates Backend oder direkt auf eine Datenbank, und schickt das Ergebnis des RPCs an den Browser.

Kernstück von Sencha GXT sind die GUI-Komponenten, die als Erweiterungen der GWT-Komponenten erstellt wurden. Auf der Homepage von Sencha finden sich Beispiele und Demos für Drag-and-Drop-Komponenten, Charts, Tabellen u. v. m.

Vaadin, das Rentier aus dem Norden

Der Begriff „Vaadin“ bezeichnet sowohl das Unternehmen als auch das Web Application Framework, das aktuell (Stand: Ende Oktober 2014) in der Version 7.3.3 vorliegt. Die sympathischen Finnen bezeichnen ihr Framework als „Java framework for building modern web applications that look great, perform well and make you and your users happy“. Der Begriff „Vaadin“ bezeichnet im Finnischen ein weibliches Rentier. Als Logo wird eine geschweifte Klammer, gefolgt von einer spitzen Klammer verwendet: }>. Dreht man dieses Zeichen um 90 Grad nach rechts, so erhält man einen stilisierten Rentierkopf.

Der konzeptionelle Ansatz in Vaadin unterscheidet sich zu GXT; dort werden mehr Aktionen im Browser behandelt. Dadurch kann der Kommunikationsaufwand zwischen Browser und Webserver geringer gehalten werden. Bei Vaadin hingegen werden mehr Server-Calls durchgeführt. So werden auch die Events von GUI-Komponenten auf Serverseite ausgeführt. Im „Book of Vaadin“, der umfassenden Dokumentation von Vaadin, findet sich auch eine Abbildung zur Architektur (Abb. 2).

Abb. 2: Anwendungsarchitektur Vaadin

Abb. 2: Anwendungsarchitektur Vaadin

Der clientseitige Code, der auch hier in Java geschrieben und mittels Googles GWT Compiler in JavaScript übersetzt wird, wird als „Widget Set“ bezeichnet. Die Standard-Widgets von Vaadin können dabei um eigenentwickelte „Custom“-Widgets sowie um „Add-on Widgets“ erweitert werden. Bei Letzteren handelt es sich um Komponenten, die von externen Entwicklern auf der Vaadin-Seite zum Download bereitgestellt werden.

Der Architekturabbildung kann man ebenfalls entnehmen, dass UI Events auf dem Webserver behandelt werden. Selbstverständlich können UI Events auch bei GXT an den Webserver weitergegeben werden. Der Fokus bei GXT liegt aber mehr darauf, Funktionalität in den Browser zu verlagern. Bei Vaadin dient der Browser „nur“ der Darstellung: sämtliche Events landen sofort auf dem Webserver. Der Zugriff auf ein Backend oder eine Datenbank unterscheidet sich in beiden Frameworks nicht.

Vaadin unterstützt ebenso wie GXT alle gängigen Browser: Chrome 23+, Internet Explorer 8+, Firefox 17+, Opera 12+, Safari 6+, sowie die Browser von Mobilgeräten für Android 2.3+ und iOS 5+. Für die App-Entwicklung bieten sowohl Vaadin („Vaadin TouchKit“) als auch Sencha („Sencha Touch“) ein eigenes Framework an. Darauf werde ich im Rahmen dieses Artikels nicht näher eingehen.

Dem Chef zuliebe bauen wir eine Sicherheitsunterweisung

Um die ersten Schritte mit den beiden Frameworks zu zeigen, werde ich mithilfe der von den Herstellern gegebenen Tutorials jeweils eine Beispielanwendung implementieren. Als technische Basis verwende ich Eclipse (Luna) sowie Java 8 auf einem Rechner mit Windows 7 (64 Bit). Als Beispielanwendung möchte ich eine einfache Anwendung zur Bestätigung einer Sicherheitsunterweisung umsetzen. Sie soll lediglich aus drei Komponenten bestehen:

  • einem Textfeld für die Erfassung des Benutzernamens
  • einem Datumsfeld zur Erfassung des Datums der Kenntnisnahme
  • einem Button zur Durchführung der Bestätigung

Als zusätzliche Validierung soll hinterlegt werden, dass das erfasste Datum nicht in der Zukunft liegt. Ist das der Fall, soll dem Benutzer ein entsprechender Hinweis angezeigt werden; die Bestätigung darf nicht ausgeführt werden. Wurde ein gültiges Datum erfasst, soll dem Benutzer eine Erfolgsmeldung angezeigt werden.

Los geht’s mit Kodieren: GXT

Beginnen wir mit dem kleineren der beiden Frameworks: Sencha GXT. Ausgangspunkt ist die modern wirkende Homepage des Herstellers: www.sencha.com. Ein Dokument für die ersten Schritte findet man allerdings nicht, wie man erwarten könnte, im Bereich Product| GXT, sondern über den Umweg Community | Documentation | GXT 3.1. Anhand der dort enthaltenen Einführung Getting started with GXT möchte ich die Webapplikation erstellen. Die ersten beiden Voraussetzungen habe ich schon erfüllt: Die aktuelle Version von Java ist auf meinem Rechner installiert, und Eclipse Luna ist auch schon eingerichtet. Als Nächstes muss das Eclipse-GWT-Plug-in installiert werden. Dies soll über den Marketplace geschehen. Da dort die Version für Eclipse Luna nicht vorhanden ist, verwende ich die Plug-in-Version für Kepler. Das hat im weiteren Verlauf keine Probleme verursacht.

Jetzt geht es richtig los: Als Basis für GXT soll zunächst ein GWT-Projekt erstellt werden. Jeder einzelne Schritt für das Erstellen des Projekts ist beschrieben und mit Abbildungen versehen. Die Erstellung funktioniert zunächst problemlos, am Ende liegt ein vollständiges GWT-Projekt gemäß Abbildung 3 vor.

Abb. 3: Projektstruktur GXT

Abb. 3: Projektstruktur GXT

Die Schwierigkeiten beginnen, wenn das Programm gestartet und getestet werden soll. Dazu starte ich zunächst die Anwendung im Development Mode, wie es in der Schritt-für-Schritt-Anleitung ebenfalls beschrieben ist. Ich möchte die Anwendung nicht nur mit Chrome testen, sondern auch mit Firefox und Internet Explorer (Version 11). Ich beginne mit Firefox und erhalte prompt eine Fehlermeldung beim Laden der Anwendung. Sie sagt mir, dass für das Starten der Anwendung im Development Mode das GWT Developer Plug-in notwendig ist. Das gibt es aber nicht für die aktuelle Firefox-Version. Eine Möglichkeit wäre der Download einer älteren Version. Da damit aber nicht gesagt werden kann, wie die Anwendung in der aktuellen Version aussehen wird, ist das keine praktikable Lösung; der Development Mode scheidet somit für Firefox aus. Möchte man trotzdem dafür entwickeln, muss vor jedem Start der GWT Compile durchgeführt werden, was für die Entwicklung einen recht hohen Zeitverlust darstellt.

Der nächste Versuch, das Starten im Internet Explorer, verläuft zunächst nicht viel erfolgreicher. Auch hier wird auf das fehlende GWT Developer Plug-in hingewiesen. Interessanterweise wird per Link allerdings das Plug-in für Firefox angeboten, womit man natürlich nicht ans Ziel kommt. Es gibt aber einen Trick: Öffnet man die Developer Tools (F12), so findet man im Menü EMULATION den Dokumentenmodus (Abb. 4).

Abb. 4: Um das GWT Developer Plug-in im IE11 installieren zu können, wendet man einen Trick an

Abb. 4: Um das GWT Developer Plug-in im IE11 installieren zu können, wendet man einen Trick an

Diesen ändert man auf IE10, und nach erneutem Laden der Seite kann das richtige Plug-in installiert werden. Nach dem Bestätigen einer Sicherheitsabfrage wird die Seite dann auch korrekt geladen (Der Dokumentenmodus kann auf Edge zurückgesetzt werden).

In Chrome läuft das Ganze flüssiger. Natürlich muss auch dort das Plug-in installiert werden. Das funktioniert aber reibungslos, und im Anschluss kann die Anwendung gestartet werden. Wir sehen eine Seite, auf der wir unseren Namen eintragen und an den Server schicken können. Ist man an diesem Punkt angelangt, sind es nur noch ein paar Schritte zur GXT-Anwendung. Im Grunde ist dazu lediglich das Einbinden der Sencha-Bibliothek in das Projekt notwendig. Dazu lädt man GXT (in der 30-Day-Evaluation-Version) herunter und fügt die JAR dem Projekt und dem Build Path hinzu. Ein paar Anpassungen der xml-Modulkonfigurationsdatei sind noch notwendig. Diese legt den Namen der Applikation fest und bindet einige Module ein, die für die Ausführung und Darstellung notwendig sind. Außerdem wird dort der Startpunkt des GWT-Moduls festgelegt (Listing 1).

Listing 1
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit 2.6.0//EN"
  "http://google-web-toolkit.googlecode.com/svn/tags/2.6.0/distro-source/core/src/gwt-module.dtd">
<module rename-to='sicherheitsunterweisung'>

  <!-- inherit core GWT Toolkit stuff -->
  <inherits name='com.google.gwt.user.User'/>
  <!-- inherit GXT module -->
  <inherits name='com.sencha.gxt.ui.GXT' />
  <!-- set up gwt theme -->
  <inherits name='com.google.gwt.user.theme.standard.Standard'/>
  <!-- set up GXT default stylesheet -->
  <stylesheet src="reset.css" />
  
  <!-- set up application entry point -->
  <entry-point class='de.herrmann.beispiel.client.Sicherheitsunterweisung'/>

  <!-- Specify the paths for translatable code -->
  <source path='client'/>
  <source path='shared'/>
</module>

Im Beispiel der Anleitung von Sencha wird das aktuelle Theme „Neptun“ referenziert. Das ist standardmäßig nicht verfügbar und führt zu einem Fehler beim Starten des Servers (im Development Mode bzw. beim GWT Compile). Daher verwenden wir das Standard-Theme von GWT.

Nun soll die Anwendung umgebaut werden, sodass die Felder für die Sicherheitsunterweisung angezeigt werden. Natürlich möchte ich dafür GXT-Komponenten verwenden. Das ist denkbar einfach: Nachdem die gxt.jar im Build Path eingebunden ist, können die GXT- genauso wie die GWT-Komponenten verwendet werden. Die Elemente der Seite werden in der Methode onModuleLoad() der Startklasse festgelegt. Dort implementiere ich beispielsweise das Textfeld mit Beschriftung und füge es der (ebenfalls leicht angepassten) HTML-Seite hinzu (Listing 2).

Listing 2
LabelToolItem nameLabel = new LabelToolItem("Name:");
final com.sencha.gxt.widget.core.client.form.TextField nameField = 
  new com.sencha.gxt.widget.core.client.form.TextField();

RootPanel.get("nameLabel").add(nameLabel);
RootPanel.get("nameField").add(nameField);

Angenehmerweise liefert die Beispielanwendung von GXT bereits sowohl eine Feldvalidierung auf Clientseite (FieldVerifier) als auch die Implementierung eines RPCs (GreetingService) mit. Auf die Implementierung des RPCs soll hier nicht näher eingegangen werden; die benötigten Klassen (Interface, Stub und Implementierung) sind für den GreetingService schon implementiert (vgl. auch Abb. 3). Die Datumsprüfung (kein zukünftiges Datum erlaubt) soll aus Gründen der Performance im Client ablaufen, für die Bestätigung der Unterweisung ist der Aufruf des Service nötig. Der Button für das Abschicken der Bestätigung erhält einen DomHandler, mit dem das ClickEvent abgefangen wird. Dann kann clientseitig die Prüfung stattfinden (Listing 3).

Listing 3
sendButton.addDomHandler(new ClickHandler() {
  public void onClick(ClickEvent event) {
    String dateString = dateField.getCell().getText(dateField.getElement());
    boolean dateOK = FieldVerifier.isValidDate(dateString);
    if (!dateOK) {
      MessageBox msgBox = new MessageBox("Fehler");
      msgBox.setMessage("Das Datum darf nicht in der Zukunft liegen.");
      msgBox.show();
      return;
    }
  }
}

Falls kein Fehler auftritt, wird der RPC durchgeführt (Listing 4). Die Umbenennung von Service und Methode erspare ich mir und belasse es bei den Default-Namen greetServer im GreetingService.

Listing 4
String textToServer = nameField.getText();
greetingService.greetServer(textToServer, new AsyncCallback() {
    public void onFailure(Throwable caught) { }

        public void onSuccess(String result) {
          MessageBox msgBox = new MessageBox("Sicherheitsunterweisung", result);
          msgBox.show();
        }
});

Auf der Serverseite (GreetingServiceImpl) kann jetzt die Bestätigung beispielsweise in eine Datenbank geschrieben werden. Als Ergebnis liefere ich lediglich einen „Vielen Dank“-Text zurück. Starten wir jetzt das Programm, so bekommen wir eine fertige Seite zur Ansicht (Abb. 5).

Abb. 5: So sieht die fertige Anwendung mit GXT aus

Abb. 5: So sieht die fertige Anwendung mit GXT aus

Bei Klick auf den Button Abschicken wird zunächst das Datum überprüft und im Fehlerfall eine Meldung ausgegeben. Ist das Datum gültig, wird ein RPC durchgeführt und – sofern kein Fehler aufgetreten ist – der „Vielen Dank“-Text ausgegeben.

Sicherheit auch mit Vaadin

Wie steht es mit Vaadin? Ich beginne den Versuch mit einem „frischen“ Eclipse. Ausgangspunkt für die Demoanwendung ist Kapitel 2 des „Book of Vaadin“, das auch in einer sehr handlichen gedruckten Ausgabe erhältlich ist. Das Buch soll eine „full reference for Vaadin“ darstellen, und diesen Eindruck macht es in der Tat. Tatsächlich ist man bei Vaadin – zu Recht – stolz auf den Stand der Dokumentation, wie Ville Ingman, Vaadin Advocate, auf der W-JAX 2014 sagte.

Mit Eclipse habe ich intuitiv eine gute Auswahl getroffen: Im einleitenden Kapitel wird erläutert, dass Vaadin speziell diese IDE unterstützt. Es gibt aber auch Communitysupport für NetBeans und IntelliJ IDEA. Die empfohlene „Tool Chain“ von Vaadin ist:

  • Windows, Linux oder Mac OS X
  • Sun Java 2 Standard Edition (JDK 1.6 oder höher)
  • Eclipse IDE für Java EE developers
  • Apache Tomcat 7.0 (Core)
  • Mozilla Firefox Browser
  • Optional: Firebug Debug Tool
  • Vaadin Framework

Damit liege ich gut im Rennen: Windows, Java, Eclipse und Firefox sind bereits auf meinem System. Tomcat 7 richte ich mir ebenfalls noch ein. Firebug installiere ich für diesen einfachen Test nicht.

In Kapitel 2.4 des Book of Vaadin ist die Installation des Vaadin-Plug-ins für Eclipse beschrieben. Voraussetzung dafür ist zunächst die Installation des IvyDE-Plug-ins. Das funktioniert fehlerfrei, sodass sofort mit der Installation des Vaadin-Plug-ins fortgefahren werden kann. Nach dem obligatorischen Neustart von Eclipse kann mit der Anlage eines neuen Vaadin-Projekts begonnen werden. Hier stoße ich auf das erste Problem: Laut Screenshot soll als „Target Runtime“ der Apache Tomcat auswählt werden, der aber noch gar nicht eingerichtet wurde. Hier hilft erst einmal nur der Abbruch (weil über die Option New Runtime… keine Serveradapter zur Auswahl stehen) und das Anlegen der Server Runtime über das Eclipse-Menü (Window | Preferences | Server | Runtime Environments). Jetzt kann ich den New Project Wizard erneut bemühen. Ich durchlaufe alle Schritte wie im Book of Vaadin angegeben, ändere dabei nur Projekt- und Package-Namen. Leider erhalte ich nach dem letzten Schritt eine Fehlermeldung (Abb. 6).

Abb. 6: Kein Erfolg mit Eclipse Luna und der letzten stabilen Version des Ivy-Plug-ins

Abb. 6: Kein Erfolg mit Eclipse Luna und der letzten stabilen Version des Ivy-Plug-ins

Die Fehlermeldung ist eine Folge daraus, dass keine gültige ivy.xml erstellt werden konnte. Dadurch können die notwendigen Abhängigkeiten nicht aufgelöst werden, und es werden auch keine Vaadin-Bibliotheken in das Projekt eingebunden. Jetzt ist guter Rat teuer. Verschiedene Konfigurationen beim Anlegen des Projekts liefern immer diese Fehlermeldung. In einem Forumseintrag von Vaadin werde ich fündig. Hier wird vorgeschlagen, das Ivy-Plug-in mit dem letzten erfolgreichen Build zu aktualisieren. Das funktioniert nur teilweise: Zwei der drei Items lassen sich updaten. Nach der Installation versuche ich eine erneute Anlage des Projekts – und siehe da: Die Fehlermeldung erscheint nicht mehr; das Projekt wird angelegt, und nach kurzer Zeit, in der Ivy die abhängigen Bibliotheken herunterlädt, steht es fehlerfrei im Workspace zur Verfügung (Abb. 7).

Abb. 7: Projektstruktur bei Vaadin

Abb. 7: Projektstruktur bei Vaadin

Nachdem ich beim Einrichten des Servers das Projekt bereits verknüpft habe, steht mir die Anwendung nach Serverstart schon unter http://localhost:8080/sicherheitsunterweisung zur Verfügung.

Jetzt möchte ich die Seite anpassen und den Button durch die gewünschten Eingabefelder ersetzen. Die Implementierung ist hier – wie bei GXT – recht einfach: Auch die Widgets von Vaadin können analog der Komponenten von GWT verwendet werden. Ich füge also die Überschrift, ein Textfeld, ein Datumsfeld und einen Button in die Seite ein (Listing 5). Die erste Methode, die bei einer Vaadin-Anwendung ausgeführt wird, ist die Methode init(), sodass ich dort das Layout zusammenbaue.

Listing 5
@Override
protected void init(VaadinRequest request) {

      final VerticalLayout layout = new VerticalLayout();
    layout.setMargin(true);
    setContent(layout);

    // Überschrift
    Label label = new Label("Sicherheitsunterweisung");
    label.addStyleName("header-style");
    layout.addComponent(label);

    // Textfeld
        HorizontalLayout hl = new HorizontalLayout();
    hl.setSpacing(true);
    layout.addComponent(hl);
    FormLayout fl = new FormLayout();
    final TextField nameField = new TextField("Name:");
    fl.addComponent(nameField);

    // Datumsfeld
    final DateField dateField = new DateField("Erfassungsdatum:");
    fl.addComponent(dateField);
    hl.addComponent(fl);

    layout.addComponent(new HorizontalLayout());

    // Abschicken-Button
    Button send = new Button("Abschicken");
    send.addClickListener(new Button.ClickListener() {
      public void buttonClick(ClickEvent event) {

        if (!validDate(dateField.getValue()))
          Notification.show("Das Datum darf nicht in der Zukunft liegen.");
            else
          Notification.show("Vielen Dank für die Bestätigung, " + nameField.getValue());
           }
  });
  layout.addComponent(send);
}

Aufgrund der Architektur von Vaadin wird der Buttonklick nicht schon im Browser behandelt, sondern direkt auf dem Server. Es wird also für jedes Event ein RPC durchgeführt. Das hat Vorteile: So steht dem Entwickler dann die komplette Java-Funktionalität zur Verfügung (der GWT-Compiler lässt nur eine beschränkte Auswahl für den Clientcode zu). Das Programm muss außerdem nicht durch den GWT-Compiler laufen; Debuggen im Dev-Mode von GWT ist nicht notwendig, da ausschließlich auf Serverseite entwickelt wird. Es hat aber auch Nachteile: Die Implementierung eines effektiven Event Handlings, z. B. auf Tastendruck in einem Textfeld, ist so nicht möglich (bzw. sinnvoll), da zu viele RPCs durchgeführt würden. Falls das gewünscht ist, ist es aber auch in Vaadin möglich, eigene Komponenten zu erstellen und das Event Handling in den Browser zu verlegen. Aus Platzgründen gehe ich hier nicht näher darauf ein; die clientseitige Entwicklung in Vaadin ist in Kapitel 13 des Book of Vaadin beschrieben. Nach erneutem Starten des Servers sehe ich die Anwendung im „Vaadin Style“ (Abb. 8).

Abb. 8: Ein frisches Gesicht: die Anwendung mit Vaadin

Abb. 8: Ein frisches Gesicht: die Anwendung mit Vaadin

Die Komponenten machen einen etwas moderneren Eindruck als bei GXT. Allerdings gibt es auch dort noch weitere Themes, die ich hier nicht näher betrachtet habe.

Zusammenfassung und Fazit

Sowohl mit Vaadin als auch mit GXT kann man leistungsstarke Webapplikationen bauen. Bei GXT liegt der Schwerpunkt mehr auf der Cliententwicklung; das Ziel bei Vaadin ist, keine eigenen Widgets bauen zu müssen. Weil das aber durchaus manchmal gewünscht ist, gibt es auch hier die Möglichkeit, das zu tun und ein eigenes „Widget Set“ zu erzeugen.

Im Praxistest tauchten (in der gewählten Konstellation der technischen Komponenten) bei beiden Frameworks Probleme auf. Diese lagen allerdings bei beiden nicht an den Komponenten der Unternehmen selbst: Bei GXT gab es Schwierigkeiten mit dem Debuggen im Dev Mode – nicht für alle Browser sind die richtigen Plug-ins verfügbar. Abhilfe könnte der neu entstandene Super Dev Mode schaffen. Bei Vaadin hatte ich besonders Schwierigkeiten bei der Anlage von neuen Projekten und der damit verbundenen Auflösung der Abhängigkeiten über Ivy. Hier war das Ivy-Plug-in für meine Eclipse-Version nicht richtig lauffähig; die Lösung lieferte ein Update des Plug-ins auf die aktuellste (Entwicklungs-)Version (2.5.0.alpha).

Weil nicht alle denkbaren GUI-Komponenten im Kern von Vaadin enthalten sein können, gibt es zahlreiche Add-ons, die von der Community entwickelt werden und auf der Homepage zum Download bereitstehen. Die Community ist bei Vaadin sehr aktiv und erweitert damit die Kernfunktionalität von Vaadin. Dem kommt das gewählte Lizenzmodell entgegen: Vaadin ist Open Source unter der Apache-2.0-Lizenz verfügbar. Sencha GXT ist lediglich für Open-Source-Projekte kostenfrei (GPLv3-Lizenz), für Unternehmensanwendungen ist eine separate Lizenz erforderlich. Diese enthält neben der Anwendung auch den Premiumsupport und kostet im ersten Jahr 4 635 US-Dollar (für bis zu fünf Entwickler).

Vaadin selbst bietet eine Seite im Internet, auf der die verschiedenen Webframeworks verglichen werden können, allerdings steht von Sencha hier nur die ältere Version Ext GWT 2.2.5 zur Auswahl. Benutzerzahlen kann man – insbesondere bei einem Open-Source-Projekt – nur sehr schwer ermitteln. Ein Indikator für die Nutzung ist hier mit der Anzahl der Einträge im Supportforum gegeben: Gibt es bei Vaadin ca. 1 600, sind es bei GXT nur knapp 400.

Im optischen Vergleich liegt meiner Meinung nach Vaadin vor GXT. Das gilt aber nur für die Standard-Themes. Bei beiden Frameworks kann man das komplette Theme austauschen oder den Stil einzelner Komponenten ändern.

Die Wahl des richtigen Frameworks hängt letztlich immer von den gegebenen Voraussetzungen ab: Sollen überwiegend eigene Komponenten entwickelt werden und soll möglichst viel Funktionalität im Browser ablaufen, bietet sich Sencha GXT an. Liegt der Schwerpunkt auf schneller und konsistenter serverseitiger Entwicklung mit einem Open-Source-Framework, ist Vaadin die richtige Wahl.

Aufmacherbild: red steel framework building via Shutterstock.com / Urheberrecht: Adam Vilimek

Geschrieben von
Holger Herrmann
Holger Herrmann
Holger Herrmann beschäftigt sich seit über zehn Jahren mit Java, seit einigen Jahren mit Schwerpunkt auf Technologien bei Webanwendungen. Seit 2011 arbeitet er als Entwickler und Softwarearchitekt bei Rödl&Partner.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: