公司对于JSF和TAPESTRY的性能比较结果。请评论！

最终结果JSF胜出。我门现在用TAPESTRY3。 请各位评论下。我觉得这个结果是否有些怀疑？

乱评一把，等着挨骂：

不了解TAPESTRY，但是它好像是自己通过对模板进行解析替换合成来生成html。模板的解析合成的效率始终要受影响的

而jsf是jsp标签，编译之后执行的就是java代码了。
效率不会太低的。

  private boolean _jspx_meth_h_commandButton_1(javax.servlet.jsp.tagext.JspTag _jspx_th_h_panelGroup_4, PageContext _jspx_page_context);
          throws Throwable {
    PageContext pageContext = _jspx_page_context;
    JspWriter out = _jspx_page_context.getOut();;
    //  h:commandButton
    org.apache.myfaces.taglib.html.HtmlCommandButtonTag _jspx_th_h_commandButton_1 = (org.apache.myfaces.taglib.html.HtmlCommandButtonTag); _jspx_tagPool_h_commandButton_value_immediate_action_nobody.get(org.apache.myfaces.taglib.html.HtmlCommandButtonTag.class);;
    _jspx_th_h_commandButton_1.setPageContext(_jspx_page_context);;
    _jspx_th_h_commandButton_1.setParent((javax.servlet.jsp.tagext.Tag); _jspx_th_h_panelGroup_4);;
    _jspx_th_h_commandButton_1.setAction("cancel");;
    _jspx_th_h_commandButton_1.setImmediate("true");;
    _jspx_th_h_commandButton_1.setValue("#{example_messages['button_cancel']}");;
    int _jspx_eval_h_commandButton_1 = _jspx_th_h_commandButton_1.doStartTag();;
    if (_jspx_th_h_commandButton_1.doEndTag(); == javax.servlet.jsp.tagext.Tag.SKIP_PAGE); {
      _jspx_tagPool_h_commandButton_value_immediate_action_nobody.reuse(_jspx_th_h_commandButton_1);;
      return true;
    }
    _jspx_tagPool_h_commandButton_value_immediate_action_nobody.reuse(_jspx_th_h_commandButton_1);;
    return false;
  }

1）从你们的测试报告上可以看出，主观上即偏袒JSF。。。对JSF介绍那么多，对tapestry只有讪讪数语。
2）现在Tapestry已经发布4.0多时，为什么要评测T3.0？
3）我对你们的评测代码表示怀疑。你们是用最合理的方式来编写tapestry吗？就以我个人的经验，特别是连接数据库的情况下，tapestry的代码编写是需要注意运行效率的。。官方示例的那种编程方式，绝对不行。。。。如果你们真有这样的高手，为什么不使用T4.0？

我在两年前曾经用JSP和tapestry对比过，当时tapestry还只有3.0，的确感觉性能诧异很大 。。

不过，呵呵，程序运行效率与程序员开发效率本来就是一个见仁见智的问题。。。

从你们的开发报告中，没有提到tapestry最大的优势，就是：随着积累组件越多，那么项目开发也越容易。。。。

从你们的评测报告上没有看到这一点，怀疑你们是否是具有评测tapestry或JSF的实力？。。。难道随便找找资料、做个例子，就算是评测和对比一个框架了？

对于一个开发团队来说，是否使用一个框架，却决定性因素的我认为不是一堆数字。而是这个开发团队的人员是否有足够的技术积累能够适应这个框架。。。数字上最好的技术对团队上来说未必是最好的，只有最合适团队开发习惯和已有技术功力的技术，才是最好的。

同意楼上的观点。

这样的性能对比 像是有点官方的味道！！！！！

管你是黑猫还是白猫  能给老子捉到耗子就是好猫!!!

看了几位的回复我觉得值得回味:

1.容易学习的东西总是更多人用
2.如果很不容易才能写出好的代码,那么这个框架的易用性值得怀疑
3.项目中不可能每个人都是高手

适合自己的才是最好的

的确合适自己就是最好的。

不过，不合适你的东西，未必不合适别人。也许在你看来很不容易写出好的代码，在别人看来却很容易。。。。

呵呵。：）所谓的高手，其实就如同中学课本上学的文言文《卖油翁》中的卖油老翁，只不过熟悉罢了。。。

个人认为项目是否易于维护或者扩展，与使用什么框架毫无关系，而是取决于项目的总体设计结构是否合理，以及代码的编程是否规范性。。。

Ajax是好东西，但是调试太老火。。。不过我想随着IDE工具的发展，应该可以得到改善。


这是因为UI无法从页面逻辑中独立出来，作为面向标签的开发方式，这是JSF和FreeMaker的瓶颈。


FreeMaker太灵活了，以至于无任何规范可以遵循。所以除了组件开发者本身，很难理解组件的结构。在维护这种项目的时候，我甚至企盼这前任开发者没有使用FreeMaker进行组件封装。。。。。


去年见过IBM有套基于eclipse的工具RAD，开发JSF只有这么爽了，几乎像VB那样简单。不过这套工具最便宜也要几K。。

有一位我很佩服的老大说过，他很讨厌这种“大厂商支持”的妥协产物，因为这种产物的出现，技术不是决定性因素。。。对于这个嘛，我功力尚浅，体会不出太大感受。。。。不过一想到IBM可能为了支持它那套RAD工具对JSF规范进行修改，我对JSF就没有好感。。。。

tapestry需要IDE工具吗？HTML模板由美工直接使用Dreamware工具，页面类是标准的Java类。唯一麻烦的是页面规范，目前的确没有很好的IDE支持，不过都是很简单的XML配置。。。个人感觉并不麻烦。


这个我很赞同，FreeMaker太灵活了，如果真要进行组件积累，应该为其定义一个大家都遵循的创建FreeMaker组件的规范，那么即便换人了，就可以依据规范很好地维护组件。。。。Tapestry的组件本身就依靠Tapestry进行限制，所以官方组件的实现方式与自定义组件的实现方式完全一样。


开源与否，第三方与否，我觉得没有区别，当我们使用第三方开源组件的时候，人家为了推广就必须提供比较完善的使用文档，而我们在使用时必须遵循人家的游戏规则。。。。实际上，公司自己开发组件，也可以达到这样的效果。何况破解别人的核心代码，是很繁琐的事。

我在这里并不是推崇Tapestry，我也不讨厌FreeMaker。。。其实我觉得无所谓啦，反正都是为了最好最快地响应客户需求而存在的工具罢了。

基本同意dudu.

如果真如你们要做邮件系统.
ajax不错啊.
mail.126.com 不错,速度很好.
界面可以不段扩展吗!