Sunday, April 09, 2006

Java Server Faces in Action


I have recently been looking at Java Server Faces and, as usual, went through the first phase of trying to understand what is involved in using it....What it can bring in and what are the compromises one has to do when using it. I am a firm believer of a tool for each job and just dove in trying to understand what kind of tool this is...So...I picked up Java Server Faces in Action and went wild with a mix of reading then diving into action (staying true to the philosophy of the in Action series). So here are my conclusions...

The book is actually a good book. Would not say excellent since it spends a whole lot listing components and attributes before diving into application of it. Something which makes for a bit of what feels like a slow reading. That being said, it does expose pretty well what you can do with JSF. Granted it is pretty valuable, but I also found a bit annoying the fact that there are an extra set of 5 chapters and 4 appendixes online and not in the print version (not published after the fact! They are even listed in the book's table of contents!!). There is a reason why I buy hardcopy books and that is that I really like having the print version and be free to read something irrespective of the presence of a internet connection or the presence of a computer with a downloaded PDF. And I really can do without printing an extra set of 270 pages (got to give a break to my home printers!).

What about JSF ? Well, I do get mixed feelings about it and to be honest I do not think that, given the nature of applications I write, I am ready to start using it just right now...Some comments on what I read and played with...
As I read this, I also browsed online for comments and applications of JSF. In particular I listened to the ZDot Podcasts by Tim Shadel. A lot of fuss was raised in the Java community around this podcast (see TheServerSide for instance, a ton more out there). Tim does point out some interesting and somewhat valid issues if JSF. Some are surely no longer applicable since he had been using an old version of JSF and do believe some of the issues he faced (e.g. bad quality of generated HTML) is no longer that much of an issue. I also believe that most importantly he might have missed an important point that you have each tool for each job. After reading and playing a ton with JSF I am convinced that the kind of applications JSF applies to are rich, almost desktop like, web applications and not your regular website.
But he does make pretty good points about some shortcomings of the technology. Taking that and my experiments here is what I liked and did not like about JSF.

Pros:

  • It is a pretty cool technology with a well thought of architecture. I really like the concept of components and regardless of other comments, I like the 7 layer burrito to implement the life cycle of a component.
  • Being component oriented I do see the huge advantages of getting pre-built components that already do the "dirty work" for you. It is indeed the basis for efficient code reuse. Oracle ADF and Apache MyFaces are just two examples of component libraries for JSF. Both provide pretty cool and useful component sets.
  • JSF has good tool support. If you use something like Java Studio Creator you can quickly take the best advantage of the component-oriented approach of JSF for rich app development (although I also have some issues with Java Studio Creator -- I have a pretty beefed up machine and my god, is this thing a performance hog sometimes!).

Cons:

  • Getting components to do the work for you prevent you from tweaking what you can do with the generated HTML. That makes sense in the scope of a rich client app, not so much in a web site where you want to get finer control over placement and presentation of all your design items. In particular, interactions with professional designers (usually non-programmers) can be dificult if working from component rendered HTML. Furthermore, some components provide their own stylesheets making it harder for proper integration with a site design.
  • There are components for JSF out there...I played with Oracle ADF and with Apache MyFaces. MyFaces was, by far, a lot more to my liking. Easier to use and deploy into your own app. I had a ton of issues with ADF. Both components libraries miss (IMHO) some more documentation to make them more usable. The goal of components is to make them easy to reuse and that *has* to equate to good documentation.
  • Every interaction involves a full roundtrip. Take for instance validation of fields. This involves a full post to the server, interaction with the component lifecycle and a return of the full HTML back to the client. With things like AJAX around, it does sound a bit hard to swallow that a full roundtrip needs to be performed to do simple validation...it sounds just to heavy for what we should be doing. Granted there are approaches to join JSF with AJAX but they start to sound a bit hybrid solutions and start taking away a bit the nature of JSF. Some components available in the JSF components libs can already be found as lightweight Javascript/AJAX components...something I would rather favor to server side full roundtrip requiring solutions.

Bottom line....I did like the book, I was not 100% convinced by the technology. I see some uses in the realm of rich web applications, I see the elegance of the architecture, I see the advantage of having good components libraries. However I feel it does not give you necessarily the best user interaction experience (POST for every interaction), might not give you ease of control over presentation aspects should you need it (e.g. a complete web site, not just a web app), components are still not that straightforward to use.

I am not jumping into the JSF wagon just yet...