Is this a fare assessment of JSF (RI 1.1)?

Question

After playing with JSF for a week, I need to tell my manager what I think of JSF. If anyone takes issue with anything I've written below, I'd be interested to hear from you.
David
JSF generates HTML its own way. The commonly adopted process of producing a page design in pure HTML, getting the layout 'just so', then implementing a dynamic version doesn't work with JSF because you can't hope to generate exactly the same HTML. You find yourself having to adapt the screen design to fit in with JSF's way of doing things, or at least come up with a different HTML solution that can be generated by JSF.
The following is a commonly occurring frustration with JSF development: You know how you would achieve something using fundamental principles (e.g. servlets, HTML and scriptlets) but you can't find a way to make JSF achieve the same thing. It often feels like a battle, trying to get JSF to do something that would be quite straightforward if you had more control.
Some of the UI control types are restricted in the ways they may be used. For example, the h:selectOneRadio component, which models a radio button group, assumes all the buttons are located within the same parent element without any interspersed HTML between the buttons. There are many cases where this is too restrictive, e.g. a design where each row of a table begins with a radio button (as a means of allowing the user to select only a single row of the table).
Some control types are not provided (at least in Sun's Reference Implementation), e.g. HTTP file upload. You can implement your own custom components, but this is not trivial.
Quirky behaviour during development slows you down. For example, actions not firing when command buttons are clicked turns out to be due to unreported page translation problems. Have to deduce what's causing the problem by selectively commenting out different portions of the page.
The Sun JSF RI is buggy. After running into a few problems and consulting the Sun JSF forum it becomes clear that the current Sun RI (1.1) suffers from a significant number of awkward bugs.
Limited ability to manipulate the GUI using client side scripting (e.g. to add new rows to a data entry table without the need for a round trip to the server).
JSF is designed to be used with tools but tool support is currently not great. Sun Java Studio Creator looks good on paper but is rather clunky in practise. Its page layout editor only allows components to be positioned absolutely (i.e. fixed size and co-ordinates). This negates one of the great virtues of HTML, i.e. that it can allow content to flow naturally and components can be positioned according to CSS rules.
In summary, the promise of rapid development with JSF is not achieved in practise due to a variety of problems. Many of the problems are to do with the immaturity of JSF. However, the lack of control over the generated HTML (assuming it's impractical to implement custom components to solve each new requirement for custom HTML) seems to be an inherent restriction.
End

Answer 1

Layout is way to restrictive when using tables for rendering in JSF. This is an RI issue, and most likely not the spec as I am sure the spec does not say layout must be implemented with tables.
I am not sure I agree with your comment that a JSP, Servlet, HTML, CSS, javascript developer is less productive than a competent JSF developer. I think JSF is a great prototyping tool, but I don't think it is as flexible as using the fundamental technologies leveraged by JSF. I run into situations where I have to customize components straight from the fundamental tehcnologies. Based on this experience, I will run into situations where the components in JSF will require some sort of customization for a customer. I have found customers that are picky about the presentation and will move components around sometimes as little as a couple pixels. Or they will require slightly different behavior in a component than what is default. The other thing I have learned working in a corporation is that branding changes every couple years. How much investment should it take to rebrand all your JSF pages when you can make it so your pages created in fundamentals leverages one CSS for the entire site? Then when the rebranding comes, all you need to do is modify the CSS and not the JSFs. In particular, I am referring to layout and not look.
Let's say a new javascript or AJAX library comes out with some whiz bang widgets. It is a lot easier to develop with that code in fundamental technologies than in JSF. We can see this with AJAX. AJAX capabilities have been around for a while now, but JSF is playing catchup. That means, if you wanted to take advatage of the benefits of AJAX when it was first around, you would have to write custom code or wait for the widgets to come out. What would have google done for google maps if they had to wait around for JSF to catch up(if hypothetically they are using j2ee)? After all, I am certain they haven't received nice publicity which turned into revenue of some sort by being an example of AJAX design. Where would AJAX be without compelling examples of AJAX? It might still be a side note or we would be using the javascript calls directly to do the asynchronous call back to the server. So, there is something to be said about not having to wait for JSF components to manifest themselves. However, that is not to say that google couldn't have invested in its own set of components, but I am not google and I consume already created components or I put the new widgets directly in the page without leveraging the JSF lifecycle. But your choice in JSF is either to use f:verbatim or create the JSF components. Does your boss want to invest in creating JSF components that may or may not be reused? This is a tough question all bosses should ask whenever venturing down the road of extra development for purposes of reuse. When is the return going to be realized on the investment in creating components? In addition, corporations like to reorganize their business units such that the project may or may not survive the reorg. Where is the investment now? If I was a boss, I would not want my developers creating reusable components as it is a distraction. If I run a second project, I might then look into creating reusable components out of the work from the first project. But I certainly would not do it on the first project. You have no way of knowing if that code will be reused. Essentially, anytime something new that comes out that could be leveraged swiftly in an HTML page, requires more work on the JSF developers part.
By the way, I have to learn how to use f:verbatim correctly. Currently, code that I have stuck in f:verbatim is being rendered outside a subview. I might be using this incorrectly though. I am also using dwr, which I am unsure if I can incorporate into a JSF subview/view without f:verbatim since dwr requires calling a dwr servlet and not the faces servlet. I guess I might be able to get around this by assigning the action on a form dynamically to call dwr instead of faces.
Just my 1/2 cent(I try not to spend my two cents all at once),
TacoEater