"GWT - Das JSF wie wir es schon immer haben wollten" - Das ist zunächst einmal ein äußerst provokanter Titel, zumal ich mich persönlich im JSF-Umfeld sehr wohl fühle und keine allzu große Kritik daran habe.

Angestachelt durch diese These, habe ich mir den Vortrag von Papick G. Taboada angehört. Er ging zunächst auf die Grundlagen von Web 2.0 mit Ajax ein, bevor er die grundsätzlichen Konzepte von GWT vorstellte. Google hat hier einen komplett neuen Ansatz gewählt, um die Webentwicklung zu vereinfachen. Es werden keine JSP- oder Html-Seiten und auch keine JavaScript-Funktionen mehr selbst geschrieben, sondern ein 100 %-iges Java-Programm erstellt.

Dazu wird die API von GWT genutzt. Sie bietet die Funktionalität, im Java-Programm die Oberfläche zu entwickeln. Es verhält sich ähnlich wie eine GUI-Entwicklung mit AWT oder Swing. Im Anschluss an eine Programmierung in einer reinen Java-Umgebung kann das Programm auf sehr einfache Weise in Html und JavaScript transferiert werden. Dazu stellt GWT einen entsprechenden #-Transformator bereit.

Der Vorteil dieser Vorgehensweise liegt klar auf der Hand: Ich kann in meiner gewohnten IDE ein Java-Programm schreiben, dabei habe ich hilfreiche Features wie Code-Vervollständigung und ich kann debuggen und auch sonst alle Vorteile der klassischen Java-Programmierung nutzen. Anschließend wird durch GWT sichergestellt, dass voll funktionsfähiges Html und JavaScript entsteht. Ich muss mich nicht mehr mühsam durch Html- bzw. JSP-Seiten kämpfen oder an der JavaScript-Syntax verzweifeln. Dies ist durchaus ein Punkt, der mir gefällt. Ich kann in einer höheren API entwickeln, ohne in die Tiefen von Html und JavaScript hinabsteigen zu müssen. Hinsichtlich der UI-Komponenten gibt es aktuell schon einen recht großen Markt. Es stehen fertige Komponenten wie Datepicker, Listen, Spincontrols etc. zum freien Download zur Verfügung.

Um jedoch ehrlich zu sein: Ich finde die Ansätze von GWT durchaus interessant, allerdings bleibe ich doch bei meiner gewohnten JSF-Entwicklung. Ich befinde mich im Web und programmiere auch dort. Warum muss ich das zwanghaft zu verbergen versuchen? Auch bietet mir GWT meiner Meinung nach nicht wirklich neuartige Antworten auf Dinge, die ich in JSF nicht genauso gut lösen könnte (nur eben anders). Auch in JSF gibt es einen großen und sehr guten Komponentenmarkt, der mir die Details von Html und JavaScript versteckt.

Auch habe ich keine Antwort gefunden, warum ich von einem Standard wie JSF weggehen sollte, nur um eine proprietäre und nicht standardisierte API zu verwenden. Sicherlich ist Google mit seiner Marktstärke durchaus in der Lage, auch einen eigenen "Standard" in die Welt zu setzen, aber ich setze eher auf die im Java-Umfeld etablierten Standardisierungsprozesse wie den JCP (trotz aller Kritik an ihm).

Insgesamt denke ich daher, dass es keine generelle Entscheidung für JSF oder GWT geben kann. Papick hat die Konzepte und Ideen von GWT durchaus gut präsentiert und den Zuhörern einen hilfreichen Überblick gegeben. Eine Entscheidung, welches Framework man zukünftig nutzen möchte, muss jedoch jeder selbst treffen. Für mich war die Session sicherlich dahingegend hilfreich, um mehr über GWT zu erfahren. Aber auch, um für mich die Frage beantworten zu können, ob GWT wirklich das bessere JSF ist oder der Titel einfach nur etwas provokant gewählt wurde.

Andy Bosch ist unabhängiger Berater und Trainer für JavaServer Faces und Portlets. Er ist Autor verschiedener Fachbücher (JavaServer Faces, Portlets und JSF) sowie Betreiber der Plattformen www.jsf-forum.de und www.jsf-portlets.net. Zudem ist er Mitglied der Expertengruppe des JSR 301 (Portlet Bridge Specification for JavaServer Faces) und Mitglied in SENS.