asp.net-mvc Java Server Faces 2.0 的主要缺点是什么？

What are the main disadvantages of Java Server Faces 2.0?

提问by Adrian Grigore

Yesterday I saw a presentation on Java Server Faces 2.0 which looked truly impressive, even though I am currently a happy ASP.NET MVC / jQuery developer. What I liked most about JSF was the huge amount of AJAX-Enabled UI components which seem to make development much faster than with ASP.NET MVC, especially on AJAX-heavy sites. Integration testing looked very nice too.

昨天我看到了一个关于 Java Server Faces 2.0 的演示，它看起来确实令人印象深刻，尽管我目前是一名快乐的 ASP.NET MVC / jQuery 开发人员。我最喜欢 JSF 的是大量支持 AJAX 的 UI 组件，它们似乎使开发速度比使用 ASP.NET MVC 快得多，尤其是在大量使用 AJAX 的站点上。集成测试看起来也很不错。

Since the presentation only emphasized the advantages of JSF, I'd like to hear about the other side as well.

由于演示文稿仅强调了 JSF 的优点，因此我也想了解另一面。

So my questions are:

所以我的问题是：

• What are the main disadvantages of Java Server Faces 2.0?
• What might make a JSF developer consider using ASP.NET MVC instead of JSF?

• Java Server Faces 2.0 的主要缺点是什么？
• 是什么让 JSF 开发人员考虑使用 ASP.NET MVC 而不是 JSF？

回答by BalusC

JSF 2.0 disadvantages? Honestly, apart from the relative steep learning curve when you don't have a solid background knowledge about basic Web Development(HTML/CSS/JS, server side versus client side, etc) and the basic Java Servlet API(request/response/session, forwarding/redirecting, etc), no serious disadvantages comes to mind. JSF in its current release still needs to get rid of the negative image it gained during the early ages, during which there were several serious disadvantages.

JSF 2.0 的缺点？老实说，除了当您没有关于基本 Web 开发（HTML/CSS/JS、服务器端与客户端等）和基本 Java Servlet API（请求/响应/会话）的扎实背景知识时，相对陡峭的学习曲线，转发/重定向等），没有想到严重的缺点。JSF 在其当前版本中仍然需要摆脱它在早期获得的负面形象，在此期间存在几个严重的缺点。

JSF 1.0 (March 2004)

JSF 1.0（2004 年 3 月）

This was the initial release. It was cluttered with bugs in both the core and performance areas you don't want to know about. Your webapplication didn't always work as you'd intuitively expect. You as developer would run hard away crying.

这是最初的版本。它在核心和性能领域都充斥着您不想知道的错误。您的 Web 应用程序并不总是像您直观地期望的那样工作。你作为开发者会哭着跑开。

JSF 1.1 (May 2004)

JSF 1.1（2004 年 5 月）

This was the bugfix release. The performance was still not much improved. There was also one major disadvantage: you can't inline HTML in the JSF page flawlessly. All plain vanilla HTML get rendered beforethe JSF component tree. You need to wrap all plain vanilla in <f:verbatim>tags so that they get included in the JSF component tree. Although this was as per the specification, this has received a lot of criticism. See also a.o. JSF/Facelets: why is it not a good idea to mix JSF/Facelets with HTML tags?

这是错误修正版本。性能仍然没有太大的提升。还有一个主要缺点：您不能在 JSF 页面中完美地内联 HTML。所有普通的普通 HTML 都在JSF 组件树之前呈现。您需要将所有普通的 vanilla 包装在<f:verbatim>标签中，以便它们包含在 JSF 组件树中。尽管这符合规范，但这已经受到了很多批评。另请参阅 ao JSF/Facelets：为什么将 JSF/Facelets 与 HTML 标签混合使用不是一个好主意？

JSF 1.2 (May 2006)

JSF 1.2（2006 年 5 月）

This was the first release of the new JSF development team lead by Ryan Lubke. The new team did a lot of great work. There were also changes in the spec. The major change was the improvement of the view handling. This not only fully detached JSF from JSP, so one could use a different view technology than JSP, but it also allowed developers to inline plain vanilla HTML in the JSF page without hassling with <f:verbatim>tags. Another major focus of the new team was improving the performance. During the lifetime of the Sun JSF Reference Implementation 1.2 (which was codenamed Mojarrasince build 1.2_08, around 2008), practically every build got shipped with (major) performance improvements next to the usual (minor) bugfixes.

