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

Question

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

由于演示文稿只强调了 JSF 的优点，我也想听听另一面。

所以我的问题是:

Java Server Faces 2.0 的主要缺点是什么？

是什么让 JSF 开发人员考虑使用 ASP.NET MVC 而不是 JSF？

Answer 1

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

两个 主要JSF 缺点:

大学习曲线。 JSF 很复杂，这是真的。

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

和 次要 我想到的缺点:

默认情况下，对象的 ID 由其父 ID 组成，例如 form1:button1。

没有简单的方法来注释掉不正确的页面片段。标签 <ui:remove>需要语法正确的内容，无论如何都要解析。

低质量的第三方组件，例如不要检查isRendered()里面 processXxx()在继续之前的方法。

合并 LESS 和 Sencha 很难。

不能很好地与 REST 配合使用。

对于 UX 设计师来说并不容易，因为现成的组件有自己的 CSS 样式，需要被覆盖。

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

请看看 Tapestry、Wicket 的低人气和经验丰富的 JSF 开发人员的低热情(更有意义的是什么)。
相比之下，看看 Rails、Grails、Django、Play 的成功!框架——它们都是基于 Action 的，不要试图对程序员隐藏 真正的请求/响应和 无国籍性质的网络。

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

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