`
ppkosd
  • 浏览: 89775 次
  • 性别: Icon_minigender_1
  • 来自: 苏州
文章分类
社区版块
存档分类
最新评论

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

    博客分类:
  • ext
阅读更多
从现在EXTJS的普及程度来说,这个工具框架的应用程度已经可以与其同类产品DOJO一比高下了,但是,从国人应用方面来看,EXTJS对于很多人,包括一些正在使用的人也是相当的陌生.因而产生很多错误的理解

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

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

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

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

原帖:http://www.dojochina.com/index.php?q=node/912
分享到:
评论
65 楼 icewubin 2008-09-29  
peacock 写道
看来这个人火药的吃得不少,国内讨论技术的人总是喜欢用人身攻击的手段来进行压制性的发表自己的观点,但就是没有这么一个牛人能开发出一个国际性的东西出来,但只要张嘴,那可是国际性的。

我和你讨论再多也没什么意思,你觉得w3c不屑一顾,你大可自己搞出一套协议出来,让IE、FF、Opera这些浏览器来支持。

我说1句,你可以有10句,而且是那种得理不饶人的口吻,你爱怎么就怎么,这是你的自由。

对于ExtJS,我只想说一句:官方的ExtJS API和example都没有采用iframe,自认为有个性的就开发出一套比ExtJS更优秀的框架出来,自认为问w3c不好,那么也请弄出一套超越问w3c的标准来。

我就是要追随国际标准,因为我没这个能力去制定标准。

最后,算我错了,我不该捅马蜂窝。


问题是我没有说我支持iFrame,我一直强调是你反驳iFrame是采用的论据基本上都是有逻辑问题的,你怎么就不能正视自己没搞清楚解析和渲染的区别呢?还特地搬出w3c?你这是在讨论技术细节么?

你说我有火药味,原因就是首先是你为了维护你的观点,扯了很远的其他话题,不着边际的连Flex都说到了。这当然让人莫名其妙了,自己理解有误说错话,还硬要扯开话题。

你怎么还在说ext官方例子的问题,有没有认真看贴,我都说了好几次我没有支持iFrame。你还说我“自认为有个性的就开发出一套比ExtJS更优秀的框架出来”,有么?我有说过这样的话么?举个例子,我们公司自己的框架,用了Hibernate,难道我就能说我们开发出一套比Hibernate更优秀的框架了么?这算哪门子逻辑啊,我们不是金*蝶公司啊(笑)。我想和你交流一下autoLoad的技术问题,你就是这么回应的?怎么看都像是你在搞人身攻击啊。

为什么你不能正面讨论ext的解析问题(或者说解析和渲染)和是否适合webpage的问题呢?

如果让你有得理不饶人的感觉,我向你道歉。但是说还是要说的,我认为合理的使用ext完全是可以应用在website的。
64 楼 peacock 2008-09-29  
看来这个人火药的吃得不少,国内讨论技术的人总是喜欢用人身攻击的手段来进行压制性的发表自己的观点,但就是没有这么一个牛人能开发出一个国际性的东西出来,但只要张嘴,那可是国际性的。

我和你讨论再多也没什么意思,你觉得w3c不屑一顾,你大可自己搞出一套协议出来,让IE、FF、Opera这些浏览器来支持。

我说1句,你可以有10句,而且是那种得理不饶人的口吻,你爱怎么就怎么,这是你的自由。

对于ExtJS,我只想说一句:官方的ExtJS API和example都没有采用iframe,自认为有个性的就开发出一套比ExtJS更优秀的框架出来,自认为问w3c不好,那么也请弄出一套超越问w3c的标准来。

我就是要追随国际标准,因为我没这个能力去制定标准。

最后,算我错了,我不该捅马蜂窝。
63 楼 icewubin 2008-09-29  
说句题外话,autoLoad页面的方式bug也是不少的,不知道你使用的过程中发现多少。我们尽量使用JS直接渲染元素,不使用autoLoad方式的。这里说的JS开发的时候作为单独的JS在主页面中引入,发布的时候每个元素对应的JS打包在一起一次性下载,思路和各个小图片打包成一个大图片是一样的。

还有就是比如美工做一个帮助页面,有自己的CSS和一些div的ID,不能要求美工具有一定的水准来适应ext的autoLoad的,而且这种类似于帮助页面又不是什么很重要的交互页面,采用iFrame或者直接采用target=_blank最省事了。

类似场景还是不少的,其他例子如临时性的挂上某个老的页面(有时间再改造),或者是客户给的一些demo页面,我们现在就是两种方式都可以。
62 楼 icewubin 2008-09-29  
peacock 写道

W3C可以说IE不好,但是MS就会说IE好,很多用户也说IE好,相反,倒是没有谁会说iframe好!

你能找得出比ExtJS还要小的Ajax框架吗?另外你对Dojo可能有点误解,你如果要拿Dojo的UI或者Jquery的UI来和ExtJS比,那没可比性,确实比不赢,但是你别忘了,Dojo、JQeury可以不需要UI,这一点来说,它们就是轻量级的。事实上,几乎很少有人用Dojo的UI或者Jquery的UI来做Web开发,反过来倒是不会有人只用ExtJS的功能,而不用ExtJS的UI,因为ExtJS的功能和UI结合确实已经非常强大,但是这并不代表他们的功能就不如ExtJS,相反,在功能普及度上,Jquery和dojo要远远大于ExtJS,你完全可以用Jquery和dojo+CSS+DIV实现自己Web应用程序,界面和美观要看UI设计人员的水平了,因为ExtJS的UI也并不是最好的,相对于Flex,他们会觉得ExtJS的界面只是小菜一碟。

我并没有去反对ExtJS,事实正好相反,我个人是绝对支持ExtJS,因为我是开发人员,我对UI设计很是烦恼,而且也不是专业的,正好ExtJS为我做好了这一切。这一点我们是站在同一阵营的!核心的问题只是讨论是OAOP还是iframe,其实你们自己也认识到他们的优劣,否则你们也不会常识要转向OAOP了。


照你的逻辑,w3c说的任何话都可以当圣经来对待了,如果是的话,你就永远跟着w3c走好了,如果不是,就不要拿w3c来做论据,这种什么别人说过什么什么来做论据毫无营养。

我也可以对你说你对EXTJS有点误解,ext也能拆开用的,你不会拆是你的问题。而且ext中也可以使用jquery。使用EXT就是为了他的UI,用不用它的UI是另一个话题,你一定要拿一个网站说它的需求不需要这种程度的UI那是其他问题了,如果你要像taobao、yahoo那样造UI的轮子那也是其他的问题了。说到功能,没有什么像样的文档,修不完的bug的框架不认为这样的功能有什么实用价值。

还有请你讨论的时候把基础框架、基础功能和UI组件分开讨论,不要动不动就出现“功能普及度上,Jquery和dojo要远远大于ExtJS”,你说普及度也就算了,说什么功能普及度,请分开讨论。说到普及度,jquery刚出来的普及度就很高么,难道刚出来的jquery我也说他不好么?你说你这算什么推导逻辑?

我之前几贴讨论的核心是有些问题不是Iframe特有的,要引出那些也不是ext不适用于公网的论据。你怎么扯到flex上去了,引开话题还真快啊,请你到其他帖子继续你的flex论调好了(注意应该是flex适合公网的论调,啊,你说你不是这个意思,仅仅指界面的好坏,不好意思我们不是在讨论界面的好坏啊),搞清楚讨论的前提好不好。

什么时候本帖的核心是“是OAOP还是iframe”了,请你先看看楼主在说什么好不好,先前就是有人把话题引到iframe上,还说什么

peacock  写道

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

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

所以要使用ExtJS,首先要理解它,如果拿它来做Web Page,那真是侮辱了ExtJS。

我只是在反驳你的这个论调,不等于我支持iFrame。

你把解析和渲染混为一谈,解析是不可避免的,渲染通过设计是可以减少渲染时间的。很多人说ExtJS性能不好的主要原因除了渲染问题外,还有第一次下载慢的问题(他们不知道GZIP的实际效果,还不知道有浏览器缓存这回事),是两个问题共同造成这个误区的。

而且即使照你说的“解析性能不好”,这和webpage有关系么?内网还不是一样,请你不要避开这个话题。你的这个逻辑是有问题的。

还有我之前反驳你提到的关于“各项需要加载的数据,光是这个过程也耗费一定的服务器资源的”,你别绕开啊,继续说啊。
61 楼 peacock 2008-09-29  
icewubin 写道
peacock 写道
我看这话题扯远了,我用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秒,为什么不让它更快呢?


1.我说了没有说不用OPOA,我是和传统方式比,但是不要那一些莫名其妙的论据来证明iFrame不好。w3c或者其他机构说过很多xxx is bad,IE is bad,这些引用没有意义。那些组织反对iframe的理由并不是这里的帖子列出的理由。

2.谁说EXTJS是一个庞然大物了,用不好是个人问题,不要随便说某个东西是庞然大物,请问大在哪里?Dojo轻量么?你说那些效果比EXTJS要好,功能完全能媲美,那我就不和你讨论下去了。

3.再次重申没有说要大家采用iFrame,但是上面几篇否定IFrame的论据都是有问题的。希望大家理清思路。


4.如果能再快1、2秒,这我是完全同意的,我也说了我们在转向不用iFrame,但是不能说因为解析和渲染的问题,就不能用这么用,我反驳的是解析和渲染没什么大不了的,很多毛病传统webpage多的是。

你可能还没有看清楚问题的关键,我如果直截了当的说支持OPOA马上就会又有人跳出来说OPOA不适合webpage,再往下就不好讨论了,有些问题必须先说清楚,不是说我赞成iFrame,而是不是它的特有的问题不要加到它头上。


W3C可以说IE不好,但是MS就会说IE好,很多用户也说IE好,相反,倒是没有谁会说iframe好!

你能找得出比ExtJS还要小的Ajax框架吗?另外你对Dojo可能有点误解,你如果要拿Dojo的UI或者Jquery的UI来和ExtJS比,那没可比性,确实比不赢,但是你别忘了,Dojo、JQeury可以不需要UI,这一点来说,它们就是轻量级的。事实上,几乎很少有人用Dojo的UI或者Jquery的UI来做Web开发,反过来倒是不会有人只用ExtJS的功能,而不用ExtJS的UI,因为ExtJS的功能和UI结合确实已经非常强大,但是这并不代表他们的功能就不如ExtJS,相反,在功能普及度上,Jquery和dojo要远远大于ExtJS,你完全可以用Jquery和dojo+CSS+DIV实现自己Web应用程序,界面和美观要看UI设计人员的水平了,因为ExtJS的UI也并不是最好的,相对于Flex,他们会觉得ExtJS的界面只是小菜一碟。

我并没有去反对ExtJS,事实正好相反,我个人是绝对支持ExtJS,因为我是开发人员,我对UI设计很是烦恼,而且也不是专业的,正好ExtJS为我做好了这一切。这一点我们是站在同一阵营的!核心的问题只是讨论是OAOP还是iframe,其实你们自己也认识到他们的优劣,否则你们也不会常识要转向OAOP了。

60 楼 icewubin 2008-09-29  
peacock 写道
我看这话题扯远了,我用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秒,为什么不让它更快呢?


1.我没有说不用OPOA,我是和传统方式比,但是不要那一些莫名其妙的论据来证明iFrame不好。w3c或者其他机构说过很多xxx is bad,IE is bad,这些引用没有意义。那些组织反对iframe的理由并不是这里的帖子列出的理由。

2.谁说EXTJS是一个庞然大物了,用不好是个人问题,不要随便说某个东西是庞然大物,请问大在哪里?Dojo轻量么?你说那些效果比EXTJS要好,功能完全能媲美,那我就不和你讨论下去了。

3.再次重申没有说要大家采用iFrame,但是上面几篇否定IFrame的论据都是有问题的。希望大家理清思路。


4.如果能再快1、2秒,这我是完全同意的,我也说了我们在转向不用iFrame,但是不能说因为解析和渲染的问题,就不能用这么用,我反驳的是解析和渲染没什么大不了的,很多毛病传统webpage多的是。

你可能还没有看清楚问题的关键,我如果直截了当的说支持OPOA马上就会又有人跳出来说OPOA不适合webpage,由此再说EXT不适合webpage,再往下就又不好讨论了,有些问题必须先说清楚,消除一些基本的误区,不是说我赞成iFrame,而是不是它的特有的问题不要加到它头上。
59 楼 peacock 2008-09-29  
我看这话题扯远了,我用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秒,为什么不让它更快呢?
58 楼 icewubin 2008-09-29  
peacock 写道
icewubin 写道
peacock 写道
extjs有2种页面载入方式,如果采用frame方式载入,当然慢了,每次载入页面都要重新载入extjs,如果采用aotoLoad方式(ajax),速度还是很快的,extjs不需要再载入,只需要载入ajax就行了。
用extjs做了一些应用,没感觉到慢


就算每个页面用iframe的方式也慢不到哪里去,浏览器能缓存,绝对比每次打开新浪页面要快。


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

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

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


即使在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没有任何关系。

不要说什么“侮辱不侮辱”的空话,拿出具体的分析来证明你的观点。
57 楼 lonelyblue 2008-09-29  
peacock 写道
icewubin 写道
peacock 写道
extjs有2种页面载入方式,如果采用frame方式载入,当然慢了,每次载入页面都要重新载入extjs,如果采用aotoLoad方式(ajax),速度还是很快的,extjs不需要再载入,只需要载入ajax就行了。
用extjs做了一些应用,没感觉到慢


就算每个页面用iframe的方式也慢不到哪里去,浏览器能缓存,绝对比每次打开新浪页面要快。


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

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

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

终于看到一个中肯的回复了,iframe共享库的方式肯定是行不通的,性能依然很低下。“载入一次之后,所有的应用就应该在这个集成环境中实现”这个才是正解,虽然不赞同“集成环境”的说法,应该是one page one application,但是OPOA太复杂了,有OPOA经验的不多,经常不自觉的又用传统WEB开发的思路来开发OPOA,导致很多问题
56 楼 peacock 2008-09-29  
icewubin 写道
peacock 写道
extjs有2种页面载入方式,如果采用frame方式载入,当然慢了,每次载入页面都要重新载入extjs,如果采用aotoLoad方式(ajax),速度还是很快的,extjs不需要再载入,只需要载入ajax就行了。
用extjs做了一些应用,没感觉到慢


就算每个页面用iframe的方式也慢不到哪里去,浏览器能缓存,绝对比每次打开新浪页面要快。


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

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

所以要使用ExtJS,首先要理解它,如果拿它来做Web Page,那真是侮辱了ExtJS,ExtJS是一个集成环境,载入一次之后,所有的应用就应该在这个集成环境中实现,而不是采用iframe那种方式,另开网页。
55 楼 cheng022074 2008-09-28  
同意楼上观点,任何一门技术,要想合理部署在项目中,"分工"是第一步,只有了解内在,熟悉相关的技术,我想,EXTJS任何方面的东西都不是一件难事,关键是你想不想做,
54 楼 icewubin 2008-09-28  
EXTJS的外观问题又不是什么难题,稍微用点工,先打好CSS的基础,再去研究EXT的扩展机制,会发现EXT本身的扩展机制做得相当的好,只可能是自己CSS功底不够,但不要老说EXT做出来都长一个样。而且用EXT扩展除了不直接支持可视化IDE(DW)以外,熟练以后效率是非常高的。
53 楼 cheng022074 2008-09-28  
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更加成熟的那一天的到来!
52 楼 wopenonline111 2008-09-27  
笨笨狗 写道
7thbyte 写道
自己基于prototype造了无数轮子了。。

和自己的应用非常非常搭



哈哈,握手!
说实话,ext那些看起来不错的组件,自己用Prototype造一个也不是难事,不试试的话你无法知道其中的爽:)


造一个不难,但要造一堆组件,组件之间还能很好的相互合作,自成体系,形成框架,那就很困难了。也许这是为何现在优秀的js框架用手指都能数得过来。
51 楼 zhudp.cn 2008-09-27  
hemuxiao 写道
我现在用EXT做了一个交通厅的OA系统.不是远程的.感觉速度还行.能接受

你这个“不是远程的”是什么意思?
在同一台机子开一个web服务器?
50 楼 hepeng421 2008-09-27  
大家千万别上当信了那些广告,extjs我打死都不去用的
49 楼 hepeng421 2008-09-27  
extjs那么慢,压根儿就不适合企业应用,
48 楼 PlayGod1984 2008-09-26  
主题:谈一谈我对于目前国人对于EXTJS的错误看法
看看这个题目,你看了几本破教程就敢说目前国人的看法,你也太不负责任了
还有,他们代表不了国人
你也别把extjs吹得太玄胡其神了。
47 楼 onlydo 2008-09-25  
kimmking 写道
这些问题讨论过很多次了。

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


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



顶。咱正用得不亦乐乎。
46 楼 vip01 2008-09-24  
火星叔叔马丁 写道
web方面 用不到ext这个杀猪刀
企业开发 有flex这个屠龙技术纲要 还是用不到这个杀猪刀

相当同意
严重同意

jquery是瑞士军刀,可以在所有web项目里面来一下
可以解决各种问题
但是他是便携的轻量级的,我可以放心的用

在可以用ext的地方,指可以接收ext这么重量级js的地方
那我宁愿用flex,更好的开发效率,更容易维护,效率也更高

所有ext生不逢时。

另外看到个别同志还提到dojo
我好心提醒一下,碰都别碰
我们公司有一个产品就是用dojo在做一个“伟大的”平台
那其中的辛酸血泪史真是。。。。。。。。。。。

相关推荐

    extjs4.0.7附带的jsb3文件,已修正路径错误

    值得注意的是,虽然EXTJS 4.0.7已经是一个较老的版本,但了解如何使用JSB3文件对于理解EXTJS的优化流程仍然很有价值。随着EXTJS版本的更新,例如EXTJS 6及以上版本,JSB3文件逐渐被SASS(Syntactically Awesome ...

    extjs资料extjs资料extjs资料

    1. **Ext 中文文档.chm**:这可能是一个包含ExtJS API的中文帮助文件,对于初学者和有经验的开发者来说都是极有价值的参考。在其中,你可以找到ExtJS类库的详细说明,包括各种组件、方法、事件和配置选项,有助于...

    extJs3升级extjs4方案

    ExtJS3 升级到 ExtJS4 需要修改大量代码,主要是因为 ExtJS4 配备了一类新的系统,不向后兼容。在 ExtJS 3 里生成表的几个框架组件,ExtJS4 大多生成 div,这使得 CSS classes 将会失败。ExtJS4 已完全重新写 grid ...

    Extjs例子Extjs例子

    Extjs例子Extjs例子Extjs例子Extjs例子Extjs例子

    EXTJS应用EXTJS应用EXTJS应用EXTJS应用

    EXTJS是一种基于JavaScript的前端开发框架,用于构建富互联网应用程序(RIA)。EXTJS的应用主要体现在其强大的组件模型、丰富的用户界面以及高效的数据显示上。EXTJS提供了大量的预定义组件,如表格、面板、菜单、...

    Extjs 2.2 Extjs 3.21 js

    这两个版本在Web开发领域都有着广泛的运用,它们各自拥有不同的特性和改进,对于理解ExtJS的发展历程和选择适合项目需求的版本至关重要。 首先,我们来看ExtJS 2.2。这个版本是ExtJS早期的一个稳定版,发布于2008年...

    extjs图标大全extjs图标大全extjs图标大全extjs图标大全

    ExtJS图标大全是一个集合了多种图标的资源库,特别适合用于Web开发,尤其是使用ExtJS框架构建用户界面时。ExtJS是一款强大的JavaScript UI框架,它提供了丰富的组件和工具,帮助开发者构建功能丰富的、响应式的Web...

    extjs流程界面设计器参考_ExtJS工作流设计器_extjs工作流_extjs_

    ExtJS是一种广泛使用的JavaScript库,专门用于构建富客户端的Web应用程序。它提供了丰富的组件和工具,使得开发者可以创建出功能强大、用户界面友好的Web应用。在“extjs流程界面设计器参考”中,我们主要关注的是...

    extjs-OA extjs-oa

    一个extjs的OA项目 extjs-OA extjs-oaextjs-OA extjs-oa

    ExtJS快速入门 ExtJS快速入门 ExtJS快速入门

    ExtJS快速入门 ExtJS快速入门 ExtJS快速入门 ExtJS快速入门 ExtJS快速入门 ExtJS快速入门 ExtJS快速入门 ExtJS快速入门 ExtJS快速入门 ExtJS快速入门 ExtJS快速入门 ExtJS快速入门ExtJS快速入门 ExtJS快速入门 ExtJS...

    ExtJS2.0教程.chm +Extjs2.2.1压缩包

    ExtJS 是一个流行的JavaScript库,专门用于构建富客户端Web应用程序。这个压缩包包含了关于ExtJS 2.0的教程以及ExtJS 2.2.1的资源,这为我们提供了学习和开发基于ExtJS的应用程序的基础。 `ExtJS2.0教程.chm`:这是...

    ExtJs学习笔记 ExtJs Api

    适合ExtJs开发人员extjs技术上手以及深入

    ExtJS项目 一个博客系统

    ExtJS项目 一个博客系统 ExtJS项目 一个博客系统

    extjs icon小图标

    总的来说,这个"extjs icon小图标"资源对于那些使用ExtJS或EasyUI的开发者来说非常有价值,它提供了一个丰富的图标库,可以极大地提高开发效率,同时提升应用的视觉品质。合理地利用这些图标,可以创建出专业、用户...

    ExtJS经典皮肤集合

    ExtJS是一款功能强大的JavaScript前端框架,它为开发者提供了构建富客户端Web应用的工具。这款框架以其丰富的组件库、可定制的界面和强大的数据绑定机制而闻名。标题中的"ExtJS经典皮肤集合"指的是该框架中包含的一...

    ExtJS2.0简明教程

    ExtJS 是一个很不错的Ajax 框架,可以用来开发带有华丽外观的富客户端应用,ExtJS 是一个用javascript 编写,与后台技术无关的前端ajax 框架。可以把ExtJS 用在.Net、Java、Php 等各种开发语言开发的应用中。教程...

    extjsapi/extjs3.4

    extjsapi,extjs文档,api手岫

    extjs收费文档extjs

    extjs的收费文档,需要的看看。 一个入门的很好教程。 extjs的收费文档,需要的看看。 一个入门的很好教程。

    extjs技术文档资料

    而“逃学大乱斗V3.4最终版.w3x”看起来并不直接相关,它更像是一个Warcraft III的游戏地图文件,可能是在错误的文件夹中被包含进来,或者是一个与EXTJS无关的个人项目。 总的来说,这份EXTJS技术文档资料将帮助...

Global site tag (gtag.js) - Google Analytics