Since JSF was engineered by companies like IBM and Oracle, major contractors in the industry, most of the emphasis was placed on creating a modular architecture that could be "easily extended" and broken down into components. While technically sound, and well designed for large companies where developers are part of an assembly line, the community at large found JSF hard to use.
JSF lacked life-cycle extension; there are six defined phases, and if you need to add another one, you're out of luck. Also lacking was easy component creation -- Creating a component in JSF today requires modification of no fewer than four separate files, even more if you use a separate renderer class. You were on your own if you wanted to validate multiple form fields against each other.
Navigation rules were ungainly, and difficult to follow logically without a visual editor. Community documentation was almost a joke. Sun's mailing list and forum are still the best places to find help. There are some very knowledgeable people, but nowhere to be found is what most developers find most useful: a central, persistent resource for documentation. I like PHP's model -- official documentation with community feedback in comments below.
The lack of bookmarking support is one of the most highly-criticized facets of JSF, which is where I got involved, leading me to create the PrettyFaces URL rewriting extension. If you need to be convinced of the collective dysfunction on this topic, look at the results of a Google search for "jsf bookmark." Yet, at the root of all this was something JSF lacked until very recently -- something very important.
A set of ears
The community was speaking, but until recently, nobody was listening. Blame the JCP? Cay Horstmann thinks that the JCP needs to be more open to the community.
Personally, I'm surprised that JSF wasn't abandoned completely, which says in my mind, "they got something right." The framework does a lot for you, but "I can't figure out how to use it," "it doesn't do what I need," and "everything takes forever." This is where we see the light, and JSF2 enters from stage left; a new star performer?
From the very start, JSF2 is different, more open. Ed Burns, Ryan Lubke, Jim Driskoll and other blogging developers can be thanked for engaging the community in a way that Sun has not done before.
Convention over configuration has taught us a lot. We might thank Ruby on Rails, or possibly a collective laziness, but the JSR 314 Expert Group has taken it to heart. "EzComp" is JSF's new component writing system, and yes, it's "Ez."
Jim Driscoll explains how to create a "click to edit" Ajax input field, like those so popularly seen on Flickr or Facebook. (About 30 lines of XHTML, plus JavaScript.) Tag libraries no longer need to be defined manually; they will spring to life as needed, based on the names and interfaces of your components.
JSF2 is showing stunning promise and vision. This is just a small set of changes that will drastically improve the usefulness and adoption of JSF. When a rookie Java Web-developer can pick up JSF2.0, in their IDE of choice, and write a small, useful application in a day, that's when we'll know they've gotten it right. Man, life is good ... but.
