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

从现在EXTJS的普及程度来说，这个工具框架的应用程度已经可以与其同类产品ＤＯＪＯ一比高下了，但是，从国人应用方面来看，ＥＸＴＪＳ对于很多人，包括一些正在使用的人也是相当的陌生．因而产生很多错误的理解

第一，认为EXTJS就是一个界面，读读数据，提交提交，就ＯＫ了．与很多语言下场一样，ＥＸＴＪＳ一经推出，很多一些所谓＂明眼＂人士，纷纷借此，写书，做教程，收费，再收费，小赚了一笔之后，也就没有下文了，比如说，开源人，浪曦等，他们教程，在我看来，更象一个数据库编程，只不过，从原来的WinForm + Database , 变成Service + EXTJS．对于性能方面，所讲基少．大家知道，ＡＪＡＸ一经推出，其效能问题一直是所有从事ＡＪＡＸ开发人员的一块心病，但其实很简单，掌握一条即可，＂尽可能减少服务器端资源的调用＂，好，这样的话，对于添加一条记录，然后，刷新一下列表做法，简直是对服务器端资源的滥用．因此，在数据交互方面，我认为ＡＪＡＸ的软肋，也是ＥＸＴＪＳ的缺点，因此，在此点上开发，才是ＥＸＴＪＳ开发的重点．

第二，认为EXTJS只能用于ＰＨＰ，或者ＳＳＨ，或者ASP.NET.为什么有这种认为，因为网上只介绍这些语言，我们的ＥＸＴＪＳ使用大家认为最＂垃圾＂的ＡＳＰ语言，同样实现ＳＯＡ．这个呢，不能怪大家，仍然要怪那些＂万恶＂的收费教程，因为他们只是讲后台怎么写，前台怎么绑，至于ＥＸＴＪＳ如何解析数据源，能够解析什么数据源这些就被＂模糊＂掉了．一个连数据交互原理都不清楚的人，是很难解决很多ＡＪＡＸ上的未见问题的．

第三，认为EXTJS就是一个界面改良，在项目中，我仍然用Ｎ张页面，在Ｎ张页面，部署ＥＸＴＪＳ．这个我不用多讲，效率问题大家都看得出来，ＥＸＴＪＳ是一个集成开发工具，注定他的开发包很大，一个500多K的JS文件，你究竟打算让它下载多少次？！应该说，EXTJS不仅是一个ＡＪＡＸ开发框架，也是一个富客户端开发平台，ＡＪＡＸ是可以部署到多个页面，而完整的ＥＸＴＪＳ是不能这样的做的，但是，他却能和ＦＬＥＸ一样，在一张页面中，完成项目中所有事件，这时有人说，这样ＪＳ文件不是就更多吗？！是的，但是，我们有压缩打包工具，可以将其打包成一个ＪＳ文件，我们可以将其部署在网络上，也可以象ＲＩＡ一样，安装机器上，使用ＡＩＲ技术即可．如果你只想进行在Windows机器上，那就也不用麻烦使用ＡＩＲ技术，直接改成后缀名变成HTA，你的程序就变成单机版了．

以上尽是一家之言，不管有没有不对的地方，我们已经在这些观点上进行了丰富的实战，事实证明，在一定范围内，是可用的，也是可行的．

原帖：http://www.dojochina.com/index.php?q=node/912

评论

105 楼 fins 2009-09-16  

redsnow_fenglin 写道

路过，个人观点：

开发面临的是需求与性能，第三方的选择在于团队整体水平、需求的满足、性能的可承受性、口碑&发展的前景及日后的维护成本；

1、Extjs在web ui这一块做的的确不错，学习曲线不是什么难题，我想在趋向收费性的extjs和出身高贵的dojo中选择，你应该会选择前者，至少我是，原因很简单：extjs还不是全部收费、漂亮的界面可以满足项目的需求、文档&api都很到位、担忧的性能extjs也很关注的在每个升级版本中优化提升，而dojo虽出身名门，得到大公司的青睐，但有一个致命伤--文档少、api升级变动、可能有些模块性能也不怎么稳定，这一点大家可以关注下struts2，struts2也选择了dojo，也是因为dojo的这种阔公子无章法的变动使得struts2的这部分开发其实也很痛苦，struts2-dojo-plugin据说也是出于此而诞生在struts2.1版的；

