当用户界面可以通过CSS，HTML，JavaScript，jQuery实现时，JSF有什么需要？
我正在阅读关于JSF的一个UI框架，并提供了一些UI组件。 但是，从Ext JS或者jQuery或者CSS和HTML和JavaScript的组合中可以获得的组件数量有多好或者不同。
为什么有人要学习JSF？
JSF到普通的JSP / Servlet / HTML / CSS / JS就像jQuery到普通的JS一样：用更less的代码来做更多的事情。 以PrimeFaces为例，浏览其展示以查看完整的代码示例。 RichFaces也展示了完整的代码示例。 如果你仔细研究这些例子，那么你会发现你基本上需要一个简单的Javabean类作为模型，一个XHTML文件作为视图。
请注意，您不应该将JSF看作单独的HTML / CSS / JSreplace，您还应该考虑服务器端部分（特别是：JSP / Servlet）。 JSF不需要收集HTTP请求参数，转换/validation它们，更新模型值，执行正确的Java方法来完成业务内容，并生成HTML / CSS / JS样板代码。 在JSF中，基本上最终是一个XHTML页面作为视图定义，一个Javabean类作为模型定义。 这大大加快了发展。
就像每个基于组件的Web MVC框架一样，JSF对所提供的HTML / CSS / JS的控制更less。 添加自定义JS代码并不是那么容易，因为您必须考虑服务器端的JSF视图状态（例如，在JS端启用禁用的button将不会启用JSF端的button，这反过来又是一个巨大的安全优势）。 如果这是一个主要的展示者，那么就应该寻找一个基于动作的Web MVC框架，比如Spring MVC 。 你只会考虑到你必须自己编写所有的HTML / CSS / JS代码。 另外，如果您从Facelets回退到JSP，您也将错过高级模板function。
另一方面，如果您有一个基于JSP / Servlet / HTML / CSS / JS / jQuery的大型网站，并且您想将重复的JSP / Servlet / HTML / CSS / JS / jQuery样板代码重构为可重用组件，那么其中一个解决scheme就是JSF。 自定义模板，标签文件和组件可以在这方面提供帮助。 从这个angular度来看，JSF站在JSP / Servlet / HTML / CSS / JS / jQuery之上（这也是为什么在深入了解JSF之前理解这些基础知识是非常重要的）。
您可以在这里find一个基于JSF的真实世界启动项目： Java EE Kickoff App 。 您会发现它包含JSF旁边的HTML5 ， CSS3和jQuery 。
也可以看看：
- 请求MVC和组件MVC之间的区别
- JSP，Servlet和JSF之间的区别
- 哪个Java Web框架selectjQuery？
- JSF 2.0的主要缺点是什么？
- 是否有可能使用JSF + Facelets与HTML 4/5？
- 何时使用<ui：include>，标记文件，复合组件和/或自定义组件？
JSF的创build是为了让java商店不必学习像jQuery这样的东西，而是build立复杂的js，而是专注于纯粹的Java堆栈。 在这个世界上，时间就是金钱，很多地方已经把注意力集中在Java开发上，less了一点语言/片断，使得训练和维护更快，从而更便宜。
我将补充说，JavaScript很容易成为大型团队的维护噩梦，特别是如果项目中的一些开发人员不是高度web浏览器。
使用Javascript和jQuery等框架，您拥有完全的灵活性和完全控制权。 与分机等你失去了很多的控制权，必须适应框架。 有了JSF，你完全失去了控制，必须完全适应框架。 你在生命周期中被调用，最后你无法控制什么时候可以调用服务器。 如果你要做一些被认为是“特殊”的事情，那么你处于非常困难的境地。 而在JSF世界中，即使是多列表sorting或只能input有限字符集（如数字字段）的字段这样的基本事物也被认为是“特殊的”。
但是，您拥有的灵活性越多，您所犯的错误或错误就越多。 高度的灵活性只适用于高度智能的程序员，其他人则会把项目变成难以驾驭的噩梦。
但是，在JSF和灵活性有限的情况下，总是只有less数（甚至只有一个）正确的方式来做某件事情。 你是非常有限的，你不能做捷径，你必须写更多的XML等 – 但是当适应标准时，对没有经验或者低技能的程序员将会产生的代码有更好的控制。 因此，大公司都喜欢JSF，因为它对他们来说更“安全”。
当我从GWT转到JSF时，我感到很震惊，有多less事情对我来说是很自然的，被认为是非常不典型的，有多么简单的事情很难实现。 更重要的是，即使做了最小的改动，比如在标签后添加“：”符号，在GWT / jQuery动力应用程序中改变一个函数生成标签，需要更改几十个具有本地属性的文件，甚至没有考虑到除我以外的任何人
使用JSF的好处不仅在于生成xhtml + css + js。 有时，JSF会对可以生成的标记施加限制，就像任何基于组件的框架一样。 但JSF不仅仅是为了它，它的生命周期也是非常有帮助的。 在validationinput之后，它可以更新模型并且毫不费力地同步你的服务器端bean。 你只是说“不pipe用户在这里input什么，检查它是否是一个数字，如果是，那么将它存储在对象XX的属性YY中”，JSF将完成所有的工作。
所以是的，你仍然可以使用JQuery，JS等等。但是JSF在编写服务器端代码方面提供了很多好处，并且可以帮你节省很多的开发板。
我强烈反对，jsf增加了一切。 它只会增加开销。 在服务器上使用ui的东西是最可笑的事情之前听说过。 而大型团队的JavaScript工作得很好 – 它被称为重用代码。
只需要将jquery包装在一些jsp标签中，这就是你所需要和已经完成的任务，并且不会忍受.jsf和richfaces的尴尬和可伸缩性问题。
使用JSF，Spring MVC，Struts，Grails，JQuery和ExtJS我认为Grails + ExtJS是一个强大的组合。
我会selectGrails而不是JSF。 我喜欢ExtJS作为客户端框架和库的完整性，但是它的学习曲线比JQuery更陡峭。
这里是jQuery和JSF最大的区别：
- 没有MVC架构
- 没有状态控制（会话或会话中的存储date，自动清理等）
- 没有（默认）validation库
- 没有模板库
- 没有先进的导航/路由
- 客户端
jQuery从来没有打算作为一个完整的堆栈webframework使用。 它更多的是用于replace低级别的JS代码，以便在更less的代码行中编写JS变得更容易，更强大。
因此它应该主要用于在HTML元素上添加行为。
在使用ExtJS框架的大型Web应用程序，我知道它是多么容易使用。 ExtJS（Schena）最适合于（MVC架构中的Oracle 11g）数据库交互。 该视图用于视觉/用户交互。 控制器指定了需要使用PLSQL包（用于CRUD的API，SQLselect查询等）的“处理”和触发器。 模型和商店文件被用来将数据项目映射到浏览器/input。
ExtJS不适用于非数据库密集型Web界面 – 其中Angular JS可能更适合。
