当 UI 可以通过 jQuery 和 AngularJS 等 JavaScript 库实现时，还需要 JSF 吗？
我读到有关 JSF 的内容，它是一个 UI 框架并提供了一些 UI 组件。但它与 jQueryUI、AngularJS、React、Vue.js、Svelte、ExtJS，甚至纯 HTML、CSS 和 JavaScript 中提供的许多组件相比有何更好或不同之处。
为什么要学习 JSF？
I was reading about JSF that it's a UI framework and provides some UI components. But how is it better or different from number of components that are available from jQueryUI, AngularJS, React, Vue.js, Svelte, ExtJS, or even plain HTML, CSS and JavaScript.
Why should someone learn JSF?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
JSF 到普通 JSP/Servlet/HTML/CSS/JS 就像 jQuery 到普通 JS：用更少的代码做更多的事情。以 PrimeFaces （基于 jQuery + jQuery UI）为例，浏览其 showcase 查看完整的代码示例。 BootsFaces （基于 jQuery + Bootstrap UI）还有一个 展示 以及完整的代码示例。如果您仔细研究这些示例，您就会发现您基本上需要一个简单的 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 框架，例如 Spring 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 Kickoff App。您会看到它旁边包含 JSF 一样好 HTML5，CSS3 和 jQuery。
另请参阅：
JSF to plain JSP/Servlet/HTML/CSS/JS is like as jQuery to plain JS: do more with less code. To take PrimeFaces (jQuery + jQuery UI based) as an example, browse through its showcase to see complete code examples. BootsFaces (jQuery + Bootstrap UI based) has also a showcase with complete code examples. If you study those examples closely, then you'll see that you basically need a simple Javabean class as model and a XHTML file as view.
Note that you should not see JSF as replacement of alone HTML/CSS/JS, you should also take the server side part into account (specifically: JSP/Servlet). JSF removes the need of all the boilerplate of gathering HTTP request parameters, converting/validating them, updating the model values, executing the right Java method to do the business stuff and generating the HTML/CSS/JS boilerplate code. With JSF you basically end up with a XHTML page as view definition and a Javabean class as model definition. This greatly speeds up development.
As with every component based web MVC framework, you have in JSF less fine-grained control over the rendered HTML/CSS/JS. Adding custom JS code isn't that easy as you have to take the JSF view state in the server side into account as well (e.g. enabling a disabled button in JS side won't enable the button in JSF side, which is in turn a huge security advantage). If that is however a major showstopper, then rather look for an action based web MVC framework like Spring MVC. You'll only take into account that you have to write all that HTML/CSS/JS code (and prevention against XSS, CSRF and DOM-manipulation!) yourself. Also if you fall back from Facelets to JSP, you'll miss advanced templating capabilities as well.
On the other hand, if you have a big JSP/Servlet/HTML/CSS/JS/jQuery based website and you'd like to refactor the repeated JSP/Servlet/HTML/CSS/JS/jQuery boilerplate code into reusable components, then one of the solutions would be JSF. Custom templates, tagfiles and components can aid in this. In that perspective, JSF stands above JSP/Servlet/HTML/CSS/JS/jQuery (and that's also why it's pretty important to understand those basics before diving into JSF).
You can find a real world kickoff JSF based project here: Java EE Kickoff App. You'll see that it contains next to JSF as good HTML5, CSS3 and jQuery.
See also:
JSF 的创建是为了让 Java 商店不必学习 jQuery 之类的东西并构建复杂的 JS，而是专注于纯粹的 Java 堆栈。在时间就是金钱的世界里，很多地方已经专注于 Java 开发，堆栈中少一种语言/片段可以使培训和维护更快，从而更便宜。
我要补充的是，JavaScript 很容易成为大型团队的维护噩梦，特别是如果项目中的某些开发人员不太精通 Web。
JSF was created to make it so that java shops didn't have to learn stuff like jQuery and build complex JS but instead focus on a purely Java stack. In a world where time is money and lots of places already focusing on Java development, one less language/piece in the stack makes training and maintaining faster and thus cheaper.
I'll add that JavaScript is easy to become a maintenance nightmare on large teams, especially if some of the developers on the project are not highly web savvy.
借助 Javascript 和 jQuery 等框架，您可以拥有完全的灵活性和完全的控制权。使用 ext 等你会失去很多控制权并且必须适应框架。使用 JSF，您将完全失去控制，并且必须完全适应该框架。您在生命周期等中被调用，最终您无法控制何时可以对服务器进行调用，何时不能进行。如果你要做一些被认为“特别”的事情，你的处境就会非常困难。在 JSF 世界中，甚至诸如多列表排序或只能键入有限字符集的字段（例如数字字段）之类的基本事物也被视为“特殊”。
然而，你的灵活性越大，你可能犯的错误或不好的做法就越多。高灵活性只适用于高度聪明的程序员，其他人会把项目变成难以管理的噩梦。
但是，由于 JSF 及其有限的灵活性，总是只有几种（甚至只有一种）正确的方法来做某事。你的能力非常有限，你不能走捷径，你必须编写更多的 XML 等等 - 但是当适应标准时，可以更好地控制没有经验或低技能的程序员将生成的代码。因此，大公司喜欢 JSF，因为它对他们来说“更安全”。
当我从 GWT 转向 JSF 时，我感到震惊，有多少对我来说很自然的事情被认为是非常不典型的，有多少简单的事情很难实现。更重要的是，即使进行最小的更改，例如在标签后添加“：”符号，在 GWT/jQuery 支持的应用程序中，这将更改一个生成标签的函数，需要更改数十个具有本地化属性的文件，而这甚至没有被考虑到除了我，谁都奇怪……
With Javascript and frameworks such as jQuery you have full flexibility and full control . With ext's etc you lose much control and must adapt to the framework. With JSF you totally lose control and must totally adapt to the framework. You're invoked in lifecycles etc. and finally you have no control when the call to the server can be made and where not. If you are to do something considered 'special', you're in very hard position. And in JSF world even such basic things as multicolumn table sort or fields where you can type only limited set of characters (such as number field) are considered 'special'.
However, the more flexibility you have, the more errors or bad practices you can made. High flexibility works only with highly intelligent programmers, others will turn the project into unmanagable nightmare.
But, with JSF and its limited flexibility, there's always only a few (or even only one) correct way to do something. You are very limited, you can't make shortcuts, you must write more XML etc. - but when adapting to standard, there's better control on the code the unexperienced or low-skilled programmers will produce. As a result, big corporations love JSF because it is 'safer' for them.
When I moved from GWT to JSF, I was shocked, how many things, that was natural to me, was considered highly untypical and how much simple things were so hard to achieve. What's more, even making the smallest changes, such as adding ':' sign after label, which in GWT/jQuery powered app would be changing one function generating label, required changing dozens of files with localized properties, which wasn't even considered by anyone except me strange...
使用JSF的好处不仅仅在于生成xhtml + css + js。有时，JSF 会对您可以生成的标记施加限制，就像任何基于组件的框架一样。但 JSF 不仅仅用于此目的，它的生命周期也有很大帮助。验证输入后，它可以毫不费力地更新模型并同步服务器端 bean。你只需说“无论用户在这里输入什么，检查它是否是一个数字，如果是，则将其存储在对象 XX 的属性 YY 中”，JSF 将完成所有这些工作。
所以，是的，您仍然可以使用 JQuery、JS 等。但是 JSF 在编写服务器端代码方面提供了许多好处，并且使您免于大量样板代码。
The benefits of using JSF are not only in generating xhtml + css + js. Sometimes JSF imposes a restriction on the markup you can generate, like any component based framework. But JSF is not just for that, its lifecyle helps greately. After validating the input it can update the model and sync your server side beans without any effort. you just say "whatever the user types here, check if it's a number, if yes then store it in the property YY in object XX" and JSF will do all that.
So yes, you can still use JQuery, JS, etc. But JSF provides many benefits when it comes to writing server side code and saves you from a lot of boiler plate.
我强烈不同意 jsf 添加任何内容。它只会增加开销。在服务器上做用户界面的事情是我听过的最荒谬的事情。 javascript 在大型团队中效果很好 - 这称为重用代码。
只需将 jquery 包装在一些 jsp 标签中，这就是您所需要的一切，并且您已经完成了，并且不必忍受 .jsf 和 richfaces 的 .shackles 和可扩展性问题。
I strongly disagree that jsf adds anything. It only adds overhead. Doing ui stuff on the server is the most ridiculous thing ive ever heard. And javascript on large teams works great - its called reusing code.
Just wrap the jquery in some jsp tags, thats all you need and youre done, and dont endure the.shackles and scalability issues with.jsf and richfaces.
在使用过 JSF、Spring MVC、Struts、Grails、JQuery 和 ExtJS 后，我认为 Grails + ExtJS 是一种强大的组合。
任何时候我都会选择 Grails 而不是 JSF。我喜欢 ExtJS 作为客户端框架和库的完整性，但它的学习曲线比 JQuery 更陡峭。
Having worked with JSF, Spring MVC, Struts, Grails, JQuery, and ExtJS my opinion is that Grails + ExtJS is one powerful combination.
I would pick Grails over JSF any day. I like the completeness of ExtJS as the client side framework and library, but it comes with a steeper learning curve than JQuery.
以下是 jQuery 和 jQuery 之间最大的区别： JSF：
jQuery 从未打算用作完整的堆栈网络框架。它更多的目的是替换低级的 JS 代码，以便用更少的代码行编写 JS 变得更容易、更强大。
因此它应该主要用于在 HTML 元素上添加行为。
Here are the biggest differences between jQuery & JSF:
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.
And it should thus mostly be used to add behaviour on HTML elements.
在大型 Web 应用程序中使用过 ExtJS 框架后，我知道它是多么容易使用。 ExtJS (Schena) 最适合 MVC 架构中的 (Oracle 11g) 数据库交互。视图用于视觉/用户交互。控制器指定了 PLSQL 包中需要使用的“处理”和触发器（CRUD、SQL 选择查询等的 API）。模型和存储文件用于将数据项“映射”到查看器/输入。
ExtJS 不适合非数据库密集型 Web 界面 - Angular JS 可能更适合。
Having used ExtJS framework for a large web application, I know how easy it is to use. The ExtJS (Schena) is best suited for (Oracle 11g) database interactions in MVC architecture. The View was for the visual / user interactions. The controller specified the 'processing' and the triggers that needed to be used form the PLSQL packages (the API for the CRUD, SQL select queries etc.). The Model and the store files were used to 'map' the data items to the Viewer / inputs.
ExtJS is not suitable for non database intensive web interfaces - where Angular JS may be a better fit.