JSF still sucks?
Granted, this post about how painful JSF is is almost 6 months old, but I think it's still mostly true.
Want to compare times? More than three man-weeks have been spent fixing silly JSF navigation problems. A full CRUD AJAX interface with Spring MVC and prototype in the same project took four days, and there was no previous experience with Spring MVC.
If you're going to use JSF, I highly recommend Facelets or Shale/Seam. However, those are mentioned as well:
The default view technology is JSP, even when no one in the real world would recommend it; instead, use Facelets, or Clay, or some other non-standard framework. Not trying to be sarcastic here, since Facelets is pretty good, but this complicates the hiring and education of the team and in fact invalidates the selling point of Faces 'being a standard'.
IMO, Facelets is very easy to learn. If you know how to program JSPs with JSF, you should be able to use Facelets in under an hour. When we converted AppFuse's JSF flavor from JSP to Facelets, rarely did the body have to change - we just had to change from taglibs to XML namespaces.
When you are not working with persistent data (if you are living in a cave or developing wizard interfaces) there are two scopes to store model state: the session context, which raises concurrency issues and is not recommended by the Faces community, and the conversation/process/whatever context, which is not standard and imply installing shale or seam to put even more lipstick on the pig.
There's two problems with Shale and Facelets - the activity on these projects is very low. Shale still has its creators around, so even while its seldom used, you can probably still get your questions answered. However, Facelets seems to be suffering from "developer abandonment".
Conclusion: don't use JSF simply because it's a "standard". Use other frameworks that are more actively developed and designed for the web. For component-based frameworks, the most popular are Tapestry and Wicket. Less popular ones are RIFE and Click.
If you still want to use JSF, you should probably use Seam, but don't simply use JSF because it's a standard. If it was a de-facto standard, that'd be another story.
Of course, you could also help improve JSF 2.0. But that's not scheduled for release until late 2008. I'm sure 2 or 3 commentors will claim we'll all be using Rails or Grails by then. 
Posted by Paul Barry on April 16, 2007 at 07:43 PM MDT #
As far as rails/grails is concerned, I disagree. Sounds like MDA revisited, or just another language to keep me busy (although I like some features of ruby)
Koen
Posted by Koen Serry on April 16, 2007 at 08:04 PM MDT #
Posted by Twice on April 17, 2007 at 07:40 AM MDT #
Being a standard gives JSF a great advantage over other frameworks - there are so many third-party JSF component libraries which plays pretty well together. I agree that you should not use some framework simply because it is a standard, but if that gives you some extra benefits, you should think again. Anyway, people often forget that JSF is not just another framework but specification which aims to build ecosystem of other frameworks (Seam, Shale...), component libraries (Ajax4jsf, RichFaces, Trinidad, IceFaces..) and implementations.
Posted by Dejan on April 17, 2007 at 09:03 AM MDT #
Posted by Craig on April 17, 2007 at 11:53 AM MDT #
Posted by Matt Raible on April 17, 2007 at 12:14 PM MDT #
Posted by Ignacio Coloma on April 17, 2007 at 12:37 PM MDT #
I work in an IT department within a corporation. The business doesn't care about technology decisions, they only care that a business need is satisfied. There are 20+ websites in various stages of evolution my team has to deal w/on a daily basis. The technology utilized for these sites was pretty much what was "Hot" for that period of time (remember when container managed entity beans were cool? or how about a JSP scriplet-based application?). The problem we have run into, is the myriad technology, frameworks and approaches taken for each site vary so greatly, that it makes maintenance a real pain to do and to find appropriate people to do it.
We're now in a refactoring / rewrite of all the sites because we're pretty much pinned down and unable to move fast enough to adapt to changing business needs. As part of the refactoring, we adopted JSF as the common framework for presentation. Yes, we're running into issues Mr Raible has outlined (and then some), but we're dealing with them. We've also needed to write a number of custom components, which some developers are complaining about having to do.
The positive side of things, is that we're in a better position now than the position we got ourselves into over the past 10 years. One of the reasons we chose JSF is because it is a spec. IMHO, Java presentation technology is evolving, but it seems like it is evolving from a JSF base, not some framework or OSS project.
When our first AJAX requirement was submitted, we incorporated Ajax4jsf and it wasn't a huge deal. To me, that was pretty "cool".
Posted by m@t on April 18, 2007 at 03:40 PM MDT #
Posted by Java on April 20, 2007 at 08:31 PM MDT #
Posted by Ryan Lubke on May 17, 2007 at 02:14 PM MDT #
Posted by Jacob Hookom on May 17, 2007 at 02:21 PM MDT #
Posted by Srinivas Narayanan on March 11, 2008 at 01:37 AM MDT #
Posted by Jeremy Leipzig on September 17, 2008 at 02:21 PM MDT #
JSF 2.0 is out, it is based on Facelets, and guess what... it still sucks!
Tooling is also practically absent, components are scarce (apart from IceFaces, RichFaces and PrimeFaces you don't find anything JSF 2.0... maybe Oracle will update their ADF soon).
Seems like JSF needs another generation to get things right... is this deja vu? [Entity Beans?]
Posted by jbx on July 17, 2010 at 02:44 PM MDT #