这是由 Ryan Lubke 领导的新 JSF 开发团队的第一个版本。新团队做了很多伟大的工作。规范也发生了变化。主要的变化是视图处理的改进。这不仅将 JSF 与 JSP 完全分离，因此可以使用与 JSP 不同的视图技术，而且还允许开发人员在 JSF 页面中内联普通的 HTML，而无需担心<f:verbatim>标签。新团队的另一个重点是提高性能。在 Sun JSF 参考实现 1.2（自 2008 年左右构建1.2_08以来代号为Mojarra）的生命周期中，几乎每个构建都附带了（主要）性能改进以及通常的（次要）错误修正。

The only serious disadvantage of JSF 1.x (including 1.2) is the lack of a scope in between the requestand sessionscope, the so-called conversationscope. This forced developers to hassle with hidden input elements, unnecessary DB queries and/or abusing the session scope whenever one want to retain the initial model data in the subsequent request in order to successfully process validations, conversions, model changes and action invocations in the more complex webapplications. The pain could be softened by adopting a 3rd party library which retains the necessary data in the subsequent request like MyFaces Tomahawk<t:saveState>component, JBoss Seamconversation scope and MyFaces Orchestraconversation framework.

JSF 1.x（包括 1.2）的唯一严重缺点是在请求和会话范围之间缺少一个范围，即所谓的对话范围。这迫使开发人员在想要在后续请求中保留初始模型数据以成功处理验证、转换、模型更改和操作调用时，不得不处理隐藏的输入元素、不必要的数据库查询和/或滥用会话范围。复杂的网络应用程序。通过采用第三方库可以减轻痛苦，该库在后续请求中保留必要的数据，例如MyFaces Tomahawk<t:saveState>组件、JBoss Seam对话范围和MyFaces Orchestra对话框架。

Another disadvantage for HTML/CSS purists is that JSF uses the colon :as ID separator character to ensure uniqueness of the HTML element idin the generated HTML output, especially when a component is reused more than once in the view (templating, iterating components, etc). Because this is an illegal character in CSS identifiers, you would need to use the \to escape the colon in CSS selectors, resulting in ugly and odd-looking selectors like #formId\:fieldId {}or even #formId\3A fieldId {}. See also How to use JSF generated HTML element ID with colon ":" in CSS selectors?However, if you're not a purist, read also By default, JSF generates unusable ids, which are incompatible with css part of web standards.

HTML/CSS 纯粹主义者的另一个缺点是 JSF 使用冒号:作为 ID 分隔符来确保id生成的 HTML 输出中HTML 元素的唯一性，尤其是当组件在视图中多次重用时（模板、迭代组件等） . 因为这是 CSS 标识符中的非法字符，您需要使用\来转义 CSS 选择器中的冒号，从而导致像#formId\:fieldId {}或 even 之类的丑陋和奇怪的选择器#formId\3A fieldId {}。另请参阅如何在 CSS 选择器中使用带有冒号“:”的 JSF 生成的 HTML 元素 ID？然而，如果你不是一个纯粹主义者，也请阅读默认情况下，JSF 生成不可用的 id，这与 web 标准的 css 部分不兼容。

Also, JSF 1.x didn't ship with Ajax facilities out of the box. Not really a technical disadvantage, but due to the Web 2.0 hype during that period, it became a functional disadvantage. Exadelwas early to introduce Ajax4jsf, which was thoroughly developed during the years and became the core part of JBoss RichFacescomponent library. Another component libraries were shipped with builtin Ajax powers as well, the well known one being ICEfaces.

此外，JSF 1.x 没有随附开箱即用的 Ajax 工具。并不是真正的技术劣势，但由于当时 Web 2.0 的炒作，它变成了功能劣势。Exadel很早就引入了 Ajax4jsf，经过多年的深入发展，成为了JBoss RichFaces组件库的核心部分。另一个组件库也带有内置的 Ajax 功能，众所周知的一个是ICEfaces。

About halfway the JSF 1.2 lifetime, a new XML based view technology was introduced: Facelets. This offered enormous advantages above JSP, especially in the area of templating.

在 JSF 1.2 生命周期的一半左右，引入了一种新的基于 XML 的视图技术：Facelets。这提供了优于 JSP 的巨大优势，尤其是在模板领域。

