对我来说，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 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倍的时间来使其可伸缩并完全按照您的要求进行操作。

在使用JSF工作了5年之后，我认为我可以添加我的2分。

Two major JSF drawbacks: Big learning curve. JSF is complex, that's just true. Its component nature. Component-based framework tries to hide the true nature of the Web, which comes with a huge amount of complications and disasters (like not supporting GET in JSF within almost 5 years). IMHO hiding HTTP Request/Response from the developer is an enormous mistake. From my experience, every component-based framework adds abstraction to the Web development, and that abstraction results in unnecessary overhead and higher complexity.

And minor drawbacks that come to my mind: By default ID of the object is composed of its parents' ids, for example form1:button1. No easy way to comment-out incorrect page's fragment. Tag <ui:remove> needs syntactically correct content which is parsed anyway. Low quality 3rd party components which e.g. don't check isRendered() inside processXxx() method before continuing. Incorporating LESS & Sencha is hard. Doesn't play well with REST. Not so easy for UX designers, because ready-to-use components have their own CSS styles, that need to be overwritten.

不要误会我的意思。作为一个组件框架，JSF在版本2中确实很好，但它仍然是基于组件的，而且永远是……

请看看Tapestry、Wicket的低人气以及有经验的JSF开发人员的低热情(这是更有意义的)。 作为对比，看看Rails、Grails、Django、Play!框架——它们都是基于动作的，不会试图向程序员隐藏真实的请求/响应和web的无状态特性。

对我来说，这是JSF的主要缺点。恕我直言，JSF可以适合某些类型的应用程序(内部网、表单密集型)，但对于现实生活中的web应用程序来说，它不是一个好方法。

希望它能帮助一些人做出关于前端的选择。

“JSF将输出视图层HTML和JavaScript，如果不进入控制器代码，您就无法控制或更改它们。”

实际上，JSF为您提供了灵活性，您既可以使用标准/第三方组件，也可以创建自己的组件，您可以完全控制呈现的内容。使用JSF 2.0创建自定义组件只需要一个xhtml。

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.

这只是我的个人意见。

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