I’m not alone for having this point of view. There are many voices having doubts about this technology:
Here are my opinions about the disadvantages of JSF:
<learnthis:thenlearnthat dontforgetme="doyourememberme()" iamundocumentedsuperfeature />
3- Losing Extensibility and Flexibility: Component encapsulation makes it hard to modify UI behaviors. Let’s say you want to insert some HTML code into 3rd row of a data grid. That may not be available in current API set. There may be many scenarios that were simple in HTML base declarative form. I inspected many JSF list components and they are nothing more than simple HTML tables. Why do we pay extra complexity cost for little earning of encapsulation of HTML? Even most of JSF components are just repetition of current HTML elements. You can find same function set of JSF implementations within JS libraries, nothing is new.
4- Complexity of Binding, Bean Lifecycle, Navigation, Scope and Event Model: To get basic grasp of JSF is much more difficult than request-based server models. MVC simplicity is also lost. You can observe that complexity in increasing development times or difficulties in debugging and fixing problems of applications. Designing UIs is just another story, common denominator between programmer and graphics designer is lost, every programmer should be also good designer. A very strong IDE support is required to hide some complexities like WebObjects did years ago.
5- Performance: I’ve heard some complaints about JSF performance, it may be eliminated but It is a fact that it would anyway consume valuable server resources. As we develop complex components with JSF, their performance degradation would be a new area of bottleneck analysis.
In Java EE stack, some standards never got enough adoption and that lead developers to find better, simpler solutions. I think JSF is moving on the same direction with EJB. Some developers may feel themselves comfortable by using JSF; good engineering, clean and structured code but I don't.