JSF 2.0 (June 2009)

JSF 2.0（2009 年 6 月）

This was the second major release, with Ajax as buzzword. There were a lot of technical and functional changes. JSP is replaced by Facelets as the default view technology and Facelets was expanded with capabilities to create custom components using pure XML (the so-called composite components). See also Why Facelets is preferred over JSP as the view definition language from JSF2.0 onwards?

这是第二个主要版本，Ajax 是流行语。有很多技术和功能上的变化。JSP 被 Facelets 取代为默认视图技术，Facelets 扩展了使用纯 XML 创建自定义组件（所谓的复合组件）的功能。另请参阅为什么从 JSF2.0 开始，作为视图定义语言，Facelets 比 JSP 更受欢迎？

Ajax powers were introduced in flavor of the <f:ajax>component which has much similarities with Ajax4jsf. Annotations and convention-over-configuration enhancements were introduced to killthe verbose faces-config.xmlfile as much as possible. Also, the default naming container ID separator character :became configurable, so HTML/CSS purists could breathe relieved. All you need to do is to define it as init-paramin web.xmlwith the name javax.faces.SEPARATOR_CHARand ensuring that you aren't using the character yourself anywhere in client ID's, such as -.

Ajax 功能是在<f:ajax>组件的风格中引入的，它与 Ajax4jsf 有很多相似之处。注释和约定优于配置的增强被引入杀冗长的faces-config.xml文件尽可能。此外，默认命名容器 ID 分隔符:变得可配置，因此 HTML/CSS 纯粹主义者可以松一口气。所有你需要做的是将其定义init-param中web.xml的名称javax.faces.SEPARATOR_CHAR，你是不是自己使用的角色在任何地方的客户端ID的，比如和保证-。

Last but not least, a new scope was introduced, the viewscope. It eliminated another major JSF 1.x disadvantage as described before. You just declare the bean @ViewScopedto enable the conversation scope without hassling all ways to retain the data in subsequent (conversational) requests. A @ViewScopedbean will live as long as you're subsequently submitting and navigating to the same view (independently of the opened browser tab/window!), either synchronously or asynchronously (Ajax). See also Difference between View and Request scope in managed beansand How to choose the right bean scope?

最后但并非最不重要的是，引入了一个新的作用域，即视图作用域。如前所述，它消除了另一个主要的 JSF 1.x 缺点。您只需声明 bean@ViewScoped即可启用对话范围，而无需在后续（对话）请求中使用所有方法来保留数据。一个@ViewScoped只要bean将居住作为你随后提交并导航到同一个视图（独立打开浏览器标签/窗口！），同步或异步（阿贾克斯）。另请参阅托管 bean 中视图和请求范围之间的差异以及如何选择正确的 bean 范围？

Although practically all disadvantages of JSF 1.x were eliminated, there are JSF 2.0 specific bugs which might become a showstopper. The @ViewScopedfails in tag handlersdue to a chicken-egg issue in partial state saving. This is fixed in JSF 2.2 and backported in Mojarra 2.1.18. Also passing custom attributes like the HTML5 data-xxxis not supported. This is fixed in JSF 2.2 by new passthrough elements/attributes feature. Further the JSF implementation Mojarra has its own set of issues. Relatively a lot of them are related to the sometimes unintuitive behaviour of <ui:repeat>, the new partial state saving implementationand the poorly implemented flash scope. Most of them are fixed in a Mojarra 2.2.x version.

尽管实际上 JSF 1.x 的所有缺点都被消除了，但仍有一些 JSF 2.0 特定的错误可能会成为一个大问题。将@ViewScoped在标签处理失败是由于部分国家储蓄鸡-蛋的问题。这在 JSF 2.2 中得到修复并在 Mojarra 2.1.18 中向后移植。还通过自定义属性像HTML5data-xxx不支持。这在 JSF 2.2 中已通过新的传递元素/属性功能修复。此外，JSF 实现 Mojarra 有其自身的一系列问题。它们中的大部分都与有时不直观的行为<ui:repeat>、新的部分状态保存实施和实施不佳的闪存范围有关。它们中的大多数在 Mojarra 2.2.x 版本中得到修复。

Around the JSF 2.0 time, PrimeFaceswas introduced, based on jQuery and jQuery UI. It became the most popular JSF component library.

