我应该选择哪个框架 – Seam，Wicket，JSF或GWT？
我正在讨论是否使用Seam，Wicket，JSF或GWT作为Java项目中表示层的基础。
我根据就业市场考虑因素，技术的新颖性以及其他SO用户的建议，将我选择的Java Web框架缩小到这个子集。
在决定这些因素时，我应该考虑哪些因素？
我使用的唯一一个是JSF，所以我无法向你提供其他人的反馈，但这是我对JSF的看法。 根据我的经验，当我们从JSP中的JSF转换为facelets中的JSF时，生活变得更加容易，因此我将专注于facelets。 而且，看起来Seam和JSF并不相互排斥。
优点：
- 创建facelets xhtml组件很简单，可以促进重用。
- 使用内置标签（如ui：insert，ui：include和ui：decorate）的体面模板function
- 通过faces-config简单访问Spring bean
- 基于XHTML，因此不熟悉java的Web开发人员仍然可以有效
- tomahawk / trinidad提供的好小部件库
缺点：
- 仅发布请求。 这可能使书签变得困难。
- 不像GWT那样内置ajax-y，但如果与Seam一起使用，这可能是固定的
我不是JSF / Facelets的专家，所以我确信还有其他我错过了。 希望其他人也会详细说明。
JSF 2.0更新：
- 复合组件具有更好的重用function
- 2.0的小部件库包括primefaces和mojarra scale
- 允许获取请求和书签
- 内置了Ajax支持
- 有关JSF 2的更多信息，请参见http://andyschwartz.wordpress.com/2009/07/31/whats-new-in-jsf-2/
自从2.0规范问世以来，我从版本1.4和JSF开始使用GWT。
GWT是一个客户端框架，它从Java生成JavaScript。 您的架构将是纯客户端 – 服务器，这意味着：
- 最好使用粗粒度服务
- 前往客户端的所有对象都应该是完全可序列化的（这意味着没有延迟加载或OpenSessionInView模式）
- 从GWT 2.0开始，你可以使用xhtml设计你的gui，这在设计和构造HTML方面要容易得多
- GWT倾向于支持良好的架构，如果搞砸了，重构将是不好的
- 完美历史（浏览器后退按钮，可collections的url）支持很难 ，你可能需要自己动手，虽然很容易在前面破解一些东西
JSF是一个基于组件的框架，具有视图优先设计（如果您愿意，可以使用代码隐藏）：
- 做一些类型的webapps更有效（有状态，比如购物车）
- JSF + Seam支持对话（想想类似于向导的页面，可以跨多个页面维护状态）
- 您可以实现OpenSessionInView，具体取决于您的堆栈。 如果您将EJB用于服务/业务层，则可能不建议这样做
- JSF2对AJAX提供了极好的支持，并且像RichFaces这样的组件套件可以构建漂亮的webapps
- 但是如果你想要精美的javascript行为，你将不得不写一些javascript
- JSF跟踪客户端或服务器端的当前UI状态。 这是网络流量或服务器内存之间的权衡。
恢复：
- GWT更适用于需要最佳客户端性能的Web 应用程序 （想想gmail）。 编写自定义组件（编写Java）很容易，因为服务器端只是服务层，所以在服务器端可以完全无状态。
- JSF更适合大多数CRUD应用程序，它们更适合面向组件的东西：想想酒店/航class预订系统，带购物车的在线商店等等
感谢wicket家伙保持清醒并继续讨论。 我是一个wicket用户，我喜欢它。 我的主要原因是：
- 它是一个组件框架。 我喜欢使用组件而不是整页。
-
当我处理java部分时，我可以让设计人员处理模板和页面
-
没有什么新东西需要学习。 它的“只是java和只是HTML”
- 我喜欢它的ajax Fallback机制。 如果浏览器上没有javascript支持，特别是在移动设备上，它会回归到简单的html，一切正常。
- 它缺乏xml配置是一个优点
- 它支持我在Web应用程序中想要的一切。 例如validation，国际化，后退按钮支持和其他宁静URL
我以前的经验是GWT和JSF 1.0
Seam是一个应用程序框架，而不是一个表示层。 它最初是为了使JSF减少痛苦而开发的，但是已经发展成为更通用的dependency injection框架。
我相信你可以使用Seam与JSF，Wicket和GWT。 JSF的支持是初级和优秀的; 我不确定其他两个人的支持程度如何。
由于您的标准的重点似乎是您的技能的适销性，我建议通过Facelets尝试Seam和JSF。 JSF是一个公认的标准，如果你使用Facelets，它实际上很有用。 您可以通过Richfaces和Ajax4jsf获得灵活的AJAXfunction。 Seam通过JCP或多或少地标准化。
我的经验是按时间顺序：
原始的servlet – （是的，很多努力工作，但它是早期的，我们是渴望海狸！）
JSP – 我认为它出现的时候是beez neez（如果我们只知道;））
Echo – 令人敬畏的框架，但不适用于需要搜索引擎友好的页面（与GWT相同的问题）
Wicket – 令人敬畏的框架 – 开发人员完全理解OO的概念（与JSP和许多其他人不同），并将所有常用的OO细节应用于此框架。 如果你欣赏’可重用性’，如果你喜欢封装，如果你喜欢分离关注点，如果你想将你的模型绑定到UI代码而不必担心对象编组和其他这样的丑陋，那么这就是你的框架！
从长远来看，我建议使用Sun规范支持的技术。 到目前为止，这已经certificate可以提供多种实现选择（通常也是开源实现），而且行为往往定义得非常好。
这将有助于您在维护方案中 – 希望 – 您的代码将及时结束。 写得很好的代码永远存在:)
在这个特殊场景中，我建议使用JSF。 我只尝试过1.1的Apache实现，但是在JSP之上是有害的。 我们很快就会对它进行修改 – 我希望在facelets上考虑使用JSF。
我使用了Wicket和GWT非常重要。 从未真正学会爱Wicket。
我的自我博客http://salk31.blogspot.com/2009/07/wicket-ajax.html
今天看看GWT 2.0 uiBinder提醒我，在Wicket中必须将XML组件树与用Java创建的组件树相匹配是多么令人讨厌。 GWT旋转对我来说看起来好得多。
我没有使用Wicket超过一年所以也许他们已经解决了很多这个问题，但鉴于现代浏览器和JS支持，我无法在服务器上看到这一切（我知道，我知道数据位置）。
如果你只考虑就业市场，你应该选择JSF。 但是，我相信RIA的未来属于GWT和gwt，就像客户端技术一样。
我认为GWT最明显的优势，它比服务器端表示层技术（如JSF，wicket）更具可扩展性。 因为，服务器不需要存储客户端状态，也可以使用客户端cpu电源。这是一个巨大的好处，你不需要在服务器计算机之间串行化客户端状态以实现容错系统。
我知道它有点晚了但是在Framewrok上已经有很多比较了，特别是这个，它发生在durinf Devox 2010 conf：
http://www.devoxx.com/display/Devoxx2K10/Comparing+JVM+Web+Frameworks
这应该可以帮助你选择:)
我从JSF（1.1和1.2）开始，我决定改变下一个项目真是太痛苦了。 我研究了一下，我决定尝试Wicket，这真是一种乐趣。 我也试过JSF 2，但仍然是一样的。
它们都是组件框架，但使用Wicket的东西很容易，而JSF则完全混乱。
Wicket over JSF：
- 在Wicket中，HTML是HTML。 JSF有自己的标记标记。 h：dataTable（对于表格）是无稽之谈。 相信我，Sun Engineers在设计它时必须喝醉。
- 在Wicket这样的东西，比如安全，
- 使用JSF，导航栏显示以前的URL。 真奇怪。
- JSF在我看来非常沉重，而像Rich或Prime这样的库甚至更多。
- 有时，似乎不可能知道发生了什么。 你最终总是对你的电脑大喊大叫，因为你不知道JSF为什么这么做。
JSF over Wicket：
- 在Wicket中，您将编写更多Java（与HTML绑定）。 至少，您的IDE将提供重构和validation支持。
- Wicket的资源管理有点棘手。
- JSF有更多的文档和支持
一个常见的缺陷是会话大小是有问题的（因为图形组件存储在那里）。
总而言之，如果你只能在Wicket和JSF之间做出决定那么对我来说毫无疑问， Wicket 。
JSF已被弃用 （当福音传播者在2010年比较或讨论Web框架时，JSF甚至没有被列为比较框架）。
现在使用GWT，YUI，JQuery等创建完整的大型应用程序。
阅读谷歌及以上的一些文章将是显而易见的。
（JSF上的所有工作都是为了支持遗留应用程序）。