Durch die “Erfindung” von AJAX vor rund 10 Jahren haben WebFrameworks seit dem einen regelrechten Boom erlebt. Auch bei den Java WebFrameworks hat der Klassiker JSF mit Erweiterungen wie IceFaces, RichFaces oder PrimeFaces starke Konkurrenz bekommen, die man durchaus ernst nehmen kann und sollte.
Gerade Frameworks die sich die etablierten AJAX-Bibliotheken (jQuery, YUI) zu Nutze machen, schaffen mit recht wenig Aufwand ansehnliche Web 2.0 Anwendungen, die auf ein reichhaltiges Angebot an Widgets zurückgreifen können.
Allerdings verfolgen die Frameworks teils sehr unterschiedliche Ansätze, was die Auswahl eines passenden Frameworks für die umzusetzenden Anforderungen unter Umständen aufwändig werden lässt.
Zwei der wichtigsten Fragen, die man sich in diesem Zusammenhang stellen sollte, sind die folgenden.
Klassische Webanwendung oder “Rich Internet Application”?
Die Trennung der beiden Begriffe ist nicht scharf definiert, lässt sich aber verständlich umschreiben.
Klassiche Webanwendungen lassen sich bereits mit JSP/Servlet oder komfortabler mit Standard-JSF implementieren. Die Anwendung ist seitenbasiert, es wird hauptsächlich klassisches HTML Markup genutzt und der Nutzer kann über POST/GET Requests bzw. über Links Aktionen ausführen und zwischen den Seiten navigieren.
Im Vergleich dazu sind Rich Internet Applications der Versuch, desktopähnliche Anwendungen in den Browser zu bringen. Merkmale hier sind die meist einseitige, dialogbasierte Oberfläche und die Nutzung typischer aus dem Desktopbereich bekannten Funktionen wie Tastenkürzel, Drag&Drop, Menüleisten und Kontextmenüs, sowie eine Auswahl fertiger Widget wie Tabellen, TreeView etc. und vordergründig die Nutzung asynchroner AJAX-Requests in Richtung Server.
Client- oder serverzentrisch?
Hauptsächlich bei den Rich Internet Applications stellt sich dann vereinfacht noch die Frage, wo die Anwendung ausgeführt wird. Auf dem Client (also im Browser), oder auf dem Server.
Clientzentrische Anwendungen sind meist komplett in JavaScript implementiert, welches beim Laden der Seite vollständig auf den Client übertragen wird. Dort kümmert sich das Framework nun eigenständig um das Rendern der HTML Inhalte und das Eventhandling für den Benutzer. Eine Interaktion mit dem Server findet nur noch dann statt, wenn weitere Daten nachgeladen werden müssen. Üblicherweise werden diese dann per JSON oder XML an den Client übertragen und dort erst gerendert.
Clientzentrische Frameworks sind z.B.: Google GWT (mit Erweiterungen wie ExtGWT und SmartGWT)
Das Gegenteil, die serverzentrischen Frameworks, belassen das Rendern der Inhalte und das Eventhandling auf dem Server. Jede Aktion im Client löst damit einen Request auf dem Server aus, der wiederum (im Idealfall) gerendertes HTML als Antwort zurückliefert. Clientseitiges JavaScript dient hier im wesentlichen nur der asynchronen Kommunikation.
Serverzentrische Frameworks sind z.B.: Vaadin, ZK
Wie üblich lässt sich bei allen drei Ansätzen nicht pauschal “Der Beste” bestimmen. Vorteile und Nachteile lassen sich nur im Kontext der Anforderungen erörtern und sollen nicht Teil dieses Beitrags sein. Hier sei auf andere Quellen verwiesen.