前面转贴Liebeck(echo的主要开发者，我的偶像)关于echo2和gwt的对比:http://www.blogjava.net/steeven/archive/2006/06/01/49379.html
今天仔细做了一些笔记，并且加入了一些自己的想法，供选型者参考：
综合对比：
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)相当值得关注。