Wie praxistauglich ist das Web-Framework?

JSF: Einer für alle, alle für einen? Kommentar zum ThoughtWorks Technology Radar

Lars Röwekamp, Arne Limburg
©shutterstock.com/Marish

In dem immer wieder empfehlenswerten Technology Radar der Firma ThoughtWorks, der verschiedenste Technologien ähnlich wie Aktien bewertet, konnte man vor kurzem lesen, dass das Java EE Web Framework JSF 2.0 von den Autoren auf „hold“ gesetzt wurde. Einhergehend mit dieser Bewertung erfolgte die Empfehlung JSF 2.0 für Webanwendungen zu vermeiden. Ist die Lage für JSF wirklich so kritisch oder fehlt der Betrachtung evtl. nur eine gewisse Differenzierung?

Um es gleich vorweg zu nehmen: Ja, wir – die beiden Autoren – sind bei einem Beratungs- und Entwicklungsunternehmen mit dem Schwerpunkt Java EE beschäftigt. Und ja, wir sind sicherlich nicht immer zu 100% objektiv wenn es um den Java-Enterprise-Standard geht. Trotzdem oder gerade deshalb geht es uns in diesem Artikel nicht darum, JSF gegen die Aussagen des Technologieradars zu verteidigen. Ganz im Gegenteil: auch wir sehen immer wieder Probleme bei unseren Kunden, wenn es um die Einführung von JSF geht. Wir sehen allerdings auch viele erfolgreiche JSF/Java-EE-Projekte, die wir in den vergangenen Jahren gemeinsam mit bzw. für unsere Kunden umgesetzt haben. Wir stellen uns daher die Frage, ob es sinnvoll ist, die „ Webanwendung“ zu verallgemeinern oder ob evtl. die Tauglichkeit von JSF etwas differenzierter betrachtet werden muss.

Was bisher geschah

ThoughtWorks führt in seiner Betrachtung von JSF einige Punkte auf, die in Summe zu der Empfehlung führen, JSF nicht in neuen Webprojekten zu verwenden. Nahezu alle genannten Punkte sind auch aus unserer Sicht valide und können somit eins zu eins unterschrieben werden. Hier noch einmal eine kurze Zusammenfassung:

Häufig wird JSF in Projekten verwendet, ohne es wirklich zu hinterfragen – schließlich handelt es sich ja um den Standard und der Standard ist immer gut. Der Kontext der Anwendung und die damit verbundenen Anforderungen an Business und Technologie werden dabei leider häufig außer Acht gelassen.

JSF (2.0) abstrahiert von HTTP, HTML und CSS und macht damit genau das Gegenteil von dem, was von einem modernen Web Framework erwartet wird. JSON wird gar nicht und AJAX nur rudimentär unterstützt. Stattdessen bietet das Framework ein eher aus der Desktop-Welt bekanntes Programmiermodell an, bei dem eine Anwendung aus Komponenten besteht (Buttons, Listen, Tabellen, Tabs, …), die Events auslösen können, auf die wiederum durch (Business-)Logik und Manipulation des Domänen-Modells reagiert werden kann.

Anwendungen, die auf JSF basieren, arbeiten mit einem Server-seitigem State. Dieser belastet zum einen das System und widerspricht zum anderen sowohl dem statuslosen HTTP als auch den aktuellen Trends à la REST, ROCA & Co..

Zwischen den Zeilen des Techradars kann der versierte Leser zusätzlich noch den Kritikpunkt finden, dass JSF – dank Lifecycle und Komponenten-Voodoo – für viele Entwickler einfach zu kompliziert ist, um mal eben schnell eine Webanwendungen ohne unerwartete Seiteneffekte zu entwickeln.

Die im Rahmen des Technologieradars genannten Punkte ließen sich aus unserer eigenen Erfahrung heraus noch um einige Punkte ergänzen. So gibt es wahrscheinlich nur wenige Frameworks im Java-EE-Umfeld, die so buggy sind, wie die beiden JSF-Implementierungen. Ein Einsatz von JSF ist somit in der Regel auch immer mit einigen Workarounds verbunden, ein Wechsel von A nach B ist nur sehr schwer realisierbar. Auch der gerne angepriesene Vorteil der 3rd-Party-Komponenten ist mit Vorsicht zu genießen. Je ausgereifter die Komponenten, desto höher ist – aufgrund interner Implementierungsdetails im Java- und CSS-/JavaScript-Umfeld – das Risiko ihrer Verwendung. Dies gilt insbesondere dann, wenn man diese Bibliotheken mit anderen kombinieren oder aber entsprechend der eigenen Anforderungen modifizieren möchte.

