Ich hatte in einem der letzten Beiträge eine Umfrage gestartet, um herauszufinden, welche Frameworks gerade wie intensiv eingesetzt werden. Natürlich ist das Ergebnis der Umfrage nicht mehr als ein Indiz, entspricht aber meinen Erwartungen.

Die erste Schwierigkeit, auf die man bei jedem Framework stößt, ist die Frage, ob es das Richtige für die Problemstellung ist. Dabei spielen natürlich verschiedene nicht technische Aspekte eine Rolle, die in die Entscheidung mit einfließen sollten. Anbei eine kleine Auswahl von Kriterien, die man in die Entscheidung einfließen lassen sollte:

• Ist das neue Framework eine Erweiterung meines Portfolios und sind mittel- und langfristig Synergieeffekte zu erwarten?
• Ist das neue Framework ein Ersatz für ein anderes im Einsatz befindliches Framework und wie kann eine Migrationsstrategie aussehen?
• Mit wieviel neuem muss ich mich beschäftigen? Wie steil ist die Lernkurve?
• Gibt es gute Dokumentationen (Bücher, Wiki, gut lesbarer Quelltext, etc.)?
• Ist zu erwarten, dass die Verbreitung dieses Frameworks eher zu- oder abnimmt?

Das letzten Fragen befassen sich nur mit einem Ausschnitt der Problematik und sind doch schon für sich genommen recht komplex. Diese Fragen kann man allerdings schwer für jemand anderen, sondern meist nur halbwegs gut für sich selbst und seinen Verantwortungsbereich beantworten. Deshalb beziehe ich mich in der folgenden Übersicht eher auf technische und organisatorische Aspekte, die aus den Erfahrungen im Umgang mit diesen Frameworks resultieren und daher natürlich subjektiv sind. Trotzdem glaube ich, dass die Einschätzung eine Hilfe für jeden sein kann, der sich mit den betreffenden Frameworks nicht beschäftigen konnte und sich trotzdem für eins einscheiden muss.

Grails

Grails ist ein an "Ruby on Rails" angelegtes Framework, was Groovy als Programmiersprache benutzt. Dinge die für Grails sprechen:

• Grails bringt alles mit, was man für eine Webanwendung braucht. Datenbank, Services, Präsentation, Ajax, etc.
• Es ist einfach, ausgehend von einer Datenbank mit Daten Anwendungen zu entwickeln, die diese Daten pflegen können.
• Die Java-Integration in Grails/Groovy ist sehr gut. Man kann als recht einfach auf bestehende Bibliotheken zurückgreifen.

Dinge die eher gegen Grails sprechen:

• Groovy ist eine dynamisch typisierte Sprache. Das hat Auswirkungen auf die IDE-Unterstützung und den Entwicklungsprozess.
• Grails benutzt für die verschiedenen Aspekte einer Anwendung etablierte Frameworks, die immer dann hervorscheinen, wenn man ein Problem hat und man sich dann nicht nur mit diesem Framework, sondern vor allem mit der Integration in Groovy beschäftigen muss.
• Grailsprojekte tendieren nicht zur Modularisierung. Ein nachträgliches Herauslösen von Funktionalität ist eher schwer.
• Wer auf eine gute Ajax-Unterstützung baut, der sollte wissen, dass Grails per Ajax nur einen Block auf der Seite aktualisieren kann. Es gibt Lösungen, die dieses Limit umgehen. Allerdings ist es überraschend, dass diese Lösungen es bisher nicht in den Grails-Kern geschafft haben.

Wer mit Grails Anwendung entwickeln möchte, der kann im Moment eigentlich nur auf IDEA und Netbeans als Entwicklungsumgebung zurückgreifen. Mit Grails lassen sich vor allem Probleme gut lösen, die genau in die Grails-Vorgehensweise passen: Datenbank anlegen, Tabellen definieren, Eingabemasken für den Datenzugriff generieren, eigene Ansichten mit eigenen Abfragen erstellen. Das ganze mit ein wenig Ajax würzen. Fertig.

Werden die Anwendungen in der Darstellung komplex, fängt es an, auch in Grails komplexer zu werden (und unterscheidet sich damit nicht von Ruby on Rails). Wenn der Fokus der Entwicklung eher in der Präsentationsschicht liegt, kann sich ein Framework lohnen, dass da seine Stärken hat. Grails ist IMHO vergleichbar mit einem etwas besseren Ansatz als Java Server Pages.

Ein in meinen Augen wichtiger Aspekt ist die fehlende Typsicherheit. Das bedeutet, dass nicht nur der letztmögliche Zeitpunkt, sondern oft auch der frühestmögliche Zeitpunkt, an dem ein Fehler sichtbar wird, der ist, wenn die Anwendung gestartet wurde und die fehlerhafte Funktion das erste mal aufgerufen wird. Dieser Fehler ist dann leicht zu beheben, weil es im Gegensatz zu anderen eher Java-basierten Frameworks keinen Server-Neustart nach sich zieht (meist nicht). Um solche Fehler in den Griff zu bekommen, müsste man dann aber entsprechende Unit-Tests erstellen. Wenn man der Argumentation von Robert Martin folgt, dann ist dieser Ansatz (dem auch jede PHP-Anwendung folgt) nicht mit TDD vereinbar, noch Clean Code ist.

