ExtJS和GWT的比较

在写之前我没看任何网上关于二者的比较，就是为了能不被别人的想法影响，所以这不是大而全的比较，充其量只是我的感受罢了。 

1. 首先是license的问题，众所周知，ExtJS已经收费了。不过我们简单的分析下，你就会发现，价格很公道。学习是不用你花钱的，js天生开源特质也很好的保证了这一点，资料也很充足，我看过的深入浅出Ext JS(第2版)(附光盘) 就是很优秀的入门和cook book。另外如果你的项目是开源的，那么ok，你也是不要花一分钱的。但是商业应用了，就要拿出一些银子了，最便宜的大概是2k左右，对于一个公司来说是十分公道的。 

    GWT的license对商业用户更友好，不要花钱。SmartGWT基础版也是免费的，提供了所有的客户端解决方案，如果想要涉及服务器端的解决方案，如消息推送什么的，也要花钱买license。 

2. 工具支持。 GWT有google自家的插件。可以提供一站式解决方案。而且都是java代码，没什么好说的，后面还会说到对于浏览器也需要相关支持，因为需要神秘的动态编译。 
    ExtJs我觉得最好用的也是最轻量级的插件是spket，支持ExtJS的自动完成和语法着色。而且很轻量级。ExtJS本身是js，其他方面也不需要太多的支持，另外一个好的调试器很重要，fireBug觉得不是很漂亮，而chrome自带的javascript调试器确实很赞。值得一用，在开发过程中我几乎离不开他的。 

3. 最关注的当然是开发效率了，GWT本身也是支持动态编译的，在托管模式下，改调的java代码会即时编译成js，开发效率还是可以接受的。 
   ExtJS原生的js只不必说，开发效率是随着你对js的理解和ExtJS的理解而越来越高的，不久你就会爱上，以前不爱写的js。不过这又涉及风格问题，以后讨论。 

4. RPC的支持。不得不说，GWT在这个领域有天然的优势，因为他们的c和s的语言相同。对for java RPC的直接支持在整合原有产品上也是有天然的优势，可以给每个EJB封装一个Servlet的proxy，就可以实现无缝，甚至原有的Domain都是可重用的，不用再搞丑丑的DTO。 

   ExtJS也是有支持的，而且面向的语言更宽泛。因为事实上官方只是提供了客户端解决方案，然后留出接口给第三方实现，就是Ext Dricet。不过现实中我们是用的Dwr，效果和原理都是一样的，甚至自己实现也是很好的方式呢。额外的会有一些DTO的出现，如果分层的话服务器端也会有些代理类封装Ejb，代码量差不多吧。 

5. 风格上。 java的风格就是那个样子，古板，刻板，代码量多。写服务器端这些某种程度上说还都是优势。 
   就javascript本身的风格来说，灵活有余严谨不够，多少在可维护上还是有点弊端的，不过类似ExtJS这种大而全的js库都是会封装一些面向对象特性进去，例如Ext.extend等，还有一些如Ext.ns提供良好的命名空间等。把可重用的封装成组件等都会抵消他的劣势，而他的灵活性又带来了相应的好处，这里就不说了，在实际编写中会有感触的。 

6. 可扩展性。 这又是尤为重要的，ExtJS的组件我写过一些，比如整合Dwr的自带翻页的表格，和基于树表的更强大的树表等。总的来说很方便，而且有源码可以参考，很快便会上手，但是基于UI的一部分，主要是基于html和css，还是有点小难的，需要反复的测试和调整，还好是解释性语言了，这个到不会让人抓狂。 

    Gwt的没那么深入扩展过，没发言权，以后尝试。 


我们公司的两个项目，我们的采用了ExtJS，另一个用了Gwt，不过Gwt的项目还没有开始，无疑他们都是优秀的项目，我会持续关注的。