Soweit, so schlecht. Lohnt sich nach all den negativen Punkten überhaupt noch eine weitere Betrachtung? Oder anders gefragt: In welchen Szenarien könnte JSF evtl. doch seine Berechtigung haben – und in welchen mit Sicherheit nicht?

JSF.next()

ThoughtWorks legt bei seinen Betrachtungen JSF in der Version 2.0 und somit einen Stand von 2009 zu Grunde. Da sich die zugehörige Spezifikation mittlerweile allerdings in der Version 2.2 (JSR-344) befindet, stellt sich die berechtigte Frage, ob alle getroffenen Aussagen auch weiterhin bestand haben oder JSF mittlerweile – wenn auch relativ spät – die Zeichen der Zeit erkannt und eine entsprechende Evolution durchlaufen hat. Im Folgenden sollen daher kurz exemplarisch einige Punkte technologisch beleuchtet werden, bei denen die JSF Expert Group bewusst auf Feedback der Web Community reagiert hat und einige der genannten Kritikpunkte angegangen ist.

Dank neuer Namespaces können Anwendungen mittlerweile vollständig in HTML5, JavaScript und CSS3 umgesetzt und an den gewünschten stellen via jsf:xyz Attribute dynamisiert werden. Spezielle JSF-Tags sind nur noch in wenigen Ausnahmefällen notwendig. Richtig eingesetzt, kann so in Kombination mit dem JSF Ressource-Handling-Mechanismus eine optimale Trennung zwischen View/Layout und Controller-Logik – auf das Modell kommen wir später zu sprechen – erfolgen. Dies gilt sowohl für die normalen „Web Pages“ als auch für eigene Komponenten, die – umgesetzt als XHTML-basierte Composite Components – demselben Muster folgen.

Und auch der oben genannten Problematik „Stateful vs. Stateless“ wurde mit der neuen Stateless View zumindest technologisch Rechnung getragen. Wem es weniger um den State an sich, als vielmehr um die damit verbundene Performanz geht, der findet bereits seit JSF 2.0 in dem Delta bzw. Partial State Saving Mechanismus, sowie in dem durch Ajax-Calls einschränkbaren Execute- und Render-Komponentenzweig eine Lösung. Vergessen sollte man bei aller Euphorie für Stateless Web Application allerdings nicht, dass ich auch schon dann einen State generiere, sobald ich einen Cookie setze oder Informationen in der http-Session ablege – das aber nur am Rande.

Abstraktion als USP

Das JSF Framework abstrahiert, anders als die meisten Web Frameworks, seit jeher bewusst vom HTTP Request/Response Modell und setzt statt dessen – wie aus der Desktop-Welt bekannt –auf UI Komponenten, die Events auslösen. Dieser Ansatz macht sich insbesondere in klassischen Business-Anwendungen gut, in denen das fachliche Modell an die Oberfläche bzw. Oberflächenkomponenten gebunden wird und Änderungen an den Komponenten serverseitige Businesslogik auslösen sollen. Dank JSF-Lifecycle – den jeder JSF-Entwickler im Schlaf herunter beten können sollte – werden die Daten nur dann in das eigene Domänen-Modell übernommen und im Anschluss die angefragte Business-Logik ausgeführt, wenn alle Änderungen/Eingaben valide sind – eine automatische Konvertierung der String-basierten Webeingabe in passende Java-Typen inklusive. Andernfalls greift das eingebaute Error-Handling bis hin zur Fehlerdarstellung in der UI. Diese automatische, Server-seitige Datenkonvertierung und -validierung, die dank HTML5 und JSF Client Behavior auch um Client-seitige Validierung ergänzt werden kann, bildet inkl. der anschließenden Übernahme der Daten in das Domänen-Modell, sicherlich einen wesentlichen Vorteil von JSF gegenüber anderen Web Frameworks.