Man kann Grails nutzen, man muss nur wissen, worauf man sich einlässt.

GWT

Im Gegensatz zu Grails benutzt GWT Java als Programmiersprache. GWT unterscheidet sich von allen anderen Frameworks dadurch, dass der Schwerpunkt der Entwicklung von GWT-Anwendungen darin liegt, einen wesentlichen Anteil der Anwendung per Javascript im Browser des Anwenders laufen zu lassen. Wenn man in Grails eine Liste neu sortiert hat, konnte man dieses Ergebnis per Ajax auf der Seite ersetzen lassen. Bei GWT ist es möglich, diese Liste nur im Browser neu zu sortieren, ohne das dadurch eine Verbindung zum Server aufgebaut werden müsste. Man kann komplexe Anwendungen schreiben, die vollständig im Browser laufen und keinerlei Verbindung zum Server aufbauen müssen. Man könnte die selbe Anwendung direkt in Javascript entwickeln.

Da Google GWT für eigenen Anwendungen nutzt, ist der Ansatz, den Google damit verfolgt, recht offensichtlich. Alles, was nicht auf dem Server, sondern im Browser des Users ausgeführt wird, belastet die eigenen Server nicht. Wenn man Probleme dieser Kategorie erwartet, könnte GWT eine Lösung sein. Allerdings bedeutet das, dass der Nutzer ohne aktiviertes Javascript überhaupt nichts zu sehen bekommt.

Anwendungen, die mit GWT entwickelt wurden, verhalten sich eher wie Flash-Anwendungen oder Applets, man kann sie auf beliebigen Seiten einbinden. Das bedeutet aber auch, dass eine Suchmaschine (auch Google in diesem Fall) nichts von der Anwendung sieht. Wer also Webanwendungen entwickeln möchte, die Inhalte auch für Suchmaschinen zur Verfügung stellen oder zu erwarten ist, dass Javascript deaktiviert sein könnte, sollte GWT nicht in Betracht ziehen.

Der GWT-Ansatz fordert natürlich Tribut. Der Entwicklungszyklus ist kompliziert, das der Javacode erst in Javascript kompiliert werden muss. Die Trennung in Client- und Servercode ist nicht ohne Weiteres nachvollziehbar. Die erste eigene Beispielanwendung ist mit Schmerzen verbunden und geht nicht leicht von der Hand.

Wer eher Desktop-orientierte Anwendungen entwickeln möchte, aber das Lastproblem, das man mit GWT lösen könnte, nicht für den anstehenden Themenkomplex als Problem identifiziert hat, der sollte sich vielleicht Vaadin ansehen. Der Unterschied zu GWT liegt im wesentlich einfacheren Entwicklungszyklus (der auf die Schmerzen verzichtet) und der bereits vorbereiteten Komponenten, die von Haus aus recht ansprechend aussehen. Vaadin benutzt GWT nur für die Darstellung und ist eher ein serverlastiges Framework. Die Vorteile, die GWT gerade im Lastbereich hat, werden durch Vaadin reduziert.

GWT eignet sich für Webanwendungen immer dann, wenn die Anwendung eher einen Service als Inhalte zur Verfügung stellt. Webanwendungen, die auf Inhalte setzen, die der Nutzer in Suchmaschinen findet und die Verlinkt werden können, eher auf andere Frameworks setzen.

Wicket

Wicket benutzt Java als Programmiersprache. Im Gegensatz zu JSF, Grails und Anderen, werden in den Html-Schnipseln, die für die Darstellung verantwortlich sind, kein Code benutzt. Alles wird mit Java realisiert. Das hört sich im ersten Moment wie ein Nachteil an, erweist sich spätestens bei Benutzung als Vorteil. Auf diese Weise kann man jede beliebige IDE einsetzen und von allen Möglichkeiten profitieren, die eine Entwicklungsumgebung in Bezug auf Java bereitstellt.

Wie bei GWT muss man sich bei allen anderen Aspekten einer Webanwendung mit der Auswahl der richtigen Frameworks beschäftigen und diese auf einander abstimmen. Allerdings kann man sich das ganze auch einfach machen und auf die selbe Frameworks wie Grails setzen. Einzig die Integration muss man selbst bewerkstelligen. Für Wicket gibt es eine gute Integration von Spring und damit Hibernate als Persistenzschicht.

Was Wicket fehlt (möchte man meinen), sind Komponenten, die bereits ein ansprechendes Layout mitbringen. Das ist allerdings auch nicht der Fokus von Wicket. Mit Wicket kann man von klassischen Web-1.0 Anwendungen bis zu Ajax-reichen Desktop-ähnlichen Anwendungen alles umsetzen. Die Komponentenarchitektur macht das ganze beherrschbar, die Anwendungen suchmaschinentauglich zu machen, ist ohne größere Aufwände (vor allen auch nachträglich) möglich.

