当用 jQuery 和 AngularJS 这样的 JavaScript 库可以实现 UI 时，JSF 的需求是什么

小开

创建 JSF 是为了让 Java 商店不必学习 jQuery 之类的东西，也不必构建复杂的 JS，而是专注于纯 Java 堆栈。在一个时间就是金钱的世界里，很多地方已经把精力集中在 Java 开发上，少一个语言/片段可以使培训和维护更快，因此更便宜。

我还要补充一点，JavaScript 很容易成为大型团队的维护噩梦，特别是如果项目中的一些开发人员不是很精通 web 的话。

小开

最佳答案

JSF 变成纯 JSP/Servlet/HTML/CSS/JS 就像 jQuery 变成纯 JS: 用更少的代码做更多的事情。以 PrimeFaces(jQuery + jQuery UI based)为例，浏览它的演出以查看完整的代码示例。靴子脸(基于 jQuery + Bootstrap UI)也有一个带有完整代码示例的 showcase。如果仔细研究这些示例，就会发现基本上需要一个简单的 Javabean 类作为模型，一个 XHTML 文件作为视图。

注意，您不应该将 JSF 视为单独的 HTML/CSS/JS 的替代品，还应该考虑服务器端部分(特别是: JSP/Servlet)。JSF 消除了收集 HTTP 请求参数、转换/验证它们、更新模型值、执行正确的 Java 方法来处理业务以及生成 HTML/CSS/JS 样板代码的所有样板需求。使用 JSF，您基本上最终会得到一个 XHTML 页面作为视图定义，一个 Javabean 类作为模型定义。这大大加快了发展速度。

与每个基于组件的 Web MVC 框架一样，您在 JSF 中对呈现的 HTML/CSS/JS 具有较少的细粒度控制。添加自定义 JS 代码并不是那么容易，因为您还必须考虑到服务器端的 JSF 视图状态(例如，在 JS 端启用禁用按钮不会在 JSF 端启用按钮，这反过来又是一个巨大的安全优势)。然而，如果这是一个主要的亮点，那么更应该寻找一个基于动作的 web MVC 框架，如春季 MVC。您只需考虑必须编写所有 HTML/CSS/JS 代码(以及防止 XSS、 CSRF 和 DOM 操作!)你自己.此外，如果您从 Facelets 退回到 jSP，您也将错过高级模板功能。

另一方面，如果你有一个大的基于 JSP/Servlet/HTML/CSS/JS/jQuery 的网站，你想重构重复的 JSP/Servlet/HTML/CSS/JS/jQuery 样板代码到可重用的组件中，那么一个解决方案就是 JSF。自定义模板、标签文件和组件可以帮助实现这一点。从这个角度来看，JSF 高于 JSP/Servlet/HTML/CSS/JS/jQuery (这也是为什么在深入研究 JSF 之前理解这些基础知识非常重要)。

您可以在这里找到一个基于 JSF 的真实世界启动项目: Java EE 启动应用程序。你会看到它包含旁边的 JSF作为良好的 HTML5，CSS3和 JQuery。

参见:

小开

有了 Javascript 和 jQuery 这样的框架，您就拥有了完全的灵活性和完全的控制权。使用 ext 等，你会失去很多控制，必须适应框架。对于 JSF，您完全失去了控制，必须完全适应框架。您在生命周期等中被调用，最后您无法控制何时可以调用服务器，何处不可以调用。如果你要做一些被认为是“特别”的事情，你的处境会非常困难。在 JSF 世界中，即使是像多列表排序或者只能输入有限字符集的字段(比如数字字段)这样的基本事情也被认为是“特殊的”。

然而，您拥有的灵活性越多，您可能犯的错误或不良实践就越多。高灵活性只适用于高智商的程序员，其他人会把项目变成无法管理的噩梦。

但是，由于 JSF 及其有限的灵活性，总是只有几种(甚至只有一种)正确的方法来做某些事情。你是非常有限的，你不能使快捷方式，你必须编写更多的 XML 等等-但是当适应标准，有更好的控制代码，没有经验或低技能的程序员将生产。因此，大公司喜欢 JSF，因为它对他们来说更“安全”。

当我从 GWT 转移到 JSF 时，我很震惊，有多少对我来说很自然的事情，被认为是非常不典型的，有多少简单的事情是如此难以实现。更重要的是，即使是最小的改变，比如添加“ :”标签，在 GWT/jQuery 驱动的应用程序将改变一个函数生成标签，需要改变几十个本地化属性的文件，这甚至没有被任何人考虑，除了我奇怪..。

小开

使用 JSF 的好处不仅在于生成 xhtml + css + js。有时候 JSF 会对您可以生成的标记施加限制，就像任何基于组件的框架一样。但是 JSF 不仅仅是为了这个，它的生命周期帮助很大。在验证输入之后，它可以不费吹灰之力地更新模型并同步服务器端 bean。你只需要说“不管用户在这里输入什么，检查它是否是一个数字，如果是，然后将它存储在对象 XX 的属性广州欢聚时代中”，JSF 就可以做到这些。

因此，是的，您仍然可以使用 JQuery、 JS 等。但是，当涉及到编写服务器端代码时，JSF 提供了许多好处，并使您避免了大量繁琐的工作。

小开

我强烈反对 jsf 添加任何东西。这只会增加开销。在服务器上做 UI 是我听过的最荒谬的事情。在大型团队中，javascript 工作得很好——它被称为重用代码。

只需将 jquery 包装在一些 jsp 标记中，这就是您所需要做的全部工作，并且不要忍受.jsf 和 richfaces 带来的.hamles 和可伸缩性问题。

小开

在使用过 JSF、 Spring MVC、 Struts、 Grails、 JQuery 和 ExtJS 之后，我认为 Grails + ExtJS 是一个强大的组合。

我会选择 Grails 而不是 JSF。我喜欢 ExtJS 作为客户端框架和库的完整性，但它的学习曲线比 JQuery 更陡峭。

小开

我已经在一个大型 Web 应用程序中使用过 ExtJS 框架，我知道它是多么容易使用。ExtJS (Schena)最适合于(Oracle 11g) MVC 体系结构中的数据库交互。视图用于视觉/用户交互。控制器指定了 PLSQL 包(用于 CRUD 的 API，SQL 选择查询等)中需要使用的“处理”和触发器。使用 Model 和存储文件将数据项“映射”到 Viewer/input。

ExtJS 不适用于非数据库密集型的 Web 界面——角形 JS 可能更适合这种情况。

小开

下面是 jQuery 和 JSF 之间最大的区别:

no MVC architecture
no state control (store date in session or conversation, auto-clean up, etc.)
无(默认)验证库
没有模板库
没有高级导航/路由
客户端

jQuery was never intended to be used as a full stack webframework. It was more intended for replacing low-level JS code so that writing JS becomes easier and more powerfull in less lines of code.

因此，它应该主要用于添加 HTML 元素上的行为。