Innerhalb des Technologieradars als Kritikpunkt aufgeführt, stellt die oben beschriebene Abstraktion innerhalb von JSF einen seiner wesentlichen „Unique Selling Points“ dar. Und auch die Möglichkeit eine eigene – und die Betonung liegt hier auf eigene – unternehmensweit wiederverwendbare, mächtige Komponentenbibliothek zu implementieren, sollte nicht unterschätzt werden. Einmal entwickelt, können die Komponenten einen Großteil der Komplexität inkl. Business-Behavior – sowohl auf Seiten der Clients als auch auf dem Server – in einfach zu verwendenden JSF-Tags kapseln.

Als potentieller Anwender von JSF sollte man also für sich selbst und seinen Projektkontext hinterfragen, ob eben diese Abstraktion einem einen Mehrwert bringt oder eben nicht. Ein Mehrwert ist sicherlich immer dann gegeben, wenn ein eher Java-lastiges Team am Werk ist und es sich um eine hoch integrierte Business-Anwendung handelt. Ein Mehrwert ist zusätzlich immer dann gegeben, wenn (unternehmensweit) wiederverwendbare Komponenten herauskristallisiert werden können. Insbesondere der in JSF integrierte Validierungs-Mechanismus – direkt genutzt oder via BeanValidation API – kann helfen sicherzustellen, dass sich auf dem Server, von den UI-Controllern bis hin zur Datenbank, niemals ein invalides Domänen-Modell erzeugen lässt.

REST & ROCA-Style mit JSF?

Problematisch wird es bei dem oben genannten Ansatz leider immer dann, wenn auf dem Client ebenfalls ein Teil des Modells, z.B. in Form eines speziellen View-Modells vorliegt. Dieses dürfte in der Regel in JSON vorgehalten werden – eine Technologie, die von JSF leider nach wie vor sträflich vernachlässigt wird. Stattdessen gehen entweder ganze XHTML-Seiten oder XML-Fragmente über die Leitung. Möchte man also weniger View-Informationen als nahezu ausschließlich Daten zwischen dem Client und dem Server austauschen, ist JSF eher eine schlechte Wahl.

Der in JSF 2.0 hinzugekommene AJAX-Support ist zwar perfekt dafür geeignet, lediglich Teile des gesamten Komponentenbaums auszuführen (Execute-Phasen des JSF Lifecycles) und zu rendern (Render-Phase), um so z.B. die Inhalte einer Tabelle dynamisch via Lazy-Loading nachzuladen, der reine Austausch von Daten dagegen ist von der zugehörigen Ajax-JavaScript API leider nicht vorgesehen. Die einzige Chance reine (JSON-)Daten mit JSF Bordmitteln zwischen Client und Server auszutauschen ist eine Lösung auf Basis eines Hidden-Field, die zwar technologisch funktioniert, aber letztendlich nur einen Workaround für die mangelhafte Unterstützung innerhalb von JSF darstellt. Besser wäre es auf jeden Fall, für diesen Anwendungsfall auf ein entsprechendes JavaScript-Framework, wie AngularJS & Co. zurückzugreifen.

Natürlich spricht auch nichts gegen einen Hybrid-Ansatz, bei dem Teile der Anwendung über das JSF-Framework und andere Teile über JavaScript-basierte Varianten abgehandelt werden. Es sollte dabei aber immer auch bewusst das Risiko betrachtet werden, dass Client-seitiges und Server-seitiges Modell auseinander laufen können, was zu sehr unschönen Seiteneffekten führen kann. Eine doppelte Absicherung auf Seiten des Clients und des Servers ist entsprechend Pflicht.

Lernkurve

Eine Lösung wird immer nur so gut, wie das Team, das die Lösung umsetzt. Hier macht auch JSF keine Ausnahme. Dies gilt insbesondere vor dem Hintergrund, dass heutige Webentwicklung mit all den involvierten Technologien und deren Zusammenspiel sicherlich zu einer der komplexeren Herausforderungen im Bereich des Software Engineerings gehört.

Wir haben in unseren Projekten festgestellt, dass die initiale Hürde für JSF-Newbies relativ hoch ist. Dies liegt unserer Meinung nach allerdings weniger in der Technologie an sich begründet als vielmehr in der Herangehensweise vieler Teams. Häufig wird mit – sehr – gefährlichem Halbwissen gestartet. Dabei werden schnell erste Erfolge gefeiert und nicht gewünschte Seiteneffekte innerhalb der Webanwendung erst einmal ignoriert. Nicht selten wird dabei vernachlässigt, dass JSF ein sehr mächtiges Framework ist – im positiven wie im negativen Sinne. Ein nicht richtig verstandener Lifecycle, unsauber programmierte Komponenten oder ein schlecht implementiertes Domänen-Modell können zu Nebeneffekten führen, die man auf Dauer kaum noch in den Griff bekommt und so die Vorteile von JSF ad absurdum führen. Bei steigender Komplexität rächt sich diese „ad-hoc“ Herangehensweise dank Technologie-Mix und problematischem Debugging doppelt und dreifach. Nur wer seine Hausaufgaben macht, wird auch Erfolg haben.

