各种webframework的比较

Matt Railbe(Struts Menu 和 Appfuse 的作者) 前些日子写了一个文档简要比较了一下目前流行的几种Web Framework, 包括struts, spring mvc, ww2, Tapestry , JSF 等. 写得还算中肯, 可以参考一下.

https://equinox.dev.java.net/framework-comparison/WebFrameworks.pdf

另外, 在他自己的wiki中他有这样写道:

I think WebWork rocks, but it's similar to JSF in that it doesn't come with everything your need. The good news is it's easy to write interceptors, but IMO there's a few that should be part of the framework. After working with Tapestry and JSF, I can see how component-based frameworks will be the wave of the future. I think as you develop more and more components, the code you write becomes less and less.

很简单的一段话,就不翻译了


以上只是为同样在Web Framework中晕头转向的同学们提供这样的一条信息而已. 不代表本人观点 :D  欢迎讨论

Webwork2有希望, 因为它代表AOP的趋势, 而且从Struts转过来也方便.
其实, 要想知道哪一种最普及, 查一下www.monster.com或是www.dice.com
就明白了.

我个人认为，Tapestry基于组件的web应用程序框架是将来发展的大方向，就好比很多年前提出面向对象编程的概念一样。技术发展的最初也是最终目的，是为了极大的提高工作效率。假设有一天，Tapestry的可视化IDE开发工具出世，那么基于元素的那些web应用程序框架的生存空间，将会受到极大的挑战。由于Tapestry的基于组件理念，这种预见是完全有可能发生的，而且实际上，Tapestry的开发者Howord的朋友，已经在着手这方面的工作。大家可以参考Howord的blog：http://howardlewisship.com/blog/   所以，我对Tapestry的发展前景，充满希望。

不过Tapestry相比struts/ww2而言,复杂度要高,学习曲线也长很多. 看了好些日子的Tapestry还是懵懵懂懂的..
据说JDK1.5包含了JSF而且JB2005也将提供支持? 还没去了解. 唉. 诸侯纷争啊

Tapestry学习曲线长，难度高，是因为Tapestry颠覆了我们平常熟悉的web表现层框架的应用方式，另外还有一个重要的原因，是因为Tapestry的资料远没有struts那么丰富。。。其实我认为，所谓难与不难，只不过是因为是否熟悉的问题。。。就如同小时候在学校学过的那一篇古文《卖油翁》所讲述的一样：“其实并不难，只不过熟悉罢了。”

我学习Tapestry才一个半月，由于资料太少，由于个人经验匮乏和技术功底不扎实，也由于缺乏与懂Tapestry的朋友交流，所以到目前为止，对Tapestry低层技术仍然有很多不明白的地方。但是随着我越深入接触Tapestry，我对Tapestry这种基于组件的web应用程序框架越看好。很简单的例子，我使用Tapestry开发网站，我同事使用JSP开发OA，根据CVS上的统计，平均业务逻辑数据库程序员写一行代码，我需要写20行代码；而我同事需要写200行代码。另外根据我们对网站性能的测试，同样的业务逻辑层（spring+Hibernate）Tapestry开发的网站比远来的JSP开发的网站快了2.5倍。当然，这个数字我自己也持怀疑态度，不过快1倍，我是相信的，而且如果开启Tapestry的页面cache，我相信会更快。

实际上，一直以来，我一直都想找个地方推广Tapestry，把我收集下来的资料，以及自己的笔记，共享给大家。至于我开发的网站，《成都建信网》，《西宁建信网》，《湘潭建信网》估计要等到明年过完春节才会真正发布到网上，到时候，或许大家可以看一下Tapestry的效果。

Tapestry的资料Manning出版社有《Tapestry in Action》。