Im Desktop-Bereich wird die Differenzierung jetzt etwas schwer: Wicket sollte man benutzen, wenn Suchmaschinenoptimierung ein Thema ist und die Anwendung auch ohne Ajax/Javascript funktionieren muss. Wenn man kein Lastproblem erwartet aber auf alle Fälle auf fertige, ansprechende Komponenten zurückgreifen möchte, benutzt man am besten Vaadin. Bei zu erwartenden Lastproblemen kann sich der Einsatz von GWT auszahlen.

Besonders bei Anwendungen die sich irgendwo zwischen Web-1.0 und Desktop befinden, oder einen großen Teil davon abdecken müssen, sollte man Wicket benutzten. Gerade in diesem Bereich kann Wicket seine Stärken ausspielen. Durch den OO-Ansatz von Wicket kann man jederzeit bestehende Komponenten umarbeiten, erweitern, vereinfachen oder aufteilen, so das man nach recht kurzer Zeit ein stabiles Grundgerüst an eigenen Komponenten besitzt, mit denen dann sehr schnell neue Entwicklungen realisiert werden können.

der Rest

Was ist mit den ganzen anderen Frameworks? Bisher konnte ich keine Punkte identifizieren, die nicht eins der erwähnten Frameworks nicht abbilden kann, so dass man auf dieses Framework weiterhin angewiesen ist. Da ich mir nicht alle Frameworks angesehen habe, fehlt natürlich das eine oder andere. In der folgenden Übersicht folgen meine Empfehlungen für eine Migration auf eines der auserwählten Frameworks:

• JSF: GWT, Vaadin oder Wicket
• Tapestry,Struts: Wicket
• PHP,JSP: Grails oder Wicket (je nachdem wie komplex da UI wird)

Schwere Entscheidung

Jetzt muss man sich nur noch entscheiden. Man sollte sich allerdings die Entscheidung nicht zu schwer machen, wenn man zwischen zwei geeigneten Kandidaten wählen muss. Es dient vielmehr dazu, ein besseres Fundament für die eigenen Entscheidung zu gießen. Wie oft ist man in den letzten Jahren einem Hype gefolgt, um dann feststellen zu müssen, dass es nicht das eine Framework gibt, dass alle Probleme lösen kann. Im Zweifel fährt man besser, wenn man auch einmal "nein" sagt und bewusst auf ein Feature verzichtet.

Feedback

Rückmeldungen sind natürlich willkommen. Aspekte, die ich vergessen habe, pflege ich gern ein, ansonsten ist ja genug Platz in den Kommentaren, um die eigene Sichtweise und Erfahrung darzulegen.

Als ich mit Wicket angefangen habe, hatte ich schon mit verschiedenen anderen Technologien gearbeitet. Ich war also keine Neueinsteiger sondern hatte bereits einige Erfahrungen hinter mir. In dieser Situation entstehen automatisch Fragestellungen, die sich damit beschäftigen, wie man bekannte Probleme neu mit Wicket lösen würde und wie diese Lösungen im Vergleich zu den bestehenden Altlösungen zu bewerten sind.

Er größte Fehler, den man bei einem Wechsel zu Wicket (und vermutlich bei jedem Wechsel einer Technologie) macht, besteht darin, das man versucht ein altes Problem mit neuer Technik auf alte Weise zu lösen. Das kann nicht funktionieren.

Beispiel

Wenn man Webanwendungen mit JSF, JSP, Struts oder anderen Frameworks entwickelt, tendiert man dazu, dass der Anwendungszustand zu einem wesentlichen Teil über Seitenparameter transportiert wird. Das hat verschiedene Ursachen (z.B. Suchmaschinenoptimierung, Seitenpufferung). Seiten, die besonders häufig abgerufen wurden, sollten gepuffert werden können. Das heißt, für eine bestimmte Url erhielt man immer den selben Inhalt. Es wurde teilweise ohne jede Nutzersession gearbeitet.

Diese Anforderung ist mit Wicket lösbar, aber der falsche Weg. Zu behaupten, es ginge mit Wicket spontan ganz einfach, ist aber ebenso falsch. Doch der Weg zu einer guten Lösung ist nicht weit. Als aller erstes musste ich mich davon verabschieden, dass eine Wicketseite (die auch Ajax verwendet) gepuffert werden kann. Wenn das Erstellen von Teilen der Seite zu zeitaufwendig ist, muss man durch das Puffern von Ergebnissen dem ganzen entgegenwirken. Aber im Unterschied zur alten Lösung wird nicht mehr die ganze Seite, sondern nur noch die Daten der nötigen Teilergebnisse gepuffert. Das ist auch sehr viele Arten sehr viel geschickter.

Ausblick

Dieses erste Beispiel veranschaulicht sehr gut, warum es gut ist, sich gerade auch mit den Grundlagen von Wicket zu beschäftigen. Ich den nächsten Artikeln werde ich weitere Beispiele erläutern und aufzeigen, wie man von der alten Lösung für ein Problem zu einer neuen Lösung mit Wicket kommt.

Wer möchte, kann mir seine Fragestellung zukommen lassen. Ich kann diese Fragestellungen dann in die Artikel einfließen lassen.