大约在 JSF 2.0 时代，引入了PrimeFaces，基于 jQuery 和 jQuery UI。它成为最流行的 JSF 组件库。

JSF 2.2 (May 2013)

JSF 2.2（2013 年 5 月）

With the introduction of JSF 2.2, HTML5 was used as buzzword even though this was technically just supported in all older JSF versions. See also JavaServer Faces 2.2 and HTML5 support, why is XHTML still being used. Most important new JSF 2.2 feature is the support for custom component attributes, hereby opening a world of possibilities, such as custom tableless radio button groups.

随着 JSF 2.2 的引入，HTML5 被用作流行语，尽管这在技术上只在所有旧的 JSF 版本中得到支持。另请参阅JavaServer Faces 2.2 和 HTML5 支持，为什么仍然使用 XHTML。最重要的 JSF 2.2 新特性是对自定义组件属性的支持，从而开启了一个充满可能性的世界，例如自定义无表单选按钮组。

Apart from implementation specific bugs and some "annoying little things" such as inability to inject an EJB in a validator/converter (already fixed in JSF 2.3), there are not really major disadvantages in the JSF 2.2 specification.

除了实现特定的错误和一些“烦人的小事情”，例如无法在验证器/转换器中注入 EJB（已在 JSF 2.3 中修复）之外，JSF 2.2 规范中并没有真正的主要缺点。

Component based MVC vs Request based MVC

基于组件的 MVC 与基于请求的 MVC

Some may opt that the major disadvantage of JSF is that it allows very little fine-grained control over the generated HTML/CSS/JS. That's not JSF's own, that's just because it's a component basedMVC framework, not a request (action) basedMVC framework. If a high degree of controlling the HTML/CSS/JS is your major requirement when considering a MVC framework, then you should already not be looking at a component based MVC framework, but at a request based MVC framework like Spring MVC. You only need to take into account that you'll have to write all that HTML/CSS/JS boilerplate yourself. See also Difference between Request MVC and Component MVC.

有些人可能会认为 JSF 的主要缺点是它几乎不允许对生成的 HTML/CSS/JS 进行细粒度控制。那不是 JSF 自己的，那只是因为它是基于组件的MVC 框架，而不是基于请求（操作）的MVC 框架。如果在考虑 MVC 框架时对 HTML/CSS/JS 的高度控制是您的主要要求，那么您不应该考虑基于组件的 MVC 框架，而应该考虑基于请求的 MVC 框架，例如Spring MVC。您只需要考虑到您必须自己编写所有 HTML/CSS/JS 样板。另请参阅请求 MVC 和组件 MVC 之间的差异。

See also:

也可以看看：

• What is the difference between JSF, Servlet and JSP?(just to understand the basics)
• Using JSF to develop tableless CSS layouts(another myth about JSF)
• JSF vs plain HTML/CSS/JS/jQuery(when JSF is the wrong choice)
• Design patterns in web applications(illustrates the ideology behind MVC)

• JSF、Servlet 和 JSP 之间有什么区别？（只是为了了解基础知识）
• 使用 JSF 开发无表 CSS 布局（关于 JSF 的另一个神话）
• JSF 与纯 HTML/CSS/JS/jQuery（当 JSF 是错误的选择时）
• Web 应用程序中的设计模式（说明了 MVC 背后的意识形态）

回答by G. Demecki

After 5 years of working with JSF, I think that I can add my 2 cents.

在与 JSF 合作 5 年后，我认为我可以增加我的 2 美分。

Two major JSFdrawbacks:

JSF 的两个主要缺点：

1. Big learning curve. JSF is complex, that's just true.
2. Its componentnature. 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.

1. 学习曲线大。JSF 很复杂，这是真的。
2. 其成分性质。基于组件的框架试图隐藏 Web 的真实本质，这带来了大量的复杂性和灾难（比如在近 5 年内不支持 JSF 中的 GET）。
   恕我直言，向开发人员隐藏 HTTP 请求/响应是一个巨大的错误。根据我的经验，每个基于组件的框架都为 Web 开发增加了抽象，而这种抽象会导致不必要的开销和更高的复杂性。

And minordrawbacks that come to my mind:

而较小的浮现在我的脑海缺点：

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