Dies gilt allerdings nicht nur für JSF sondern für alle Technologien. Wir haben in diesem Kontext auch die Erfahrung gemacht, dass ein Java Entwickler noch lange kein Web Entwickler ist – vice versa. Für fancy Web UIs abgestellte Java Entwickler richten nicht selten erheblichen Schaden an. Client-seitiger State wird nicht sauber aufgebaut bzw. nicht richtig an den Server übergeben, JS-Frameworks werden genutzt ohne sie wirklich verstanden zu haben, Validierung nur halbherzig umgesetzt. In diesem Sinne ein kleiner Pro-Tipp: „Web/UI Entwicklung sollte ausschließlich durch qualifizierte Web/UI Entwickler, also Entwickler mit tiefen HTML5, JavaScript und CSS 3 Know-how erfolgen. Diese sind genau so wertvoll, wie jeder andere (Backend-)Entwickler auch!“. Es kann übrigens auch einem Java-Entwickler nicht schaden, ein wenig über den Tellerrand zu blicken und zu versuchen die „Wunderwelt Web“ besser zu verstehen.

Fazit

JSF – ja oder nein? Wie so oft lautet auch bei dieser Frage die Antwort: „es kommt darauf an!“. Sicherlich macht es keinen Sinn JSF nur deshalb zu wählen, weil es „zufällig“ Bestand der Java EE Spezifikation ist. Gleichzeitig macht es aber auch keinen Sinn, JSF per se als nicht mehr „state-of-the-art“ abzulehnen. Die eigentliche Frage, die man sich stellen sollte, ist die nach dem eigenen Projektkontext und – aufgepasst, denn an diesem Punkt scheitern nicht wenige Projekte! – nach dem vorhanden oder realistisch im Rahmen des Projektes aufbaubaren Team. Möchte man eine klassische Business-Anwendung mit starkem Integrationscharakter entwickeln – zum Beispiel im Rahmen einer Migration einer bestehenden Fat-Client oder Desktop-Anwendung – ist JSF 2.x aus unserer Sicht sicherlich eine gute Wahl. Dass diese Anwendung dann durchaus auch mit einer „fancy“ UI aufwarten und auf HTML5 / CSS3 inkl. JavaScript-Bibliotheken basieren soll ist kein Widerspruch – ganz im Gegenteil. Vorausgesetzt man nimmt sich als Team ausreichend Zeit wiederverwendbare (UI-)Komponenten zu definieren bzw. zu implementieren, um so die aufkommende Komplexität der vielen verschiedenen Technologien sinnvoll zu kapseln.

Möchte man dagegen einen zum größten Teil datenzentrierten Ansatz fahren, bei dem im Rahmen einer Single Page Application vornehmlich JSON-Daten zwischen Client und Server ausgetauscht werden und der State maßgeblich auf dem Client aufgebaut und gehalten wird, ist JSF aus unserer Sicht eher ungeeignet. Hier bietet sich statt dessen ein rein JavaScript basiertes Framework, wie z.B. jQuery bzw. darauf aufbauende JS-Frameworks zur Dom-Manipulation inkl. eigener Erweiterungen zur Umsetzung des Clients an – entsprechende Entwickler mit Fachwissen vorausgesetzt. Noch besser eignen sich JavaScript Web-Frameworks mit einem höheren Abstraktionsgrad, wie zum Beispiel AngularJS, BackBone oder Knockout. Man sollte bei der Verwendung eines JavaScript-basierten Frameworks allerdings nicht vergessen, dass sich in diesem Umfeld zwar derzeit sehr viel bewegt und somit viele positive Innovationen stattfinden, die Halbwertszeit vieler ursprünglich einmal als „hip“ gegoltener Frameworks aber deutlich unter fünf Jahren liegt. Oder wer startet heute noch sein Web-Projekt mit den beiden, noch vor wenigen Jahren hochgelobten Frameworks Prototype und script.aculo.us? Dies könnte zumindest für diejenigen Unternehmen ein Problem werden, die auf Langfristigkeit und Beständigkeit in ihrer Entwicklungsstrategie wert legen.

