H5W3
当前位置:H5W3 > 其他技术问题 > 正文

gwt和echo2的对比

    综合对比:

    1. 两个都是非传统的b/s框架,都是用AJAX来构造动态网站。编程过程都和SWT/Swing差不多。

    2. 区别在于一个运行于客户端,一个运行于服务器

    3. gwt把代码编译为html+js, 目前只支持java1.4规范。echo没这限制。

    4. gwt可以运行于任何web server, echo则需要传统的servlet容器。(意义不大,现在哪有静态网站啊,后台交互肯定还是需要的)

    5. echo2的客户端引擎通过ajax提交用户动作,对用户界面增量更新。

    性能:

    1. gwt的页面logic都在浏览器上,所以很快。但是如果需要和中间层交互,就会碰到同样的网络问题。

    2. echo2的代码跑在server上,所以所有的交互都需要反馈给server.echo2在设计上尽量减少这种交互,比如客户对文本的修改都是延迟发送到服务器,而服务器只发送页面的变化部分到浏览器。

    3. gwt应用被编译成一个页面,虽然应用的复杂化,这个编译结果也随之变得可怕……(个人认为随着编译器的发展,不同的页面可以做到lazy load)

    4. echo的js模块是lazy加载到浏览器的,界面上呈现哪些控件才去加载并且缓存对应的js模块。发送到客户端的不是逻辑代码,只有用户状态(个人认为echo2现在过于lazy,导致初始化阶段多次访问server加载一些基本的js模块,应该揉合到一起。另外,因为echo逻辑代码在服务器上,相对来说可以防止盗版)

    中间层和数据访问:

    1. 如果要访问数据,gwt还是要回到传统的模式,通过rpc访问servlet.gwt提供把远程服务透明的包装起来,中间传送pojo. 尽管包装了,中间的安全和和校验还是必须要开发者考虑。

    2. echo支持SOA,但是不必须。大多数情况下安全不是问题,因为数据和逻辑都不会暴露到浏览器上。(以前给echo提过建议,浏览器用户很可能去模拟一个被disabled按钮提交,这种问题现在无需考虑)

    运行环境:

    1. gwt运行在浏览器上,并非所有的java类都能编译成js. gwt现在只支持java.lang/java.util下面的一个子集(版本 1.0.21):27 classes, 11 interfaces, and 18 exception(这让人想起了j2me开发)。 一些现有的类库就别想了。

    调试:1. gwt调试需要一套和运行时完全不同的环境:HOST模式,代码作为真正的java在运行。(个人认为这里因为是纯java调试,比echo的web调试要稍微方便一些。做单元测试也更方便些,但不是对最终browser的测试)

    2. echo调试就是传统的servlet调试。

    授权:

     1. gwt的api是开源的,编译器和host模式浏览器不公开。整体来说:free. (个人认为,如果要扩充gwt可能会遇到麻烦)

    2. echo2开源,mozilla public license. free(个人认为:echostudio也free就好了。nextapp毕竟要生存)

    应用:

    1. gwt可以嵌入传统的静态html, 也能作为一个完整应用。做大应用要考虑编译后的重量、本地化、库支持等问题(关于18n, 可以在gwt支持论坛上搜索i18n,似乎已经有方案)

    2. echo2成熟得可以适用各种应用,但是不能作为静态页面的一部分使用。(有点吹牛,在大访问量下,服务器的压力肯定不会小)

    个人结论:

    1. 开发方式都很优秀,用纯java开发b/s

    2. gwt可用于大型网站,把压力转嫁给客户端。

    3. echo可用于快速开发复杂的企业应用,把压力丢给服务器(企业里面最清闲的就是前台和服务器)

    两个产品都很优秀,GWT是2006年的IT飓风,波及后面几年。M$的日子要难过了, GOOGLE的确是个令人头痛的对手。

    然而,还有比gwt/echo2更美好的未来吗?

    有!把他们的输出变成flash,用java开发flash应用。去年探索过一段时间,原型已经出来,因为flash开发调试太ugly, 没有继续下去。

    另外,微软的WPF(AVALON)相当值得关注。

本文地址:H5W3 » gwt和echo2的对比

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址