1. 默认情况下，对象的 ID 由其父 ID 组成，例如 form1:button1。
2. 没有简单的方法来注释掉不正确的页面片段。标签<ui:remove>需要语法正确的内容，无论如何都会被解析。
3. 低质量的第 3 方组件，例如在继续之前不检查isRendered()内部processXxx()方法。
4. 合并 LESS & Sencha 很难。
5. 不适合 REST。
6. 对于 UX 设计人员来说并不容易，因为现成的组件有自己的 CSS 样式，需要覆盖。

Don't get me wrong. As a component framework JSF in version 2 is really good, but it's still component-based, and always will be...

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

Please take a look at the low popularity of Tapestry, Wicket and low enthusiasm of experienced JSF developers (what is even more meaningful). And for contrast, take a look at the success of Rails, Grails, Django, Play! Framework - they all are action-based and don't try to hide from the programmer true request/responseand stateless natureof the web.

请看一下Tapestry、Wicket 的低知名度和有经验的JSF 开发人员的低热情（更有意义的是什么）。相比之下，看看 Rails、Grails、Django、Play 的成功案例！框架——它们都是基于动作的，不会试图向程序员隐藏真正的请求/响应和网络的无状态性质。

For me it's major JSF disadvantage. IMHO JSF can suits some type of applications (intranet, forms-intensive), but for real-life webapplication it's not a good way to go.

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

Hope it helps somebody with his/her choices that regards to front-end.

希望它可以帮助某人做出有关前端的选择。

回答by Kay Pale

A few drawbacks that pop to mind:

想到的几个缺点：

1. JSF is a component-based framework. This has inherent restrictions that have to do with obeying the component-model.
2. AFAIK JSF supports only POST, so if you want a GET somewhere you have to do a plain servlet/JSP.
3. 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.
4. 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.
5. 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.
6. 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.

1. JSF 是一个基于组件的框架。这具有与遵守组件模型有关的固有限制。
2. AFAIK JSF 仅支持 POST，因此如果您想在某处使用 GET，您必须执行一个普通的 servlet/JSP。
3. 大多数组件都试图提供对关系数据库和前端 JavaScript 等域的抽象，而且很多时候这些抽象是“有漏洞的”并且很难调试。
4. 对于初级开发人员或不熟悉特定领域（例如前端 JavaScript）的人来说，这些抽象可能是一个很好的起点，但很难优化性能，因为涉及多个层，而且大多数人都使用它们对引擎盖下发生的事情知之甚少。
5. 通常与 JSF 一起使用的模板机制与 Web 设计器的工作方式无关。JSF 的 WYSIWYG 编辑器是原始的，在任何情况下，您的设计师都会为您提供 HTML/CSS，您将不得不花费很长时间进行转换。
6. 诸如 EL 表达式之类的东西不是静态检查的，编译器和 IDE 都没有在发现错误方面做得很好，因此您最终会遇到必须在运行时捕获的错误。这对于像 Ruby 或 PHP 这样的动态类型语言来说可能没问题，但是如果我必须承受 Java 生态系统的绝对膨胀，我需要为我的模板打字。

To sum up:The time you will save with JSF, from avoiding to write the JSP/servlet/bean boilerplate code, you'll spent it x10 to make it scale and do exactly what you want it to do.

总结一下：使用 JSF 节省的时间，从避免编写 JSP/servlet/bean 样板代码，您将花费 x10 倍以使其可扩展并完全按照您的意愿去做。

回答by AlanObject

To me the biggest disadvantage of JSF 2.0 is the learning curve not only of JSF, but the component libraries that you have to use in order to get it to do useful work. Consider the staggering number of specifications and standards you have deal with to really be proficient:

对我来说，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.