Für alle Nuancen zwischen den beiden dargestellten Anwendungstypen – klassische Business-Anwendung und datenzentrierte REST- bzw. ROCA-Anwendung – gilt es individuell und projektbezogen, dass Für und Wider, unter Berücksichtigung des vorhandenen Teams, sauber abzuwägen.

Aufmacherbild: people icons with colorful dialog speech bubbles von Shutterstock / Urheberrecht: Marish

Geschrieben von
Lars Röwekamp
Lars Röwekamp
Lars Röwekamp ist Gründer des IT-Beratungs- und Entwicklungsunternehmens open knowledge GmbH, beschäftigt sich im Rahmen seiner Tätigkeit als „CIO New Technologies“ mit der eingehenden Analyse und Bewertung neuer Software- und Technologietrends. Ein besonderer Schwerpunkt seiner Arbeit liegt derzeit in den Bereichen Enterprise und Mobile Computing, wobei neben Design- und Architekturfragen insbesondere die Real-Life-Aspekte im Fokus seiner Betrachtung stehen. Lars Röwekamp, Autor mehrerer Fachartikel und -bücher, beschäftigt sich seit der Geburtsstunde von Java mit dieser Programmiersprache, wobei er einen Großteil seiner praktischen Erfahrungen im Rahmen großer internationaler Projekte sammeln konnte.
Arne Limburg
Arne Limburg
Arne Limburg ist Softwarearchitekt bei der open knowledge GmbH in Oldenburg. Er verfügt über langjährige Erfahrung als Entwickler, Architekt und Consultant im Java-Umfeld und ist auch seit der ersten Stunde im Android-Umfeld aktiv.
Kommentare

Hinterlasse einen Kommentar

12 Kommentare auf "JSF: Einer für alle, alle für einen? Kommentar zum ThoughtWorks Technology Radar"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Joachim Arrasz
Gast

Was hilft es einem, wenn die aktuelleren Standards (2.2) einen besseren Weg bieten, wenn man diese so gut wie nie einsetzen kann?
Aufgrund dessen das JSF (wohl) ohnehin nur in reichlich unflexiblen Firmen (nur diese setzen meiner Erfahrung nach gnadenlos auf Standards) nicht einsetzen kann bringt einem dass dann in 2-4 Jahren etwas. Richtig?

Habt ihr hier andere Erfahrungswerte?

Lars Röwekamp
Gast

Hallo Joachim, wir sehen durchaus auch "flexible" Unternehmen, die aufgrund des von uns genannten USPs bewusst auf JSF setzen. Allerdings sollte das von dir beschriebene Problem tatsächlich nicht unterschätzt werden. Insbesondere vor dem Hintergrund, dass eine finale Spec ja noch lange nicht bedeutet, dass es auch eine produktionsreife Implementierung dafür gibt. Die meisten unserer Kunden migrieren – schon aus Selbstschutz – in der Regel frühesten 6-12 Monate nach erscheinen einer neuen (JEE) Spec auf die neue Technologie.

Joachim Arrasz
Gast

Was hilft es einem, wenn die aktuelleren Standards (2.2) einen besseren Weg bieten, wenn man diese so gut wie nie einsetzen kann?
Aufgrund dessen das JSF (wohl) ohnehin nur in reichlich unflexiblen Firmen (nur diese setzen meiner Erfahrung nach gnadenlos auf Standards) nicht einsetzen kann bringt einem dass dann in 2-4 Jahren etwas. Richtig?

Habt ihr hier andere Erfahrungswerte?

Lars Röwekamp
Gast

Hallo Joachim, wir sehen durchaus auch "flexible" Unternehmen, die aufgrund des von uns genannten USPs bewusst auf JSF setzen. Allerdings sollte das von dir beschriebene Problem tatsächlich nicht unterschätzt werden. Insbesondere vor dem Hintergrund, dass eine finale Spec ja noch lange nicht bedeutet, dass es auch eine produktionsreife Implementierung dafür gibt. Die meisten unserer Kunden migrieren – schon aus Selbstschutz – in der Regel frühesten 6-12 Monate nach erscheinen einer neuen (JEE) Spec auf die neue Technologie.