2、extjs与jquery其实没有可比性的，因为他们各自的出发点和落脚点不在同一个平台上；当然，你若担心extjs的性能，又偏爱于jquery，那么，你完全可以考虑用jquery+css+div的方式来DIY轮子或者用jquery的ui插件来实现extjs类似的你所需要的功能，这里你是不是已经发现了一个问题：jquery封装实现类似extjs提供的功能！对，就是它，它至少可以回答你两个问题，一是extjs和jquery的可比性其实不大，二是extjs的性能整体来说弱于jquery，但话又说过来了，若你将jquery封装到extjs的级别，那两者的性能对比将又如何？天知道，至少我不知道，永远的矛盾--易用性与性能，封装的层次越高，应用、维护起来越方便，性能的担忧也就越多了，不单单web开发，纯后台的项目也是如此，而且纯后台的项目更注重性能，易用易维护的封装层次与性能及灵活性永远是矛盾的共存体，如何取舍由你，但效果最终还是取决于项目终端用户体验的满意度，因为那才是财源；
PS：之说以这么说是因为我最近做了一个纯后台的项目时遇到持久层的性能瓶颈争论问题，我给大家一个粗略的性能测试数据，即便我不说，相信大家横行对比也知道这里面的含义了(据说C的oracle oci可以到达3k条/秒的insert速度，而我测java的oci或thin最好测试记录也无非1.3k多条/秒，比较汗)：
测试环境：主机 HP-UX rp3440 B.11.23 U 9000/800 (td) 数据库 ora9i
插入速度测试数据
模式 驱动模式 数据量 2w 2w 10w 10w
原始jdbc模式 thin 时间(速率) 17秒(1176条/秒) 18秒(1111条/秒) 1.26分(1162条/秒 1.26分(1162条/秒)
oci 18秒(1111条/秒) 18秒(1111条/秒) 1.25分(1176条/秒 1.28分(1136条/秒)
JdbcTemplate模式 thin 24秒(833条/秒) 24秒(833条/秒) 1.59分(840条/秒) 1.54分(877条/秒)
oci 29秒(689条/秒) 29秒(689条/秒) 2.33分(653条/秒) 2.21分(709条/秒)

ibatis两种驱动模式下插入速度大约在  400多条/秒，ibatis的批量可以达到[5400,6000](条/秒)当批量值在[500,1000]条之间选择时

从测试数据可以看出，OO易用性越好封装抽象层次越高，性能相对越低，未来的改良可能采用DBUtil了，因为后台这种多数情况下即时insert项目缓存的意义并不太明显，有种越走越底层、越走越原始的感觉，难道人生最后的最高境界真的是返璞归真？
PS-Java是个开源的世界，存在众多可选性，为避免重复制造轮子、快速开发，使用现有的第三方是有益的举措，但要做到使用第三方能够快速、高性能的完成项目开发，必须严把选择关，从需求满足、开源厂商、用户群、口碑、性能、前景等等，多方位、多角度的衡量第三方，一旦确定下第三方就要深入的去研究，为我所用；

3、再说flex，若对比extjs与flex，无非也是ui与性能，事物都是两面性的，所以，我比较不出所以然来，但我们不妨换个角度来看下：
   flex吸引你眼球的地方是什么呢？我想无非是良好的舆论口碑、漂亮的ui组件、高度耦合的B/S层server数据可便捷取到browser的能力及富客户端的体验(类似于js与dwr的关系，此况下似乎高度耦合我们也并不介意，也许面向接口编程缓和了高耦合的批判度，所以，不要过分技术...有点扯淡我*_*)；flex的确走出了一条新路子，它的新得益于门出adobe，受益于flash环境及actionscript脚步；我们不妨这样肢解一下flex：
   a.组件式的漂亮UI；b.actionscript的脚本编程；c.flash的运行环境；d.B/S的间通信协议；
   它的着力点在哪里呢？adobe利用flash的优势，打造web富客户端体验的application开发模式，个人观点，我为什么这么说呢？我们可以从以下几点来看：
   一、传统的web开发，主要是靠js+div+css来美工界面的，js虽有意高攀java但两者并无任何必然联系并终因其前期难以开发、调试、跨浏览器的差异性及非真正面向对象的语法以及所谓的js加载性能的讨论，使得开发人员对js是爱恨交错；
   二、ajax的风靡使得客户体验度大大提升，渐进沉寂的js又二度开春，再度被狂热追捧，这个过程也反映了web开发UI是软肋，说明web开发需要丰富的UI，需要非传统的web体验，开发人员期待能用像RAD方式开发application系统的方式来完成web的开发，简捷的 、丰富UI及便捷的UI与后端数据交互，这应该是jsf做的路线吧；
   三、ajax之前就已经存在jsf，jsf也是正统出身，旨在UI，推了好久，但始终不温不火，不知其中缘由，但jsf给我的感觉配置多于编码，这个让我受不了；
   四、接下来的代表应该是gwt了，是google推出的一套开发基类库，将开发完全分为client/server模式，无js代码，因为gwt会为你代劳，这也许是不擅长js而渴望开发出漂亮UI的web应用的朋友们的福音，也许google的原因吧，gwt还是蛮有影响力的；
   五、extjs着力于web UI的js类库，再看gwt-ext及ext-gwt，都着力在web开发UI及客户体验上；
   我们是否可以这样看下去：传统web开发ui的软肋(js+div+css) --> 带宽增加、数据交互能力、客户体验度的提升(ajax) --> 一方面UI的需求(air、extjs)，一方开发模式的转变(jsf，gwt，gwt-ext) --> 以上的web UI 最终体现脚本js，解析依赖于各浏览器；存在肢解的元素a.组件ui；b.js脚本；c.浏览器运行环境；d.http协议(当然ajax rpc) --> 终于到了炙手可热的flex；这应该是发展的根本所在吧~~

    黑猫，白猫，皆为猫，抓到老鼠是好猫^_^，或旨在ui，或旨在b/s数据获取，或旨在开发模式，或旨在一整套解决方案，擦亮眼睛勿迷失，我们工作就是任务制，写方案需要万金油，全能的，但要code，还是要擅己所长啊！

4、个人观点：抓其本质所在，有选择的拿来主义，精其精髓方触类旁通，做技术的主人而非努力，勿浮躁的整天追着技术跑，跑来跑去还仅是在比较孰优孰劣，一家之言，对也好，错也罢，交流嘛，就是争论性的^_^

险些错过精彩的回复

104 楼 sunplay2046 2009-09-16  

extjs说到底，是有一定编程方式，一定思路的一个sdk包，重点是看怎么用，用在什么项目里面，个人认为，在产品一级上还是推荐使用

103 楼 lookdd1 2009-09-11  

哪位ext高手能写篇EXT使用最佳实践或者使用总结之类的文章啊？很多新手学习ext用的乱七八糟，如何大规模应用中用正确的方式方法使用EXT，单单API和简单的例子无法满足，我用了好几个月了也没有找到最佳的应用方式。

102 楼 timshaw9791 2009-09-11  

顶楼上的，写的挺好的。

同时不看好ajax，做填角料可以，搞大了恐怕是锯末纸板房了。

当初大家翻出ajax来就是因为需求变化太快了，已经远不是webpage+link就能吃定的年代了，也不是asp,jsp能敷衍的时代了。但js所立足html,css本身就是块是非之地，是非恩怨多扯皮，以何来满足快速变化的需求？另外js不是谁的儿子(可能算是google的干儿子)，多半是被利用的命运，始终不见大的商业推手，好的开发环境还是遥遥无期。

另，我听说js是一门很高深很灵活能力很强的语言，我觉得建城堡还是小心点所谓的灵活，没有规矩不成方圆，事实上java这么清晰的静态语言我们还弄是弄了这么多的编码规范呢。

我觉得怎么多java精英跑来折腾ajax这种一坨坨的js，还要比拼这堆好点还是那堆好点，再联想到咱还要跑数据库那头捣腾，实在有点心酸。

还是别不好意思了，来一声叹息吧："非不为也，实不能也"。

101 楼 redsnow_fenglin 2009-09-10  

路过，个人观点：

开发面临的是需求与性能，第三方的选择在于团队整体水平、需求的满足、性能的可承受性、口碑&发展的前景及日后的维护成本；

1、Extjs在web ui这一块做的的确不错，学习曲线不是什么难题，我想在趋向收费性的extjs和出身高贵的dojo中选择，你应该会选择前者，至少我是，原因很简单：extjs还不是全部收费、漂亮的界面可以满足项目的需求、文档&api都很到位、担忧的性能extjs也很关注的在每个升级版本中优化提升，而dojo虽出身名门，得到大公司的青睐，但有一个致命伤--文档少、api升级变动、可能有些模块性能也不怎么稳定，这一点大家可以关注下struts2，struts2也选择了dojo，也是因为dojo的这种阔公子无章法的变动使得struts2的这部分开发其实也很痛苦，struts2-dojo-plugin据说也是出于此而诞生在struts2.1版的；

2、extjs与jquery其实没有可比性的，因为他们各自的出发点和落脚点不在同一个平台上；当然，你若担心extjs的性能，又偏爱于jquery，那么，你完全可以考虑用jquery+css+div的方式来DIY轮子或者用jquery的ui插件来实现extjs类似的你所需要的功能，这里你是不是已经发现了一个问题：jquery封装实现类似extjs提供的功能！对，就是它，它至少可以回答你两个问题，一是extjs和jquery的可比性其实不大，二是extjs的性能整体来说弱于jquery，但话又说过来了，若你将jquery封装到extjs的级别，那两者的性能对比将又如何？天知道，至少我不知道，永远的矛盾--易用性与性能，封装的层次越高，应用、维护起来越方便，性能的担忧也就越多了，不单单web开发，纯后台的项目也是如此，而且纯后台的项目更注重性能，易用易维护的封装层次与性能及灵活性永远是矛盾的共存体，如何取舍由你，但效果最终还是取决于项目终端用户体验的满意度，因为那才是财源；
PS：之说以这么说是因为我最近做了一个纯后台的项目时遇到持久层的性能瓶颈争论问题，我给大家一个粗略的性能测试数据，即便我不说，相信大家横行对比也知道这里面的含义了(据说C的oracle oci可以到达3k条/秒的insert速度，而我测java的oci或thin最好测试记录也无非1.3k多条/秒，比较汗)：
测试环境：主机 HP-UX rp3440 B.11.23 U 9000/800 (td) 数据库 ora9i
插入速度测试数据
模式 驱动模式 数据量 2w 2w 10w 10w
原始jdbc模式 thin 时间(速率) 17秒(1176条/秒) 18秒(1111条/秒) 1.26分(1162条/秒 1.26分(1162条/秒)
oci 18秒(1111条/秒) 18秒(1111条/秒) 1.25分(1176条/秒 1.28分(1136条/秒)
JdbcTemplate模式 thin 24秒(833条/秒) 24秒(833条/秒) 1.59分(840条/秒) 1.54分(877条/秒)
oci 29秒(689条/秒) 29秒(689条/秒) 2.33分(653条/秒) 2.21分(709条/秒)

ibatis两种驱动模式下插入速度大约在  400多条/秒，ibatis的批量可以达到[5400,6000](条/秒)当批量值在[500,1000]条之间选择时

从测试数据可以看出，OO易用性越好封装抽象层次越高，性能相对越低，未来的改良可能采用DBUtil了，因为后台这种多数情况下即时insert项目缓存的意义并不太明显，有种越走越底层、越走越原始的感觉，难道人生最后的最高境界真的是返璞归真？
PS-Java是个开源的世界，存在众多可选性，为避免重复制造轮子、快速开发，使用现有的第三方是有益的举措，但要做到使用第三方能够快速、高性能的完成项目开发，必须严把选择关，从需求满足、开源厂商、用户群、口碑、性能、前景等等，多方位、多角度的衡量第三方，一旦确定下第三方就要深入的去研究，为我所用；

3、再说flex，若对比extjs与flex，无非也是ui与性能，事物都是两面性的，所以，我比较不出所以然来，但我们不妨换个角度来看下：
   flex吸引你眼球的地方是什么呢？我想无非是良好的舆论口碑、漂亮的ui组件、高度耦合的B/S层server数据可便捷取到browser的能力及富客户端的体验(类似于js与dwr的关系，此况下似乎高度耦合我们也并不介意，也许面向接口编程缓和了高耦合的批判度，所以，不要过分技术...有点扯淡我*_*)；flex的确走出了一条新路子，它的新得益于门出adobe，受益于flash环境及actionscript脚步；我们不妨这样肢解一下flex：
   a.组件式的漂亮UI；b.actionscript的脚本编程；c.flash的运行环境；d.B/S的间通信协议；
   它的着力点在哪里呢？adobe利用flash的优势，打造web富客户端体验的application开发模式，个人观点，我为什么这么说呢？我们可以从以下几点来看：
   一、传统的web开发，主要是靠js+div+css来美工界面的，js虽有意高攀java但两者并无任何必然联系并终因其前期难以开发、调试、跨浏览器的差异性及非真正面向对象的语法以及所谓的js加载性能的讨论，使得开发人员对js是爱恨交错；
   二、ajax的风靡使得客户体验度大大提升，渐进沉寂的js又二度开春，再度被狂热追捧，这个过程也反映了web开发UI是软肋，说明web开发需要丰富的UI，需要非传统的web体验，开发人员期待能用像RAD方式开发application系统的方式来完成web的开发，简捷的 、丰富UI及便捷的UI与后端数据交互，这应该是jsf做的路线吧；
   三、ajax之前就已经存在jsf，jsf也是正统出身，旨在UI，推了好久，但始终不温不火，不知其中缘由，但jsf给我的感觉配置多于编码，这个让我受不了；
   四、接下来的代表应该是gwt了，是google推出的一套开发基类库，将开发完全分为client/server模式，无js代码，因为gwt会为你代劳，这也许是不擅长js而渴望开发出漂亮UI的web应用的朋友们的福音，也许google的原因吧，gwt还是蛮有影响力的；
   五、extjs着力于web UI的js类库，再看gwt-ext及ext-gwt，都着力在web开发UI及客户体验上；
   我们是否可以这样看下去：传统web开发ui的软肋(js+div+css) --> 带宽增加、数据交互能力、客户体验度的提升(ajax) --> 一方面UI的需求(air、extjs)，一方开发模式的转变(jsf，gwt，gwt-ext) --> 以上的web UI 最终体现脚本js，解析依赖于各浏览器；存在肢解的元素a.组件ui；b.js脚本；c.浏览器运行环境；d.http协议(当然ajax rpc) --> 终于到了炙手可热的flex；这应该是发展的根本所在吧~~

    黑猫，白猫，皆为猫，抓到老鼠是好猫^_^，或旨在ui，或旨在b/s数据获取，或旨在开发模式，或旨在一整套解决方案，擦亮眼睛勿迷失，我们工作就是任务制，写方案需要万金油，全能的，但要code，还是要擅己所长啊！

4、个人观点：抓其本质所在，有选择的拿来主义，精其精髓方触类旁通，做技术的主人而非努力，勿浮躁的整天追着技术跑，跑来跑去还仅是在比较孰优孰劣，一家之言，对也好，错也罢，交流嘛，就是争论性的^_^

100 楼 deyami 2009-08-25  

Jekey 写道

项目里当初用的ext1.1，现在想加进去新的功能，才发现1.1是个半成品，那个悔呀……

有同感，想做个扩展费劲的要命。。。源码的结构明显没有ext2清晰

99 楼 Jekey 2009-08-25  

项目里当初用的ext1.1，现在想加进去新的功能，才发现1.1是个半成品，那个悔呀……

98 楼 menuhin 2009-08-25  

说来说去，说了这么多。最重要还是看它是否能够满足我们的开发需求及在此之上的性能问题！

97 楼 deyami 2009-08-25  

<div class="quote_title">ppkosd 写道</div>
<div class="quote_div">认为EXTJS就是一个界面改良，在项目中，我仍然用Ｎ张页面，在Ｎ张页面，部署ＥＸＴＪＳ．这个我不用多讲，效率问题大家都看得出来，ＥＸＴＪＳ是一个集成开发工具，注定他的开发包很大，一个500多K的JS文件，你究竟打算让它下载多少次？！<br>
</div>
<p> </p>
<p>我觉得ria的意义应当在于将表现层的展现从小玩艺的级别升级到了应用级别，表现层的开发真正有了一套开发理念和开发模式。</p>

96 楼 jinyanhui2008 2009-08-25  

个人感觉jq完全可以满足开发需要如果需要更强大的功能可以使用flex，没有必要使用ext

95 楼 zhengyutong 2009-08-06  

kimmking 写道

这些问题讨论过很多次了。

世界上只有两种东西，一个是人人骂的，一个是没人用的。


extjs有一些问题，但依然是目前世界上公开的最好的js框架。

人人都骂，也要比没人用强。
支持extjs！

94 楼 MVC2008MVC 2009-08-06  

＂尽可能减少服务器端资源的调用＂，好，这样的话，对于添加一条记录，然后，刷新一下列表做法，简直是对服务器端资源的滥用"
  问一下楼主你再系统中是怎么实现的？添加n条数据然后去提交刷新，怎么去控制用户？如：添加到前台页面后用户就关闭了浏览器。而实际上数据并没有在数据库中。

93 楼 hyj1254 2009-08-06  

刚开始学JQuery,问个菜鸟级的问题:

JQuery能和ExtJs一样做界面吗？不能吧？怎么有那么多人把它们放在一起比呢？

92 楼 cyfgod 2009-07-21  

一个框架，一般都会随着功能越来越强大，性能不可避免有所下降。ExtJS也不例外，功能是强大了，速度却实在是慢。

91 楼 wjsir 2009-07-19  

imlsq 写道

EXTJS,这套东西，还有人在用！！！

如果是做企业应用开发，还是选择flex ,或者sl吧。

EXTJS这个东西，根本就不值得拿出来讨论嘛，先天的基础不足。

就你先天足。。。。。。。。呵呵

90 楼 cloverpluss 2009-07-15  

看来很多同学(无论是否已经独立，我都叫同学，因为大家都正在学做人)对ext真的有爱，我发表一下几个观点。

1.学习曲线大而且内部修改非常困难的东西，在公司是很难推广的，因为不是个个人的水平都像上面那些大牛一样牛X，而在小公司更是如此，用人成本太高，公司不肯上，你也没有办法。

2.不是每台电脑都像开发人员的电脑那么牛X，客户的电脑尤其是这样，君不见一些奔3，赛扬的电脑还是普遍存在，打开个网页都很慢了，更不用说跑ext。

3.ps:引用某人：性能？搞笑，系统的最大的性能在业务层面。没做过千万元级的大项目，不要谈性能，不然让人可笑。
任何项目你无好的系统架构，没有好的效能，系统经常down掉后响应慢，引起客户的不良反馈，都只能叫失败的项目而已。

89 楼 墓里活人 2009-06-12  

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

88 楼 我奋斗 2009-06-10  

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

87 楼 Dreamer 2009-03-31  

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

86 楼 kimmking 2009-03-29  

alexgratonor 写道

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

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

那就多追一会儿~