EXTJS--一个漂亮但不贤惠的情人
EXTJS—一个漂亮但不贤惠的情人,是我在学习EXTJS和用它做开发后的一个感受。曾经被EXTJS的美丽迷倒过,为了搞定这个美丽的可人儿,我每天通宵达旦的学习。当时学习开发的时候还没有中文教程,唯一可以参考的完整的文档是官方的API文档,虽然内容很全面,很丰富,但是英文教程还是让我吃了不少苦头。将EXTJS运用到系统开发中,并且取得了一定的成果,自己也很高兴,也很有成就感。
为什么我将EXTJS称为“情人”。因为作为情人,她首先具备的应该是一个迷人的外表。官网上大量的漂亮的Demo,尽展她迷人的身姿,多少人因为美丽而踏入她的领地。发几张我们系统中运用EXTJS开发的界面。
1、 我们在KOA中运用了EXTJS。以下是我在javaeye上发布的博客。
也来show一下我的EXT成果
2、 我们在百洋软件实验室的系统后台运用了EXTJS的桌面应用。
从这些漂亮的界面来看,我们怎么不拜倒在她的石榴裙下?我们又怎么能禁得起EXTJS阵营的诱惑而让我们趋之若鹜呢?
使用EXTJS,除了她迷人的外表,她还存在着其他的优点。
1、 统一的类库,虽然在升级到2.2后,类库发生了很大的改变,但是整体上还是相对一致的。
2、 组件化的思想。EXTJS可以说是将JavaScript的面向对象编程的特性发挥的淋漓尽致。很清晰的继承体系,让我们可以拆成不同的组件使用和扩展。
3、 丰富的UI。详细大家第一次去学习EXTJS也是被官网上那美妙绝伦的例子而吸引的吧。丰富的UI是区别于property,jQuery等轻量级框架所不具有的特性。
4、 详细的文档。EXTJS团队的确把文档做的非常不错,内容丰富且易于使用,并且为我们准备了在线文档和离线文档等多种文档形式。
但是开发系统或者技术选型,我们不能单单只看界面,效果,而是从各方面考虑,就像人们不能因为情人的漂亮多姿而升成正房一样。以下是在学习和开发EXTJS应用时总结的缺点:
1、 最让人痛恨的是EXTJS的授权,一次次的增加限制,让我们在使用的时候不得不考虑使用EXTJS的成本。
2、 类库文件太过庞大,一个ext-all.js就要900多K,造成页面加载速度太慢。
3、 时间一长,浏览器占的内存就会迅速上升,浏览器卡死是经常发生的事情。
4、 服务器端的功能被大大的消弱,服务器端大多数只是在做操作数据库的功能,应用服务器的功能利用率太低。
5、 前段展现全部用js来实现,存在很多兼容性和稳定性等诸多问题,而真正精通js编程的人不多。
6、 缺少强大的IDE的支持,虽然aptana、spket等开发利器,但是和Eclipse、VS这样的IDE相比,还是差许多。虽然提供在线的设计器,但是也只不过是个玩物。
7、 JS难以调试,而且界面和服务器后端的通讯及数据的传递不直接,需要服务器对象和JSON、XML传输介质的转换,增加了额外的开销,虽然也提供了java对象和json转换的类库,但是使用起来仍然不是很方便,造成了开发效率很低。
8、 JS代码比较杂乱,难以维护,项目越大,维护成本就越高。
所以说EXTJS是一个漂亮但不贤惠的情人一点也不为过。就像包二奶虽然不是我们所宣扬的,但是作为一个社会问题,自然有存在的理由,我们需要合理的认识和处理。而EXTJS作为情人,地位也非常的尴尬,也需要我们认真的分析,给它一个正确的位置。
1、 EXTJS太过庞大,不适合做互联网应用。但是值得庆幸的是,今年春天EXTJS发布了EXTJS-CORE版本,将核心类库分离出来,去掉了UI,只保留了ajax的相关操作,让EXT在互联网应用中开始占有一席之地。
2、 EXTJS不适合开发整个应用,特别是大型应用,在需要的地方使用就可以了,还是履行她作为情人的职责吧。
3、 由于使用EXTJS不在关心HTML,CSS这些页面元素,它特别适合一些不太懂界面的程序员的喜爱,比方我业余时间可以利用EXTJS开发一些小系统自娱自乐。
在使用了一段时间的EXTJS后,我终于决定要和她说再见了。在OECP中我们使用漂亮且稍微贤惠的RichFaces作为我们富客户端技术框架,我们也将在未来的开发中更深入的学习和应用,以后请大家更多的关注我们的OECP项目和相关的技术应用。