Nikolaos Kaintantzis
Gast
Danke für euren guten Artikel. In meinem Umfeld gab es mehrheitlich Freunde und Schadenfreude über die Beurteilung von JSF im Tech-Radar. Dies mag daran liegen, dass ich jetzt in einem coolen Responsive-Projekt mit „modernen“ Technologien bin. Dennoch gibt es Kunden, denen ich JSF weiterhin empfehlen kann. Denn, wie ihr auch schreibt: auf den Kontext kommt es an! Wer Technologien allein anhand des aktuellen Coolness-, Mode- oder Propaganda-Faktors beurteilt macht den gleichen Fehler wie jene, die blind auf Standards setzen. Die ganze Diskussion mit Kunden und Kollegen haben mich veranlasst selbst einen Blog-Beitrag zu schreiben (siehe: http://blog.zuehlke.com/ist-das-jsf-modell-wirklich-kaputt/). Das Fazit geht in… Read more »
Nikolaos Kaintantzis
Gast
Danke für euren guten Artikel. In meinem Umfeld gab es mehrheitlich Freunde und Schadenfreude über die Beurteilung von JSF im Tech-Radar. Dies mag daran liegen, dass ich jetzt in einem coolen Responsive-Projekt mit „modernen“ Technologien bin. Dennoch gibt es Kunden, denen ich JSF weiterhin empfehlen kann. Denn, wie ihr auch schreibt: auf den Kontext kommt es an! Wer Technologien allein anhand des aktuellen Coolness-, Mode- oder Propaganda-Faktors beurteilt macht den gleichen Fehler wie jene, die blind auf Standards setzen. Die ganze Diskussion mit Kunden und Kollegen haben mich veranlasst selbst einen Blog-Beitrag zu schreiben (siehe: http://blog.zuehlke.com/ist-das-jsf-modell-wirklich-kaputt/). Das Fazit geht in… Read more »
Romaine
Gast

I've been a english teacher for any incredibly long time and I
enjoy the way you wrote this short article! I shared this with my colleague
who teaches inventive and informational writing at my college and shes
used it as an instance for certainly one of her classes.
Enough mentioned. Nice article!

Romaine
Gast

I've been a english teacher for any incredibly long time and I
enjoy the way you wrote this short article! I shared this with my colleague
who teaches inventive and informational writing at my college and shes
used it as an instance for certainly one of her classes.
Enough mentioned. Nice article!

Patrice
Gast

You could definitely see your skills in the artice youu write.
The sector hopes forr even more passionate writers
such as you who are not afraid to mention how they believe.
At all times go aftwr your heart.

Patrice
Gast

You could definitely see your skills in the artice youu write.
The sector hopes forr even more passionate writers
such as you who are not afraid to mention how they believe.
At all times go aftwr your heart.

struberg
Gast
Ich arbeite seit etwa einem Jahr in einem großen Projekt bin in dem ich _leider_ kein JSF verwenden kann sondern eines von den derzeit gehypten 'neuen' Frameworks. Um es kurz zu sagen: ein paar Dinge gehen damit besser, aber all diese frameworks haben noch derart viele Kinderkrankheiten und Schwachpunkte, daß ich mir oft JSF (Apache MyFaces-2.1) zurückwünsche. * Gerade für formulargetriebene Apps mit vielen Eingaben bietet JSF auch aktuell noch immer große Vorteile. Man kann einfach recht schnell neue Dialoge hinzufügen. * Stateful muß nicht immer ein Nachteil sein. Die meisten Teile einer Applikation sind sowieso @RequestScoped. Aber man kann… Read more »
struberg
Gast
Ich arbeite seit etwa einem Jahr in einem großen Projekt bin in dem ich _leider_ kein JSF verwenden kann sondern eines von den derzeit gehypten 'neuen' Frameworks. Um es kurz zu sagen: ein paar Dinge gehen damit besser, aber all diese frameworks haben noch derart viele Kinderkrankheiten und Schwachpunkte, daß ich mir oft JSF (Apache MyFaces-2.1) zurückwünsche. * Gerade für formulargetriebene Apps mit vielen Eingaben bietet JSF auch aktuell noch immer große Vorteile. Man kann einfach recht schnell neue Dialoge hinzufügen. * Stateful muß nicht immer ein Nachteil sein. Die meisten Teile einer Applikation sind sowieso @RequestScoped. Aber man kann… Read more »