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

大家千万别上当信了那些广告，extjs我打死都不去用的

你这个“不是远程的”是什么意思？
在同一台机子开一个web服务器？

造一个不难，但要造一堆组件，组件之间还能很好的相互合作，自成体系，形成框架，那就很困难了。也许这是为何现在优秀的js框架用手指都能数得过来。

EXTJS只是众多RIA技术与AJAX应用中的一个框架而已,至于为什么现在这么受人追捧,追根到底,就是因为其完全颠覆了传统WEB应用程序的外观,与设计组织思路.使得AJAX与RIA也能象Swing,WinForm一样进行项目化、团队化开发。从原先的WEB前端是“美工+验证+效果”的模式，变成“皮肤+组件”的传统可视化开发思路上来。

目前EXTJS国内的批评大致也就这么几个：
1、没有执行效率：不过，除了其本身存在的效率问题以外，大多数导致项目崩溃的效率性能问题是应用者的设计造成的；

2、没有创意：“一眼就看出是EXTJS做的，一点创意都没有，很容易产生用户审美疲劳”，这点，我也完全赞同，大我数的EXTJS开发团队，是没有能力为其制作一个完整的“皮肤”包，只能使用国外或者国内几个开源社团的提供的“皮肤”，也就是二十几种，而且，大致的样子是不会改变的。但是，我们为什么不反过来想想，“让用户操作WEB程序就象单机版程序一样简单”，这也是为WEB应用程序提供了一个可选的思路。最起码我们不需要在基本可视化组件，或者使用别他的EXTJS组件，而大费周章解决“兼容”问题。因此这个问题，我认为是损誉参半；

3、很难想象那么JavaScript代码怎么管理啊：JavaScript很早就有IDE开发工具，随着EXTJS，DOJO等一些知名AJAX框架的发展，现在可选的JS开发工具还是挺多的，如spket，eclipse的JS编写插件等。另外，如果你实在不想编写JS，学习GWT-EXT也是EXTJS的一种选择。


因此呢，如果你是高手，你在应用的同时，你得解决上述问题，这样才能让更多的普通应用者能够接受这门EXTJS，如果你是一名普通开发员，那好！将问题提出来，向别人咨询最佳方案吧，毕竟EXTJS开发成功的项目已经不是一个两个了。如果你是一位快速开发技术员，那么，请你再等等，等到EXTJS更加成熟的那一天的到来！

EXTJS的外观问题又不是什么难题，稍微用点工，先打好CSS的基础，再去研究EXT的扩展机制，会发现EXT本身的扩展机制做得相当的好，只可能是自己CSS功底不够，但不要老说EXT做出来都长一个样。而且用EXT扩展除了不直接支持可视化IDE（DW）以外，熟练以后效率是非常高的。

同意楼上观点,任何一门技术,要想合理部署在项目中,"分工"是第一步,只有了解内在,熟悉相关的技术,我想,EXTJS任何方面的东西都不是一件难事,关键是你想不想做,

我是说载入，不是下载，就算本地缓存了，用iframe方式还是要重新载入解析，这个过程对于ExtJS来说，还是有点慢的，这也是为什么很多人说ExtJS性能不好的原因。

另外，别指望浏览器的缓存能解决很大的性能问题，缓存的过程是，浏览器需要与服务器进行连接，然后对比各项需要加载的数据，光是这个过程也耗费一定的服务器资源的。

所以要使用ExtJS，首先要理解它，如果拿它来做Web Page，那真是侮辱了ExtJS，ExtJS是一个集成环境，载入一次之后，所有的应用就应该在这个集成环境中实现，而不是采用iframe那种方式，另开网页。

终于看到一个中肯的回复了，iframe共享库的方式肯定是行不通的，性能依然很低下。“载入一次之后，所有的应用就应该在这个集成环境中实现”这个才是正解，虽然不赞同“集成环境”的说法，应该是one page one application，但是OPOA太复杂了，有OPOA经验的不多，经常不自觉的又用传统WEB开发的思路来开发OPOA，导致很多问题

即使在JS效率低下的IE下，我们都已经有好几个项目上线了，除了我现在正在参与的项目逐渐转向不用iframe以外，之前上线的项目都是iframe的方式，所以我不知道你们还在反复强调解析的过程有多慢，有意义么？我认为和渲染比起来，解析JS源代码的过程算是比较快的了，主要的瓶颈是渲染慢。到目前为止进一步出现的两个误区：
1.渲染慢等于不可用？实际情况是，避免渲染慢的设计即可，而且这个很容易测试。设计UI的时候绕过少数的几种渲染慢的过程，传统的方式渲染速度也是有极限的，比如我的PIII 800的机器用IE打开verycd上的某些网页（下载数目比较多的列表），因为客户端CPU慢，也到极限了，时间长达10秒以上。

