en
de

Ist das JSF-Modell wirklich kaputt?

11 Februar 2014
| |
Lesezeit: 3 Minutes

Im Technology Radar von ThoughtWorks schneidet JSF 2.0 ziemlich schlecht ab. Da steht zum Beispiel: „We are aware of the improvements in JSF 2.0, but think the model is fundamentally broken.“ Ebenfalls nachzulesen: „We think JSF is flawed because it tries to abstract away HTML, CSS and HTTP, exactly the reverse of what modern web frameworks do.“

Diese und weitere Aussagen sind meiner Meinung nach richtig, aber einseitig und überspitzt formuliert. Nehmen wir den Satz „Teams seem to choose JSF because it is a J2EE standard without really evaluating whether the programming model suits them“. Auf den Standard zu setzen ist nicht per se falsch. Zurückblickend hätten vor einigen Jahren einige Projekte besser auf JSF statt auf Flex gesetzt. Nicht zu prüfen, ob das JSF-Modell passt und stattdessen ohne Evaluation der gegebenen Rahmenbedingungen ein „modernes Web-Framework“ auszuwählen, ist falsch.

Was ist das JSF-Programmier-Modell überhaupt?

Gute Frage. Ich nehme an, hiermit wird auf den Life-Cycle und den Komponentenbaum angespielt. Eventuell sind hier auch die austauschbaren Kernkomponenten wie der Renderer und die Extension-Mechanismen gemeint. Dies alles macht JSF kompliziert und abstrahiert die Realitäten einer Webapplikation weg vom Entwickler. Diese Erweiterbarkeit und Austauschbarkeit bring aber auch eine Stärke mit sich: JSF ist nicht nur Web. Es können auch JavaFX-Clients mit JSF-Backend gebaut werden. (Siehe z.B. das Framework Captain Casa, das sich unter anderem die Austauschbarkeit des Rendererer in JSF zu nutze macht).

Wo passt das JSF-Modell?

KMUs mit kleiner Entwicklungsabteilung müssen ihre Kräfte bündeln. Das Know-how und der Aufgabenbereich dieser Abteilungen ist breit gefächert. Generalisten statt Spezialisten sind gefragt. Front-End-Aufgaben werden nicht durch Spezialisten sondern durch das ganze Team (z.B. Java-Entwickler) erledigt. Wenn der Front-End-affine Mitarbeiter im Urlaub ist, muss der Kollege einspringen. In solch einem Umfeld ist man darauf angewiesen, die Sprachen- und Framework-Vielfalt gering zu halten und auf Technologien zu setzen, die sich am Markt etabliert haben. Jedem Trend nachzugehen widerspricht zudem dem gewünschten Investitionsschutz und der Stabilität.

Werden Web-Applikationen von der internen Fachabteilungen am Arbeitsplatz verwendet (Line of Business Apps), so werden meist geringere Anforderungen am Erscheinungsbild (z.B. Animationen) gestellt. Responsive Design ist auch nicht gefragt. Wichtiger als die Modernität eines Frameworks ist es, dass das Modell die Arbeit des Entwicklerteams erleichtert und die Implementierung beschleunigt. Ziel ist es ein angemessenen gutes UI mit geringem Aufwand zu erstellen. Eine sortierbare Tabelle zum Beispiel muss mit wenigen Zeilen erstellt sein. Dies ist mit bewährten JSF-Komponenten einfach, schnell und ohne grosses Know-how clientseitiger Webtechnologien zu erreichen.

Wo macht JSF weniger Sinn oder ist aufwändiger?

Im mobilen Umfeld oder im Bereich dynamisch gestalteter Layouts (Responsive Design) gibt es wenig ausgereifte Komponenten. Jedoch ist es möglich, mit den Basiskomponenten auch mit JSF Responsive Design umzusetzen. Wurden aber Erweiterungen resp. spezielle Komponenten (zum Beispiel grössere Tabellen mit Mehrfachheadern) eingesetzt, so sind diese mit grosser Wahrscheinlichkeit nicht per se responsive umsetzbar. Wenn also HTML5-, CSS3- und JavaScript-Wissen gebraucht wird, dann ist der Schritt zum Arbeiten ohne JSF klein und somit naheliegend. Coole UIs entstehen aus den gleichen Gründen ohne JSF.

Eine moderne Web-Architektur ist heute stateless und Service-basiert (vor allem REST-basiert). JSF war vor diesem Trend. Wenn die Abstraktion von JSF im Projekt oder im Geschäft keine Vorteile bringt, würde ich auf JSF verzichten.

Mein Fazit

Das Wegabstrahieren von Basis-Technologien hat Vor-, aber auch Nachteile und schafft neue Probleme. ThougtWorks sagt nichts Falsches. Der Trend sagt klar, man muss sich mit den Web-Basistechnologien beschäftigen. Dem stimme ich voll bei. Doch die Pauschalverurteilung ohne Projektkontext ist zu sehr auf Marktschreier-Niveau. Es gibt einen Einsatzbereich und somit -Markt für JSF, auch wenn er schrumpft und die meisten Entwickler lieber trendigere Frameworks einsetzen wollen. Wichtig ist, sich die Frage zu stellen, ob JSF dem eigenen Projekt mehr Vor- als Nachteile bringt.

Kommentare (11)

Jonas

11 Februar 2014 um 20:35

Ha ha,
im 2011 haben sie beinahe dasselbe von GWT geschrieben.

