What is JSF really all about?

Question

On another thread on this forum somebody posted these two very interesting articles, which for me helped clear up a lot of the confusion about what JSF is about.
http://www.internetnews.com/dev-news/article.php/3322641
http://www.internetnews.com/dev-news/article.php/3324521
But for me anyway they raised a bunch of new questions, which I am wondering if the JSF team can comment on? According to the articles, JSF is not an out of the box solution. It is really a framework for building frameworks and not for building applications. So far, after playing around with JSF for a few weeks, it seems to me that this is a true statement. Now here is the confusion:
1) JSF is supposed to prevent the fragmentation and vendor lock-in caused by all these non-JSF frameworks out there. But if each vendor needs to build additional infrastructure to make JSF into a suitable tool for application development what prevents fragmentation and lock-in caused by multiple JSF frameworks. Right now the problem is that a new Java web development framework pops up every day. It seems to me that in a couple of years a new JSF compliant framework could be popping up every day. So how does JSF hope to improve the current situation?
2) I am currently doing a study on the feasibility of creating such a JSF compliant framework, but it seems like a very risky proposition. The early risk is that JSF has too many quirks to really build a proper framework without access to the underlying implementation (my limited research has indicated this). Once all the "version 1" issues get shaken out, the risk becomes that in a few years JSF will decide to become an out-of-the-box solution and blow every other JSF compliant framework out of the water. It seems that we would have to be part of the expert committe on JSF to reduce the risks to a reasonable level. It seems like only companies on the expert committee are allowed to lock developers in. Any other vendor gets frozen out by the risk. So can a small player join the expert committee for future JSF versions? What is the criteria for joining?
3) A lot of people on The Server Side are ripping JSF for being too JSP-centric, which seems wrong to me. While JSP has a lot of flaws, it seems to me that most of the JSF users will be using JSP because it's the standard. So my concern is the opposite? I've asked a few questions on this forum and the answer has been, that there are limitiations in JSF when used from JSP, but not using JSP and creating my own view handler would be a solution. It seems to me that JSF has to work best in JSP because that is what most people will use. The answer to any question should never be: "it will work better if you don't use JSP". Otherwise I'm better off writing my own templating engine, which leads to more fragmentation, lock-in etc...

Answer 1

Here is a quote from the article:
"A standard for Web application development with visual components such as buttons, frames and radio buttons, JSR-127 was never intended as an out-of-the-box development tool. But judging from the negative reaction of some programmers so far, that's what they were expecting.
Craig McClanahan told internetnews.com that many programmers were expecting a working implementation of a framework that lets coders create Web applications using visual components. Instead, they got a specification that runs underneath the framework to allow portability between different tools. "
Seems to me this is true, especially since there are only a handful of simple components, validators and events. It seems that somebody has to build it out more, either tool/component vendors or business app developers. I think for the most part business app developers aren't going to want to do this. If you have to build extra infrastructure it kills the extra productivity you get from the component model. If it's component vendors it seems to me that the components could be generic an move from one JSF implementation to another, but I'm not sure how third party components would integrate with third party tools from other vendors.
For example, if I was to write a component library and a Dreamweaver extension to let users "paint" my components, I would have to hard code the Dreamweaver extension to generate and interpret the specific sets of tags in my library. It seems to me that this is a general problem, that the tool tends to get bound up with the library. Maybe really smart tools could be built to handle UI components in a generic way and let you import any tag library, but I think this is much harder to do with tags then with Swing components, because very often a single visual GUI component is a composite of many tags, so how do you explain the interrelationships to a tool in a generic way. It seems you would need some very clever and complex meta-data, or some way to attach generic tag editors to components that could ride along with the components from tool to tool. I haven't seen that in the spec, but maybe I'm missing something.
Now, if a vendor decides to use a different templating engine altogether, which seems to be what a lot of people want and the spec and implementation seem to incourage, then all bets are off. The tools and the template have to be bound up together.
So once you pick a templating engine, a vendor tool and a component library for your application, it becomes difficult to to switch to another engine, tool and component library unless you want to abandon tools all together and just use a text editor, or rewrite your user interface. You're back to lock-in and fragmentation, same as now.
Now as a potential component vendor, I see this as a big risk. I write a component library and tool and so do a million others and we compete on the merits of our tools and libraries (I'm very comfortable with that). But developers start complaining about the fragmentation, and the only solution is for the extra infrastructure to be built right into JSF so it's standard and every tool can manage the same tags. Now I have to rewrite my tool, and my component library is worthless. So do I want to become a component vendor? Maybe if I was on the expert committee and I could prevent new standard JSF features that blow me out of the water. Otherwise it's a very risky undertaking. And statements like this in the spec "It is anticipated that the number of standard component classes will grow in future versions of the JavaServer Faces specification." don't help anything. If I'm a developer should I use a third party library or wait? If I'm a potential vendor should I even bother?