I'll grant that more complicated applications will be easier to manage with Seam, Guice, Spring, etc, but one *can* write applications in Plain Jane JSF, though they may be simple.  But if the user just wants to write a simple application, then that's good enough.

We shouldn't hamstring them, or guilt them into throwing more complex IoC solutions into the mix just because We Know Better Than They.  FWIW, I worked at a shop that didn't use any of the aforementioned IoC panaceas.  We used JSF and, if necessary, EJB3.  IIRC, most were simply JSF+JPA, which fit the bill nicely.  We weren't writing the next eBay, but they kept that mid-size HVAC company, and continue to do so 3+ years after some of them written.

The problem I have with this viewpoint is that if you take standalone JSF and compare it to the myriad of alternatives the developer has to choose from, many of the alternatives are much more attractive Basically, if it were that simple of an application, I might not even use JSF (Grials perhaps). I might not even use Java EE.

What makes JSF so compelling and unique is that it opens the door to the rest of Java EE, giving a clear integration between web and enterprise services. It's failure to do that in Java EE 5 is how we ended up with Seam in the first place.

I just don't understand why we are trying to keep an arms length distance from Java EE (whether it be 5 or 6). JSF *is* a part of Java EE. It's value is not in a standalone framework. We can let it be used standalone, just like JPA, but that should be secondary to the tight integrations it offers with Java EE. We have to be realistic about what else is available to developers.

-Dan