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

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

路过，个人观点：

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

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

顶楼上的，写的挺好的。

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

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

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

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

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

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

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

险些错过精彩的回复