• 各种形式的 HTML。不要假装你不需要知道它。
• HTTP——当您无法弄清楚发生了什么时，您必须打开 Firebug 并查看。为此，您需要了解这一点。
• CSS——喜欢与否。它真的没有那么糟糕，至少有一些不错的工具。
• XML —— JSF 可能是您在这种程度上使用命名空间的第一个地方。
• 小服务程序规范。迟早你会开始调用这个包中的方法。除此之外，您还必须知道您的 Facelets 是如何变成 XHTML 之类的。
• JSP（主要是为了让您知道为什么在 JSF 中不需要它）
• JSTL（同样，主要是为了应对遗留框架）
• 各种形式的表达式语言 (EL)。
• ECMAScript、JavaScript 或其他任何您想称呼它的东西。
• JSON——即使你不使用它，你也应该知道这一点。
• 阿贾克斯。我会说 JSF 2.0 在向您隐藏这一点方面做得不错，但您仍然需要知道发生了什么。
• DOM。以及浏览器如何使用它。请参阅 ECMAScript。
• DOM 事件——一个单独的主题。
• Java Persistence Architecture (JPA)，如果您希望您的应用程序具有任何后端数据库。
• Java本身。
• JSEE，而你在它。
• 上下文依赖注入规范 (CDI) 以及它如何与 JSF 2.0 发生冲突以及如何与 JSF 2.0 一起使用
• JQuery——我希望看到你在没有它的情况下也能相处。

Now, once you are done with that you can get on with the proprietary specifications, namely the component libraries and provider libraries you will pick up along the way:

现在，一旦完成，您就可以继续使用专有规范，即您将沿途选择的组件库和提供程序库：

• PrimeFaces (my component library of choice)
• RichFaces
• MyFaces
• ICEFaces
• EclipseLink (my JPA Provider)
• Hibernate
• Weld

• PrimeFaces（我选择的组件库）
• 富人脸
• 我的脸
• 冰面
• EclipseLink（我的 JPA 提供程序）
• 休眠
• 焊接

And don't forget the container! And all those configuration files:

并且不要忘记容器！以及所有这些配置文件：

• GlassFish (2, 3, etc)
• JBoss
• Tomcat

• GlassFish（2、3 等）
• 老板
• 雄猫

So -- THIS IS MAKING IT EASY? Sure, JSF 2.0 is "easy" as long as all you want to do is the most basic web pages with the simplest interactions.

所以 - 这让它变得容易了吗？当然，JSF 2.0 是“简单的”，只要您想做的只是具有最简单交互的最基本的网页。

Simply put, JSF 2.0 is the most complicated and cumbersome mishmash of glued together technologies as exists in the software universe today. And I can't think of anything I would rather use.

简而言之，JSF 2.0 是当今软件世界中存在的最复杂和最麻烦的粘合技术大杂烩。而且我想不出任何我宁愿使用的东西。

回答by Koks Skirtumas

1. Inexperienced developers usually will create applications that are painfully slow and code will be really ugly and hard to maintain. Its deceptively simple to start, but actually requires some investment in learning if you want to write good programs.
2. At least at the start you will often "stuck" on some problem and will spend more time reading balusc posts on internet than actually working :) After a while it will be less and less of that, but it still can be annoying.
3. Even more annoying when you find out that the problem is not due to you lack of knowledge/mistake but actually a bug. Mojarra was(is?) quite buggy, and another layer of components adds even more problems. Richfaces was biggest piece of crap software ever written :) Don't know how it is now on version 4. We have Primefaces which is better, but still you will run into bugs or lack of features especially with more exotic components. And now you will need to pay for Primefaces updates. So I would say its buggy but its getting better especially after 2.2 version fixed some problems with spec. Framework getting more mature but still far from perfect (maybe myfaces better?).
4. I don't find it especially flexible. Often if you need something very very customized and there are no components that does that - it will be a bit painful. Again I'm talking from average developer perspective - the one with deadlines, quick reading tutorials, and searching stackoverflow when getting stuck because no time to learn how it really works :) Often some components seems to have "almost" what you need, but not exactly and sometimes you might spend too much time to make it do something you want :) Need to be careful in evaluating if its better to create your own or torture existing component. Actually if you are creating something really unique I would not recommend JSF.

