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项目和相关的技术应用。