ExtJS和GWT的比较

orangesdk 2012-08-14

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

1.首先是license的问题,众所周知,ExtJS已经收费了。不过我们简单的分析下,你就会发现,价格很公道。学习是不用你花钱的,js天生开源特质也很好的保证了这一点,资料也很充足,我看过的深入浅出ExtJS(第2版)(附光盘)就是很优秀的入门和cookbook。另外如果你的项目是开源的,那么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的语言相同。对forjavaRPC的直接支持在整合原有产品上也是有天然的优势,可以给每个EJB封装一个Servlet的proxy,就可以实现无缝,甚至原有的Domain都是可重用的,不用再搞丑丑的DTO。

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

5.风格上。java的风格就是那个样子,古板,刻板,代码量多。写服务器端这些某种程度上说还都是优势。

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

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

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

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

相关推荐

kingwt / 0评论 2015-05-18