1. 缺乏经验的开发人员通常会创建非常缓慢的应用程序，并且代码非常丑陋且难以维护。它的开始看似简单，但如果您想编写好的程序，实际上需要在学习上进行一些投资。
2. 至少在开始时，您经常会“卡住”在某些问题上，并且会花更多的时间阅读互联网上的 balusc 帖子而不是实际工作:) 一段时间后，这种情况会越来越少，但仍然很烦人。
3. 当您发现问题不是由于您缺乏知识/错误而实际上是一个错误时，就更烦人了。Mojarra 过去（是？）有很多问题，另一层组件增加了更多问题。Richfaces 是有史以来最大的垃圾软件 :) 不知道它现在在第 4 版上如何。我们有更好的 Primefaces，但您仍然会遇到错误或缺乏功能，尤其是使用更多奇特组件时。现在您需要为 Primefaces 更新付费。所以我会说它有问题，但它变得更好，尤其是在 2.2 版本修复了规范的一些问题之后。框架越来越成熟，但还远非完美（也许 myfaces 更好？）。
4. 我觉得它不是特别灵活。通常，如果您需要非常非常定制的东西并且没有组件可以做到这一点 - 这会有点痛苦。我再次从普通开发人员的角度进行讨论 - 有截止日期，快速阅读教程以及在陷入困境时搜索 stackoverflow 的人，因为没有时间了解它的真正工作原理:) 通常，某些组件似乎“几乎”拥有您需要的东西，但是不完全是，有时您可能会花费太多时间让它做您想做的事情:) 需要小心评估创建自己的组件或折磨现有组件是否更好。实际上，如果您正在创建真正独特的东西，我不会推荐 JSF。

So in short my drawbacks would be: Complexity, Not very smooth development progress, buggy, inflexible.

所以简而言之，我的缺点是：复杂，开发进度不是很顺利，有问题，不灵活。

Of course there are advantages too, but that's not what you asked. Anyway that's my experience with framework others might have different opinions, so best way is to just try it for a while to see if its for you (just something more complex - not naive examples - JSF really shines there:) IMHO best use case for JSF is business applications, like CRMs etc...

当然也有优点，但这不是你问的。无论如何，这是我对框架的经验，其他人可能会有不同的意见，所以最好的方法是尝试一段时间，看看它是否适合你（只是更复杂的东西 - 不是天真的例子 - JSF 真的很出色：）恕我直言，最好的用例JSF 是业务应用程序，例如 CRM 等...

回答by Jesús López

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.

我根本不是 Java Server Faces 专家。但恕我直言，主要缺点是它是服务器端。我厌倦了学习和使用服务器端 Web 表示层框架，如 ASP.NET Web Forms、ASP.NET MVC、Java Server Faces、Struts、php 框架和 ruby​​ on rails 框架。我和他们说再见，我向 Angularjs 和 TypeScript 打招呼。我的表示层在浏览器上运行。不管它是由运行 php 或 ASP.NET 的 Windows IIS 提供服务，还是由运行在 Linux 上的 Apache Web 服务器提供服务。我只需要学习一个适用于任何地方的框架。

Just my two cents.

只有我的两分钱。

回答by Cagatay Civici

"JSF will output View-layer HTML and JavaScript that you cannot control or change without going into Controller code."

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

Actually JSF gives you the flexibility, you can either use standard/third-party components or create your own which you have full control over what is rendered. It is just one xhtml you need to create your custom components with JSF 2.0.

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

回答by Alireza Fattahi

We developed a sample project with JSF (It was a three week research so we may have lose some things!)

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

We try to use core jsf, if a component is needed we used PrimeFaces.

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

The project was a web site with navigation. Each page should be loaded via ajax when the menu is clicked.

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

The site has two usecases:

该站点有两个用例：

1. A page with a grid. The grid is loaded via ajax and should support sort and paging
2. A three step wizard page. Each page has client side validation (for simple validations) and server side ajax base validation (for complex validations). Any server exception ( from service layer) should be displayed on the same page of wizard without navigating to next page.

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

We found that:

我们发现：

1. 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).
2. 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.
3. 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.
4. We try to do some client scripts when ajax complete by ajaxCompleteand we found that the PF 4 has implemented its own ajax events. We had some jQuery components and we need to change their code.

1. 您需要使用 omniFaces 的一些技巧来修复 JSF 视图状态。当您通过 ajax 相互包含页面时，JSF 状态将被破坏。这似乎是 JSF 中的一个错误，可能会在下一个版本（不是 2.3）中修复。
2. JSF Flow 与 ajax 无法正常工作（或者我们无法使其工作！）我们尝试使用 primeface 向导组件，但似乎不支持客户端验证，这意味着它不是标准的 JSF 流标准。
3. 当使用jqGird等一些jQuery组件，需要加载JSON结果时，建议使用纯servlet，JSF不会为你做任何事情。因此，如果您使用这些类型的组件，您的设计将不适合 JSF。
4. 我们尝试在 ajax 完成时做一些客户端脚本ajaxComplete，我们发现 PF 4 已经实现了自己的 ajax 事件。我们有一些 jQuery 组件，我们需要更改它们的代码。

