谈一谈我对于目前国人对于EXTJS的错误看法

   ExtJS架构已经不仅仅是一个VIEW解决方案，更可以说是WEB开发的一个很好的平台，ExtJS很好的融合了AJAX技术，可以很容易让前后台融为一体。同时Extjs对JSON很好的支持，让我们很容易使控件与数据绑定。更奇妙的是Extjs提供了多种获得远程数据的手段，毫不夸张的ExtJS与Struts中MC配合的实在是太好了。
   Web企业级应用中对页面的要求较高。ExtJS丰富的组件为我们提供了方便。随着探索的深入，发觉ExtJS以不仅仅解决了页面问题，让人感到C/S味道：数据的绑定与交互是那么的方便!
  Ext与Struts、spring、dwr、json基本上是无缝的、平滑的。
  性能？搞笑，系统的最大的性能在业务层面。没做过千万元级的大项目，不要谈性能，不然让人可笑。

  Ext不存在JS编程问题，其实通过XML配置+spring可以自动生成Ext的脚本。

 

那只是分工上的不存在而已，一个项目组中必然至少得有一个人来维护你所谓的能够自动生成Ext的框架，这个框架即使是类似于GWT的开源框架，依然是需要维护的。

这些维护工作量主要包括，框架本身的小bug，组件的扩展和用户的需求（框架提供的组件不能直接提供）。

也就是说，你所说的“Ext不存在JS编程问题”仅仅是在这个“框架”够用的前提下，一旦这个“框架”的功能不够用，或者bug数量比较多的话，那个维护的人自然而然就成为了瓶颈。

从整体成本上来考虑，如果那个维护的人是1-3个的话，既有可能导致成本本末倒置，其他人员使用此框架节省出的成本全被这些维护框架的人消耗殆尽。

还有个最严重的问题，EXT要用到什么程度，如果只是作为组件锦上添花型的，采用服务端生成JS代码的方式还算可行。如果是为了进一步提高客户体验，减少不必要的网络开销，势必要采用模块化的设计，单个模块往往就是一个OPOA，此时这种服务端生成JS代码的方式根本就是不好使的。这个问题归根结底是，页面UI逻辑有相当一部分是属于页面上的动态信息的交互，就应该用最直接最简单的方式直接实现这类千变万化的页面逻辑。

例，假设页面布局分成左右2个区域，左边是添加好友界面，右边是显示已添加好友列表，当左半边用户添加一个好友以后，最理想的数据操作就是发送一个Ajax请求给服务端，添加一个好友成功后返回成功信息，然后客户端回调一个函数用来在右边的好友列表中增加一个刚才添加的好友信息。然后左边的界面模块自动切换成给这个好友发送站内消息的界面，如果客户再做一个发送站内消息的操作，老样子，服务端接收发送操作，成功后返回成功信息，然后客户端回调一个函数更新右边好友列表中的相应好友的状态，搞个图标表示信息发送成功未查看状态。

这种细粒度的用户UI交互设计，如果是直接JS编程的话，成本是非常低的，如果此时一定要把这个操作封装成服务端生成的组件，绝对是吃力不讨好的，因为封装调试相对于直接JS编程是需要高额成本的，而且这种业务逻辑没有重用性可言，根本不值得封装成页面组件。而由于采用了类似于GWT的这种服务端生成JS代码的框架，反而是必须要封装，就变成为了封装而封装了，封装粒度不对。

EXT的整体架构已经非常优秀，充分利用了JS的特性，使得编程难度降低不少，代码量也不多，也可以充分利用ext的OO特性进行组件封装。

做很多子项目集成的时候iframe还是很有用的，尤其是某些不能不用的框架无法和其他框架一起工作之类的情况。

ext的效率不是问题，他基本的优化已经给我们做完了。dojo的效率是个大问题，他默认做的优化不多，而且build系统非常麻烦。ext最大的问题是封装过度，在很多情况下调试比较困难，有时简直无法追踪问题的来源。

呵呵,写一点心得,从0.3开始写Ext.一直到2.0,写了一年多了.企业级应用.
一开始写的页面反应超慢,反复操作多次后ie竟占用300多m内存,当时差点废掉Ext.
后来写的多了，发现自已当初还是不会写，现在８５％的页面在ADSL调试客户端上载入时间控制在900ms以内，内存泄露能躲过的尽量避免，客户从上午九点开始进行月末库间调货集中盘点（涉及四大模块几十个操作）一直到下午6点下班IE6内存只增加了17.1M.操作没有任何问题．
还有一点是关于iFRAME的，如果使用iframe,并涉及到大量的模块间调用与参数传递,教训是惨痛的．

坚持看源码，不从不买书籍

通过看大家的讨论，真的学到很多阿。

那就多追一会儿~

非常不喜欢EXTjs的运营模式。

陈老师，第一次进你blog，很高兴，说声你好，你视频做的很好！

ext用了大半年，
对js编程有质的飞越.............