… das ist alles Teil einer grossen JavaScript-Verschwörung 🙂

thoefer

5 März 2014 um 13:15

Yes, seriously, jsf is fundamentally broken as are *all* other „technologies“ trying to abstract away the web and its statelessness with state simulating components (at this point the web still hasn’t state… see the conceptual mismatch?!).

You can achieve everything(!) you’ve described with a stateless rest framework and knowledge of basic web technologies in a better way: better code, easier to maintain, better usability, a browser works as expected (back button, anyone?!). To me, one simply has(!) to know web technologies – thats in the same category as one has to know about SQL and not only ORM.

Guys complaining about all that usually don’t understand (or accept) the principles of the web deep enough. In a nutshell: the web is a graph of resources that a browser traverses – every visitation of a node goes along with a fresh state (usually displayed in a browser). Compare that fact with a technology like JSF of „stateful whatever“…

(„[… ]ein “modernes Web-Framework” auszuwählen […]“) – in facth there exist(!) modern frameworks, no need for quotation marks, you’re not aware of that?! See for example Play 2. Wouldn’t you agree that it’s a more modern and web centric approach than e.g. Struts? Time goes by and you should try to follow relevant trends otherwise you’re stuck in the past with using JSF.

    Nikolaos Kaintantzis

    Nikolaos Kaintantzis

    5 März 2014 um 14:52

    Of course modern web frameworks exist. And I never doubted that I can do the same things with my bare hands or a modern framework instead of using JSF. In fact I do so with my current project and it’s fun. But for each project I have to care about the context and the customers. And for some circumstances JSF makes sense.

    Choosing JSF is not necessarily the same as being stuck in the past. It’s one possible option for a “design to cost” strategy. Sometimes “better” is too expensive.

    The core message of my post is not “Use JSF because everything else is not mature enough”…
    The core message is: Evaluate!

      thoefer

      5 März 2014 um 15:12

      To answer the page title’s question: yes it really is flawed!

      If one has a larger app already implemented with JSF then I agree with you, one stays with JSF. But to me that is not an evaluation in the traditional sense. When starting on a greenfield project I tend not use JSF (or „stateful whatever“) on any(!) kind of webbased project. Can’t think of a scenario when using JSF on a greenfield project makes sense.

        Nikolaos Kaintantzis

        Nikolaos Kaintantzis

        5 März 2014 um 20:41

        In my opinion it makes sense to use JSF on a greenfield project if your team hasn’t the necessary web skills and nobody is able to learn the HTML5 stack (of course only if also all the other evaluation aspects match).

        Not being able to learn HTML5 stack means that there is no internal motivation or no educational support from the company’s management. This can happen if for instance:
        – no specialization of the team members due to the team size
        – the management fears that new technologies aren’t stable enough to invest into
        – web is not the core business of the company and the investment for only one specific project seems too high

      thoefer

      5 März 2014 um 15:26

      Do you guys use Play Framework 2 or Scala?

        Patrick Walther

        Patrick Walther

        6 März 2014 um 18:56

        I implemented a small project with Playframework and Scala some time ago. As far as I can remeber it was version 2.0.4.

        What I really liked about it is the Scala language coupled with Akka. It allows to write a RESTful API in just a couple of lines. The functional style really fits for such tasks. This makes the whole mapping of form data so simple and easy to understand. I was very impressed by that.
        Also the fact, that templates get compiled into Scala functions is an excellent design, making them easy to use and powerful. Yet they still contain clean HTML/JS/CSS. So you don’t need to learn a new template language.

        On the other hand when it comes to things which are not mentioned in the documentation, it can get really frustrating! For example a simple form with a file upload. The whole form mapping which is so nice, won’t work with this one and you end up creating multiple forms or other workarounds.
        Another negative point is, that your team has to learn HTML/CSS/JS and Scala.

        But overall I can say I would love to implement a bigger project with this framework! And compare it to a Java solution to see how much more code the Java one needs 🙂

          thoefer

          7 März 2014 um 19:18

          Currently I’m working on a Play 2 project (upgraded to version 2.2.2 this week without any modification of my code) with Scala almost fulltime for over 4 months now. I think documentation is quite good, all essential concepts are documented deep enough. But it’s not perfect at minor details.

          Yes, a team has to know about the typcial client side web stack when it comes to a web framework. But on the other hand it’s a rewarding experience.

          To me Scala is almost something like a paradigm shift, think about what it unifies in a coherent paradigm: static types in a language that mostly looks & feels dynamically typed; support for imperative style and functional style programming; full java compatibility; extension of the language with language constructs that are indistinguishable from syntactically builtin constructs e.g. Java’s „try with resources“ is about 10 lines of pure Scala without having to hack the compiler – the same holds true for „async and await“ in Scala 2.10.3; use Erlang’s programming model with a library like Akka.

Rick

2 August 2014 um 19:39

Ich vermisse in dieser Diskussion komplett den Hinweis auf serverseitigen, MVC-basierte Webframeworks wie Spring MVC. Zum Einsatz dieser reichen grundlegendes HTML- und HTTP- Wissen und man erspart sich dennoch die Probleme der komplexen Abstraktionsschicht, die mit JSF einher gehen.
In der Microsoft-Welt hat sich aus diesen Gründen ASP.Net MVC schon lange als Alternative zu den Web Components, welche vom Programmiermodel JSF entsprechen, etabliert und heute finden Web Components bei neuen Projekten kaum noch Verwendung.

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.