Tapestry的作者HLS同时也是HiveMind的作者，是一个很有创意的家伙，TSS.com网站现在就是用Tapestry来做的。Tapestry的事件驱动机制和dotnet的webforms，Sun的JSF类似，但是这种事件驱动机制编程一定需要良好的“所见即所得”的IDE设计环境，以及丰富的组件库，在这两方面，JSF/Tapestry相比webforms差距就比较大了。所以我的看法，事件驱动的Web框架成败更多的取决于IDE和组件库的情况，而不完全取决于框架本身。Tapestry的IDE支持和组件库支持都还可以，但是距离大规模的应用，它的可用性又显然有很大差距。

前面表示层版很多人都提出Web框架必须考虑添加足够的客户端JS支持，才是一个良好的解决方案，在当前的技术发展阶段，现在无法完美的做到这一点(XMLHTTP并非Web层的救世主)，因此也就注定了不会出现一个一统江湖的Web框架出来。那么在这种阶段，Web框架的成败更多的取决于是否简单易用、易于学习、资料是否丰富、应用是否广泛等等的非技术因素。

因此，我认为基于MVC模式的Web框架仍然是主流，Struts仍然是事实标准，而Webwork比较有希望在未来取代Struts；Tapestry应用不会成为主流，但是也会很流行，而JSF则实在丑陋，我非常不看好。

Robbin说的不错，既然是基于组件的framework，IDE和组件库将是Tapestry在企业领域大力开展的基础。
而Tapestry的缺点也正是这两点：
1、没有很好的IDE工具，而且它的html、page和java相互之间的联系较弱，想开发IDE工具有一定的难度；
2、组件库不够丰富，而且编写组件的难度比较大，一是因为缺少IDE工具，另外一点就是编写JS难度增大。

《Tapestry in Action》有在看, 感觉起点还是稍微有些高, 对Tapestry没有概念的人看的话很可能是一头雾水.

Tapestry现在支持的IDE也就只有Eclipse的Spindle吧, 功能不算强大. 目前支持到Tapestry3.01
组件库现在也有其他一些第三方开发的组件,不过确实很少, 在Tapestry的wiki上有相关链接.

WW应该是最接近传统MVC(struts?)的框架吧. 学习和开发确实比较简单. 并且在吸收了前人的经验后的确优于struts. 前些时候也看了一段时间的WW, 做了些ww+sitemesh的小东西吧, 似乎目前ww前端对js的支持还是比较脆弱.不知道后面的版本有没有改进了.不过就像QuakeWang所说的, WW/struts里面无聊的id传递方式确实比Tapestry的数据绑定来说要差那么一截.至于争论得很多的taglib问题就仁者见仁了.

JSF实在没有精力去看了. 哪怕他现在是1.5标准里的东西.sigh.

我现在为一个中型项目（80万美刀）选择框架，本来打算采用Struts1.2，主要看重它的成熟性、普及性，但实在不想采用一个已经相对落后的框架，这对公司技术能力的积累很不利，WW2虽然好，但是不够成熟，在成熟性上考虑，不见得比Tapestry好多少，何况Tapestry属于apache，最后打算采用Tapestry。

对Tapestry我比较担心两点：
1.普通程序员的学习成本，如果远远高于Struts，肯定就不行了，Struts本身的学习曲线就不理想。
2.开发效率问题，尤其是大量js的编写，或者重新封装，不知道对于这一点各位兄弟有什么经验和教训可以借鉴。

我个人对Tapestry十分看好，无论从美工和程序员分工的角度，还是从web端编程的方式来考虑都比较理想，但是要让老板相信需要实际的案例来说明框架的可行性，我没有找到足够的资料，不知道那位兄弟能提供相关的实现案例，或者是站点，多多益善啊。

tapestry确实是一个jsp之外非常好的技术。前面因崇拜turbine，花了一大把精力，项目搞到现在，初稿一运行，发现实在太慢，往往一个view就算没有任何velocity代码也要等地球转小半圈才出来，自己不满意别人也不满意。tapestry虽然新了点，但速度上、开发模式上让人欣慰，而且照样可以轻松实现页面模板动态切换，棒极了。
个人认为，tapestry值得花点时间去研究。