Wicket、Grails与JSF/seam, tapestry性能比较

wicket beats grails jsf+seam tapestry一文对当前最流行几个表现层框架性能进行了比较，如下图：

1.Grails比Tapestry 更加产品化，这是因为Grails的文本质量要通俗易懂，看过Tapestry的文档的人确实比较难以
理解作者思路，Tapestry作者最近写了一个很学术的怪异模式，看了半天才大概明白是动态代理懒加载之类。

2.Grails的性能需要提高。

3.Wicket是最快的，Tapestry紧随其后。

4. Seam + JSF 的Session使用量明显高于其他，每个Session大概760 KB.为什么这个指标很重要，因为在分布式
环境中，这些Session中数据是否分布拷贝到其他服务器上，如果是幂等的，可重新生成，就安全，否则服务器
之间Session复制就占据服务器大量处理能力。

5.tapestry网站宣称：在一些类似Tapestry框架中, 类如 Faces和Wicket, 页面结构是动态的, 必须保存更多数据在HttpSession.该文作者认为这个结论是不正确的。

个人评价：其实我们已经从Wicket和tapestry关于HttpSession口水仗看到基于服务器的表现层框架的一个误区：
在服务器端处理客户端状态的窘境，而REST倡导将客户端状态转移至客户端，这是一个方向性的不同创举啊，
所以，为了获得根本的高性能，以及高伸缩性，使用REST架构也许是个大趋势。其他不过是五十步笑百步。

[该贴被banq于2009-09-17 11:39修改过]

wicket用户漂过。wicket和rest并存，对外查询的基本上都是rest，有一些后台管理的用wicket，目前已经解决了１００％的问题。但Ｗｉｃｋｅｔ与其他框架的集成，不如Struts1/2之类的方便，这里主要是报表，工作流之类的框架，不代表其他的ＤＩ框架和Ｗｅｂ框架。

Ｗｉｃｋｅｔ扩展性很好，各种类抽象得相当不错。

JSF，谁用，我佩服谁，个人观点，能不用就不用。Ｓｅａｍ也是。

Ｇｒａｉｌｓ过去是玩具，现在开始走向正规。

tapestry看过３和４，再到了５居然又是大变脸，我不想折腾，就没再看过。学习曲线相对大一些，似乎不适合生产中找人来开发。

seam/jsf 还是比较有前途的，jsf 2.0 或许是走进寻常百姓家的第一步。。。
jsf 2.0 疯狂的吸引了其他扩展的一些特性，如ajax4jsf, richfaces, jsftemplate, icefaces等，可能是Java EE 6中特性增加最多的一个规范。
掌握jsf，我相信需要一定时间的（目前我正在练习jsf/seam），毕竟它的设计有些复杂，相对于基于action的框架。jsf 在java web 开发真正做到了组件复用，目前比较出名的组件包括，richfaces/ajax4jsf, icefaces, openfaces, primefaces, dojofaces, xulfaces, restfaces等，几乎覆盖了所有的ajax技术（dojo,yui,ext,jquery等），你不用写任何js代码可以做各种效果ajax页面，当然还有Myfaces家族产品。
seam的扩展性是很强的，不要想到seam就想到了jsf，其实在2.0早期，seam中已经集成了spring（可以调用spring bean）, gwt, wicket等等的支持，tapestry5, metawidgets 等都有seam的扩展。
至于wicket，只是试用过，个人感觉功过参半，页面干净了，却需要复杂冗长的java代码来处理即使很简单的响应。
与 wicket 相比，如果我喜欢这种编程方式，我会选择vaadin（基于gwt，我觉得它可以脱离gwt），内置了页面模板，没有页面代码（当然你不喜欢它的样式，就可以自己定义页面样式），所有代码是java完成。
metawidgets 的方式也是不错，和xul编程类似。

Wicket 比较喜欢的，够优雅；开发起来感觉不错，有IDE完全支持，写代码心里踏实；
Grails 研究了一段时间，更改代码后重新装载还是慢，有时候甚至无效，完全没有淋漓爽快的感觉；Groovy的IDE代码分析检查也不行，得靠运行时检查调试大部分问题，不爽；
JSF和Tapestry没用过，没有发言权；