2.如果是某些人认为的解析和渲染慢，那和是不是公网应用还是内网应用就没有任何关系了，难道在内网中客户端的渲染速度就快了么？

继续我的论述：
1.我们目前的设计页面，据粗略估计，在网速能保证的情况下，还是以新浪为例，新浪没用EXT吧，新浪每次切换页面，解析和渲染速度（其实这个有点难以测算，掺杂了部分的下载时间，其实用网速更快的淘宝是一个很好的参照）是5秒，那我们用的iFrame方式一般也就1-4秒（当然也是掺杂下载时间在内的），这点时间和公网网速引起的延迟比起来，根本不值一提，所以我很疑惑你们提出的论断，怎么会有如此结论，我们项目一个接一个上线，用户体验都非常的不错，还在有人说公网不行，既然公网解析和渲染不行，内网就行了（因为还有很多人说EXT只适合内网，既然适合内网那请不要还在继续用解析渲染慢说ext不能适用于公网的理由）？

2.又有人说“浏览器需要与服务器进行连接，然后对比各项需要加载的数据，光是这个过程也耗费一定的服务器资源的”，请问这个是ext的特色么？任何页面都是这样的好不好，哦，你是指EXT比其他框架会产生更多的链接服务器的资源，是这个意思吧，请问证据在哪里？
就我对ext的了解，ext用了很多办法来减少和服务端的连接，绝对比某些传统网页要好。以yahoo为背景的若干条webpage的军规为例，比如JS文件打包成一个文件，和服务器只发一次请求验证是否过期，还有就是很多小图片合成一张大图片，用CSS定位为的方式截取其中的一小块，来达到减少服务器请求的次数，比如20张小图（大图作用不明显）片合成一张，20次请求就变成了1次。

3.从头到尾分析一下一个普通EXT的页面的耗费时间，首先因为用了Iframe方式，所以一个页面的“工作量”绝对是远远小于OPOA的页面的工作量的，这个是不能横向比较的。
首先从服务端获取html，这和其它方式没啥两样，然后根据HTML中的资源定义向服务端请求打包的js和css和html中直接已有的一些图片的加载，这些资源不是动态的，基本都可以命中本地缓存，因为是IFrame方式，主要的几个大的JS和CSS本地一定有了缓存的。然后是JS解析的过程，之前有人说这个速度很慢，我还是我的观点，这个过程请问慢到哪里去，拿出数据来，不要把渲染速度归结为解析速度。解析完毕后，渲染页面元素，同时渲染需要的css会再次发送一些小图片的请求（大部分也能命中本地缓存），同时还有1-3个必要的远程数据源的元素发出ajax请求，获取动态数据，如果是grid的话，获取到数据后又是一个渲染表格的过程（当然ext的grid在IE下渲染个数超过300个就会在客户端慢的让客户不能接受了，但是这可以通过分页或者livegrid避开的）。其他如果是form类的元素，拿到数据后就简单的填入数据的过程，速度肯定是相对很快的。至此页面显示完毕。

4.我不是否认OPOA，我们也在调整中，也在转向OPOA的方式。我的观点是，OPOA确实能减少一定的资源浪费的方式，当然比iframe方式要好。但是iframe的方式也不见得慢，慢的原因要详细分析不要主观臆断，我之前的叙述主要在将iframe和传统webpage方式的比较，不是和OPOA方式的比较，请注意了，不是和OPOA方式的比较，因为说到OPOA又有人回绕回来说一次性加载某些东西不适合webpage了。也就是说iframe方式不比传统方式差。

最后再简单说一下，第一次下载慢不是理由，很多网页上光是几张稍大的图片加起来就超过120KB的，难道很多webpage上都没有图片么；解析和一般渲染慢也不是理由，就因为是公网访问，在相对较慢（相对于局域网）的网速下，解析和渲染不是最主要的瓶颈，如果因为不合理的设计真的造成渲染慢，那这个页面在局域网中也是一样的，这和是不是webpage没有任何关系。

不要说什么“侮辱不侮辱”的空话，拿出具体的分析来证明你的观点。

我看这话题扯远了，我用2个简单的例子来说：
1、如果OAOP能实现的，为什么还要用iframe？为什么w3c会说：iframe is bad？为什么在各个标准组织中，所有的组织都极力反对iframe？
2、如果采用iframe，何必要用ExtJS这个庞然大物？用CSS+DIV+轻量级AJAX框架（比如JQuery、Dojo等）实现的网页并不比ExtJS的效果差，功能上也完全能和ExtJS媲美。
注：用CSS+DIV反过来并不是表示一定要用iframe，否则又要被抓字眼了。

最后我要强调这个“慢”字，慢不是有标准的，它只是人能接受的一个限度问题，假如google或者baidu再慢1、2秒，我也一样能接受，但是如果能快1、2秒，为什么不让它更快呢？