我想到了一些缺点:

JSF is a component-based framework. This has inherent restrictions that have to do with obeying the component-model. AFAIK JSF supports only POST, so if you want a GET somewhere you have to do a plain servlet/JSP. Most components try to provide abstractions over domains like relational databases and front-end JavaScript, and many time these abstractions are "leaky" and very hard to debug. These abstractions might be a good starting point for a junior developer or someone not comfortable with a particular domain (e.g. front-end JavaScript), but are very hard to optimise for performance, since there are several layers involved, and most people that use them have little understanding of what is going on under the hood. The templating mechanisms that are usually used with JSF have nothing to do with how web desigers work. The WYSIWYG editors for JSF are primitive and in any case, your designer will give you HTML/CSS that you'll have to spend ages converting. Things like EL expressions are not statically checked and both the compiler and IDEs are not doing a good job at finding errors, so you'll end up with errors that you'll have to catch at run-time. This might be fine for dynamically typed language like Ruby or PHP, but if I have to withstand the sheer bloat of the Java ecosystem, I demand typing for my templates.

总而言之:使用JSF节省的时间，从避免编写JSP/servlet/bean样板代码，您将花费10倍的时间来使其可伸缩并完全按照您的要求进行操作。

For me the biggest shortcoming of JSF is poor support for programmatically (dynamically) generated pages. If you want to construct your page (create page component model) dynamically from java code. For example if you are working on WYSIWYG web page constructor. Adequate documentation of this use case in not generally available. There are many points where you have to experiment and development is quiet slow. Many things just don't work how you would expect. But generally its possible hack it somehow. Good thing is that it's not problem in philosophy or architecture of JSF. It's simply not elaborated enough (as far as I know).

JSF 2带来了组合组件，这将使组件开发变得容易，但是它们对动态(编程式)构造的支持非常差。如果你克服了动态组合组件构造的复杂且几乎没有文档的过程，你会发现如果你把几个组合组件嵌套得稍微深一点，它们就会停止工作，抛出一些异常。

但是JSF社区似乎意识到了这个缺点。你可以从这两个bug中看到，他们正在研究这个 http://java.net/jira/browse/JAVASERVERFACES-1309 http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

至少在谈论规范时，JSF 2.2的情况会更好。

在所有的“主流”框架中，如Spring MVC、Wicket、Tapestry等，Java EE的JSF及其复合组件是所提供的最精细的表示层和面向组件的技术。与HybridJava提供的解决方案相比，它有点麻烦和不完整。

对我来说，JSF 2.0最大的缺点不仅是JSF的学习曲线，而且是为了让它做有用的工作而必须使用的组件库。想想你要真正精通需要处理的数量惊人的规范和标准:

HTML in the various incarnations. Don't pretend you don't need to know it. HTTP -- when you can't figure out what is going on you have to open Firebug and see. For that you need to know this. CSS -- Like it or not. It isn't so bad really and there are some nice tools out there at least. XML -- JSF will probably the first place you use namespaces to this degree. Servlet Specification. Sooner or later you will get into calling methods in this package. Aside from that you have to know how your Facelets gets turned into XHTML or whatever. JSP (mostly so you know why you don't need it in JSF) JSTL (again, mostly to cope with legacy framework) Expression Language (EL) in its various forms. ECMAScript, JavaScript, or whatever else you want to call it. JSON -- you should know this even if you don't use it. AJAX. I would say JSF 2.0 does a decent job of hiding this from you but you still need to know what is going on. The DOM. And how a browser uses it. See ECMAScript. DOM Events -- a topic all by itself. Java Persistence Architecture (JPA) that is if you want your app to have any back end data base. Java itself. JSEE while you are at it. The Context Dependency Injection specification (CDI) and how it clashes with and is used with JSF 2.0 JQuery -- I would like to see you get along without it.

现在，一旦你完成了这些，你就可以继续使用专有规范，即你将在此过程中获得的组件库和提供者库:

PrimeFaces(我选择的组件库) RichFaces MyFaces ICEFaces EclipseLink(我的JPA提供者) Hibernate 焊接

别忘了容器!所有这些配置文件:

GlassFish(2,3等) JBoss Tomcat

那么——这让事情变得简单了吗?当然，JSF 2.0很“简单”，只要你想做的只是最基本的web页面和最简单的交互。

简单地说，JSF 2.0是当今软件界所存在的最复杂和最麻烦的技术大杂烩。我想不出还有什么更好的方法。

我们使用JSF开发了一个示例项目(这是一个为期三周的研究，所以我们可能会丢失一些东西!)

我们尝试使用核心jsf，如果需要组件，我们使用PrimeFaces。

该项目是一个带有导航功能的网站。当点击菜单时，每个页面都应该通过ajax加载。

该网站有两个用例:

带有网格的页面。网格是通过ajax加载的，应该支持排序和分页 一个三步向导页面。每个页面都有客户端验证(用于简单验证)和服务器端ajax基础验证(用于复杂验证)。任何服务器异常(来自服务层)应该显示在向导的同一页上，而不需要导航到下一页。

我们发现:

You need to use some hacks from omniFaces to make the JSF view state fixed. The JSF state will be corrupted when you include pages via ajax in each other. This seems a bug in JSF and may be fixed on next releases (not in 2.3). The JSF Flow is not working correctly with ajax (or we could not make it work!) We try to use primeface wizard component instead but the client validation seems not supported and mean while it was not standard JSF flow standard. When using some jQuery components like jqGird, and you need to load JSON results, then you are advised to use pure servlet, The JSF will do nothing for you. So if you use these kind of components, your design will not fit in JSF. We try to do some client scripts when ajax complete by ajaxComplete and we found that the PF 4 has implemented its own ajax events. We had some jQuery components and we need to change their code.

如果您将上面的示例更改为非Ajax项目(或至少是较少的Ajax项目)，您将不会面临上述许多问题。

我们将我们的研究总结为:

JSF在一个完全基于ajax的网站上不能很好地工作。

当然，我们发现JSF中有很多不错的特性，这些特性在某些项目中可能非常有用，所以请考虑您的项目需求。

请参考JSF技术文档来回顾JSF的优点，在我看来JSF最大的优点是来自@BalusC的完全和巨大的支持;-)

I'm not a Java Server Faces expert at all. But IMHO the main disadvantage is that it's server side. I'm tired of learning and using server side web presentation layer frameworks like ASP.NET Web Forms, ASP.NET MVC, Java Server Faces, Struts, php frameworks and ruby on rails frameworks. I said goodbye to all of them, and I said hello to Angularjs and TypeScript. My presentation layer runs on the browser. I doesn't matter if it is served by Windows IIS running php or ASP.NET, or if it is served by an Apache web server running on Linux. I just need to learn just one framework that works everywhere.

这只是我的个人意见。