评论我过去几个月的Primefaces/JSF体验:

如果你可以使用“现成的”组件，我想这并不可怕。 然而，当你走到外面并需要定制ui时，它就不能很好地发挥作用。-例如，我们需要在项目中使用Twitter的bootstrap。(不是primefaces bootstrap)。 现在我们的页面工作如下: 页面加载。 用户与具有ajax功能的Primefaces交互 Bootstrap的javascript绑定中断 我们运行额外的javascript来重新绑定所有内容

JSF避免编写javascript的承诺变成了编写比不使用Primefaces时更多的javascript——而javascript是用来修复Primefaces破坏的。

这是一个时间消耗器——除非你再次使用现成的东西。当不得不与Selenium一起工作时，也非常丑陋(Primefaces)。这些都是可以做到的，但是时间有限。

如果你和UX/设计团队一起工作，并且需要快速迭代UI，你可以通过学习jquery/编写直接的HTML来节省时间，或者查看react/angular。

JSF只有一个缺点:在开始“JSF”开发之前，你应该清楚地了解web开发、核心java和前端架构。

现在“新的”JavaScript框架只是试图复制/粘贴“JSF”基于组件的模型。

我想到了一些缺点:

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应用程序来说，它不是一个好方法。

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

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提供的解决方案相比，它有点麻烦和不完整。