Ich wünsche allen ein gesundes neues Jahr. 2009 hat sich verabschiedet und 2010 zeigt sich bereits jetzt von seiner besten Seite (wenn man Schnee mag). Ich freue mich auf die vielen spannenden Themen, die das neue Jahr bereithält.

Auch wenn es anders kommt, als man sich denkt, wage ich hier doch mal ein paar Vorhersagen. Manches davon ist offensichtlich und wird vermutlich schon deshalb nicht eintreten, Anderes ist frei erfunden und hat damit die besten Chancen, zum Volltreffer zu werden.

Nachdem 2009 eigentlich ein Scala-Jahr war, wird es auch 2010 in diesem Bereich interessant bleiben. Zu meiner Überraschung konnte allerdings auch Java durch den Scala-Hype profitieren. Einige fühlten sich wohl durch die Möglichkeiten von Scala entsprechend angestachelt, dass selbst für Dinge wie Scala Traits Implementierungen (z.B. java-mixins) für Java geschrieben wurden. Java ist zwar etwas angestaubt aber eben noch nicht tot. Und was Google mit GWT und Android alles auf Basis von Java anstellt, zeigt deutlich, dass da noch Platz für Innovationen ist. Das bedeutet, dass es auch 2010 nicht verkehrt ist, auf Java zu setzen.

Nachdem JSF 2.0 wie zu erwarten war, nicht alle Probleme, die JSF bis jetzt angesammelt hat, lösen wird, gehe ich davon aus, dass wie schon 2009 immer mehr Projekte auch mit Wicket realisiert werden. Da Wicket als Basis schon sehr ausgereift ist, wird sich der Zustrom an Entwicklern vermutlich eher auf Integrationsthemen auswirken: Web-Worker, Javascript-Frameworks und andere noch unbekannte Entwicklungen. Ich erwarte außerdem (unabhängig von meinem eigenen Teilprojekt auf wicketstuff.org) ein paar Standardvorlagen für Wicket-Projekte.

Nachdem Groovy in der neuesten Version alle Sprachfeatures hat, die für eine saubere Wicket-Integration notwendig sind, wird es auch in diesem Bereich interessant. Die Bedenken, die ich trage, richten sich vielmehr an die Plattform Groovy/Grails an sich. Es gibt Entwicklungen, die bei mir Bauchschmerzen hervorrufen (Grape - Dependency Management als Annotation auf einem Import - WTF)), die merkwürdig sind und auf die Frage "Warum?" vermutlich nur mit einem "Weil es geht." beantwortet werden.

Alles in Allem, es bleibt und wird spannend. Ich wünsche allen (unabhängig von der technologischen Präferenz) ein gutes und erfolgreiches Jahr.

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.

Wicket 1.4 nähert sich der Fertigstellung. Das ist ein gutes Zeichen, auch wenn ich Wicket 1.4-rc2 bereits längere Zeit ohne Probleme produktiv einsetze. Dieses Jahr wird ein Wicket-Jahr, denn so langsam beschäftigen sich immer mehr Entwickler mit dem Framework. Außerdem erscheinen in diesem Jahr einige Bücher rund um Wicket, so dass man gespannt sein darf, welche Auswirkung aktuelle Literatur zu diesem Thema haben wird.

Für mich steht diese Jahr auch im Zeichen von Scala. Die IDE-Unterstützung verbessert sich zunehmen, so dass man jetzt schon wieder zwischen Eclipse und Netbeans wählen kann. Wenn man dann Scala mit Wicket kombiniert, könnte man bei der Umsetzungsgeschwindigkeit auch Frameworks wie Grails den Platz auch gerade bei einfachen Projekten streitig machen. Das Wicket gerade bei komplexen Projekten punktet hat sich zwar auch noch nicht überall herumgesprochen, aber je mehr Anwendungen mit Wicket realisiert werden, desto schwieriger kann man diese Entwicklung ignorieren.

Damit bleiben für mich zwei Technologien übrig, mit denen man sinnvoll Java-basierte Webanwendungen entwickeln kann: GWT und Wicket. Für alle anderen Frameworks gibt es eigentlich keine Berechtigung, weil es keine guten Gründe mehr gibt, die für deren Einsatz sprechen. Wer andere Meinung ist, kann sich ja in einem Kommentar beschweren.

Am Ende des Jahres werden wir sehen, wie dicht ich dran lag:)