If you change the above sample to a non Ajaxproject ( or at least less ajax project) you will not face lots of above issues.

如果您将上述示例更改为非 Ajax项目（或至少更少的 ajax 项目），您将不会遇到上述许多问题。

We summarize our research as:

我们总结我们的研究如下：

JSF is not working well in an fully ajax base website.

JSF 在完全基于 ajax 的网站中运行不佳。

Of course we find lots of nice features in JSF which may be very helpful in some projects, so consider your project needs.

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

Please refer to JSF technical documents to review JSF advantages, and in my opinion the biggest advantage of JSF, is the COMPLETE AND HUGE support from @BalusC ;-)

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

回答by Ondrej Bozek

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 最大的缺点是对以编程方式（动态）生成的页面的支持很差。
如果要从 Java 代码动态构建页面（创建页面组件模型）。例如，如果您正在使用 WYSIWYG 网页构造函数。此用例的充分文档通常不可用。有很多地方您必须进行试验，而开发却非常缓慢。很多事情并不像你期望的那样工作。但通常它可能以某种方式破解它。
好消息是这在 JSF 的哲学或体系结构中不是问题。它只是不够详细（据我所知）。

JSF 2 brought Composite Components which should make component development easy, but their support for dynamic (programmatic) construction is very poor. If you overcome quiet complicated and almost undocumented process of dynamic Composite Component construction, you will find out that If you nest few Composite components little deeper, they stop working, throwing some exceptions.

JSF 2 带来了复合组件，这应该使组件开发变得容易，但是它们对动态（程序化）构造的支持非常差。如果您克服了动态复合组件构建的安静复杂且几乎未记录的过程，您会发现如果您将几个复合组件嵌套得更深一些，它们将停止工作，并抛出一些异常。

But It seems that JSF community is aware of this shortcomings. They are working on this as you can see from these two bugs
http://java.net/jira/browse/JAVASERVERFACES-1309
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-599

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

Situation should be better with JSF 2.2 at least if we are talking about specification.

至少在我们谈论规范时，JSF 2.2 的情况应该更好。

回答by rprasad

Commenting on my last few months of Primefaces/JSF experience:

评论我最近几个月的 Primefaces/JSF 体验：

• If you can use components "off the shelf", I guess it's not terrible.
• However, it doesn't play well as soon as you step outside and need custom UIs. - For example, we needed to use Twitter's bootstrap for our project. (Not primefaces bootstrap).
  • Now our pages work as follows:
    • Page loads.
    • User interacts with a Primefaces that has ajax functionality
    • Bootstrap's javascript bindings break
    • We run extra javascript to rebind everything

• 如果您可以使用“现成的”组件，我想这并不可怕。
• 但是，一旦您走出去并需要自定义 UI，它就不能很好地发挥作用。- 例如，我们需要为我们的项目使用 Twitter 的引导程序。（不是primefaces bootstrap）。
  • 现在我们的页面工作如下：
    • 页面加载。
    • 用户与具有 ajax 功能的 Primefaces 交互
    • Bootstrap 的 javascript 绑定中断
    • 我们运行额外的 javascript 来重新绑定所有内容

The promise of JSF to avoid writing javascript turned into writing more javascript than we would have if not using Primefaces--and that javascript to is fix what Primefaces breaks.

JSF 避免编写 javascript 的承诺变成了编写比我们不使用 Primefaces 时更多的 javascript——而 javascript 修复了 Primefaces 的问题。

It's a time sink--unless you again use "off the shelf" stuff. Also really ugly (Primefaces) when having to work with Selenium. It can all be done--but again--there's only so much time.

这是一个时间槽——除非你再次使用“现成的”东西。不得不使用 Selenium 时也非常丑陋（Primefaces）。这一切都可以完成——但再说一遍——时间有限。

Definitely avoid this if you're working with a UX/design team and need to rapidly iterate on the UI--you can save time by learning jquery/writing straight HTML--or looking at react/angular.

如果您正在与 UX/设计团队合作并且需要在 UI 上快速迭代，请绝对避免这种情况——您可以通过学习 jquery/直接编写 HTML——或查看 react/angular 来节省时间。