泡网俱乐部

EXT的力量 ---- 浅谈EXT的影响
Ext现在在je里的人气越来越旺了, 我想任何了解ext的人 对这种人气的兴旺不会有丝毫的惊奇.

它所爆发出的力量瞬间摧毁了ajax领域内所有的竞争对手,很多有多年历史的商业软件也没能幸免.


但是正如 7thbyte 所说 "AJAX不应该只是EXT" [url]http://www.javaeye.com/topic/184120[url]
他的这个观点我也很认同, 对于大多数使用Ext的人来说,ext只是一个工具,
一个"能够更漂亮地把自己的界面需求制作出来，提供更好的交互性(7thbyte语)"的工具.

大家在关注工具如何使用的同时, 也应该留心一下工具背后所蕴含的技术以及意义.
并且时刻留心下一个ext的出现.

在下一个ext出现之前,我想说一说在我的眼中 EXT除了作为工具本身固有的价值外,它对于web开发领域还产生了哪些影响.
说的不一定准确,欢迎大家纠正和补充.

EXT的影响:

1 让更多的人意识到了ajax的强大,使更多的人投入到ajax开发的大军.

2 改变了人们开发页面组件的习惯.
让以前习惯写 的开发者们改用 new Panel+json参数 来表达自己的思想.
而这种改变依然保留了web开发的纯洁性.(客户端ui组件的开发只依赖客户端技术,为开发测试带来了极大的方便)
同时,让在大学里长期接受c++ java .net 教育的开发者们倍感亲切.


3 对html的现有模型进一步的提炼,提取出了较大粒度的组件.以及一整套ui组件模型.
有这个模型在,语言 运行环境这些就都是次要的了.基于这个模型,未来的ext也许会更加的"为所欲为".



4 减缓了RIA普及的脚步(ext之类的ajax的组件严格意义上将不属于RIA,只是类似RIA).
RIA这个名词出来很多年了,flex Laszlo之流正要展现自己的实力时,ext狠狠的打击了他们的嚣张气焰.


5 把页面开发引入了又一个全新的阶段.下文中的第4个阶段.

客户端ui组件的开发经历了如下几个阶段(仅代表个人观点):

第一阶段, web开发初期, 开发人员写html 写css 写js,一个人都包了.
结果是一个人累的半死 效果却不好.

第二阶段, 出现了程序员GG和美工MM的分工合作. 美工mm用ps或其他类似的工具画图 切图.
程序员GG来把那些图变成 html css js
结果, 很多东西 画起来简单,代码写起来难, 而且那时候的美工基本上web开发知识贫乏,所以和程序员的交流配合有很多问题

第三阶段, 随着asp php jsp的流行,美工开始专业化,美工不光要会画图,还要熟悉css和html,甚至要理解一些标签 脚本语言等等.

必要的时候还要由美工亲自上阵来修改网页文件.程序员则依然要懂得 html css js.

第四阶段 ,组件化开发阶段.美工主要做的也就是改一改图片 改一改css里的颜色,而这个工作完全可以由程序员自己来做.甚至可以

不做,因为组件的皮肤可以网上下载,或者是由组件提供商提供. 可以这么说,页面美工被边缘化了.当然纯美术相关的东东,如设计

logo 设计icon 设计网站的总体色调等 还是要美工的鼎立相助的. 程序员依然要懂得html css js. 但是对 html和css的要求难度

较前几个简短低, 对js的要求相对较高.


6 ext让我们对未来充满了幻想和期待.
在js1.5 html4 上, 尚能产生这样的杰作, 那么未来js2 html5来临时,web开发又将迎来怎样美好的明天呢?让我们拭目以待吧.

* 01:18
* 浏览 (2348)
* 评论 (20)
* 分类: js & ajax
* 相关推荐

评论
sp42 昨天
axel说得没错
另外ext正在构建自己的DSL（Domain Spec. Language）
像Ext.overrie,Ext.IsArray等的类型判断等等 不一而足。
axel 昨天
Ext仅仅是界面吗？
Ext是给了你一个客户端的开发框架，这点是其它ajax产品所不具备的。也就是为什么会有人喜欢ext,因为ext几乎给了你客户端的所有。
使用Ext当然一定要应用场景，不是什么网页都去使用ext.
Ext也可以变得很灵活，很多人都不习惯ext的form，但只要在ext上再开发一层，你完全可以自由地去定义form然后利用ext的form相应的功能包括验证。
笨笨狗 昨天
其实，从国外各大出版社的书籍来看，ext远远不能跟Prototype、JQ这些框架相比，人家是商人……
fins 昨天
"JS本省就是过程脚本语言"?
lprince 昨天
界面没太大的意思，不太符合中国人的习惯。

太追求对象性了，而JS本省就是过程脚本语言，不应该给它太多的炫耀的资本。
个人不太看好AJAX，枯燥无味，没有点技术含量。
wfdoublext 前天
不是很看好EXT，虽然做过一些东西。
indexchen 前天
不想写js，就用GWT，或GWT-Ext
KKFC 前天
我从不用EXT 的 FORM 因为这样就失去了自己写程序的特色了
不一定全披上EXT的外衣。
java_2006 前天
还是觉得要写很多JS代码，不好控制，特别是form。。。
Arden 前天
ext 还是太大了，速度令人人有点害怕，使用起来复杂、写js文件太多。
fangzhouxing 前天
写得好,中肯!精彩!
KKFC 前天
从JACK的早期博客文章可以看出,ext的设计是很重视性能的.
http://ajaxjs.com/blog/html/104141328/
应该说到这份上,应该做得可以说都做了...
fins 前天
引用
至少我们大多数人写不出同等效果下，效率比它更高的代码

这个观点很赞同

很多人都抱怨EXT慢, 但是这里的慢,是和及其简陋的组件做的比较.
这种比较是不公平的.

采用类似的技术 达到和ext一样的效果 ,确实很难.
虽然ext有很多不足 , 但是"给ext挑毛病"和"写出比ext更好的组件"完全不是一个等级的事情.
综合衡量, ext在同类产品里 已经是目前最好的了

补充:
不过我依然对ext在企业中的应用比较担忧, 一个开发团队或者是客户,被ext的外表所迷惑,而不去考衡自己所拥有的开发人员的能力,轻易的去使用ext还是有一定风险的.
建议:
通常情况下,开发团队中, 一定要有至少一个人 对ext和js非常熟悉.
如果团队规模大,开发人员很多,那么应该保证3%的人对ext和js非常熟悉.

其他人简单看看文档 看看例子 看看api 应该很容易就能学会使用ext的.
ext不可能比swing更难.
icewubin 2008-04-20
之所以这么说，因为有时候架构师根据各方涉众，举丽交涉，避开或者绕开一些棘手需求，可以化解甚至完全绕开一些导致性能问题的需求。

还有就是好的架构随时都有候补方案，像我们公司的方案就是，实在不行，各种其他途径都不解决的话，就不用EXT，直接用FreeMarker写页面，最多风格不是很一致而已。

在客户端执行效率上，EXT算是很好的，至少我们大多数人写不出同等效果下，效率比它更高的代码。
icewubin 2008-04-20
引用
其实现在瓶颈并不在上百k的js，一般的图片都要上百k。目前的性能瓶颈主要在ext的本地执行上，脚本在浏览器上的解释运行速度太慢。如果有JS虚拟机的话，渲染速度一定能大幅提升。可惜没有，不知道各位怎么解决的！


避免设计出会导致性能问题的客户端代码，需要从需求导向上着手，在调整UI交互模式可以绕开一些问题。

一般来说，只要架构师不要太烂，都会有不止一个的解决方案，这个时候架构师的好坏决定了底层程序员的工作量。
lgn21st 2008-04-20
我没有在前台开发以及js上很深的造诣,但是从fins子里行间中可以窥见fins这种从本原思考,洞悉技术发展本质的思想,赞一个,真希望可以有多几张投票来顶fins.
pharaohsprince 2008-04-19
客户端ui组件的开发经历了如下几个阶段:
总结的太好了！！！！！！！！！！
ldjsyl 2008-04-19
引用
一直都没时间尝试ext，但是一看到上百k的js，真的是望而却步。至少在目前服务器资源跟带宽都有限的状态下，我觉得ext要达到普及还不是时候。

其实现在瓶颈并不在上百k的js，一般的图片都要上百k。目前的性能瓶颈主要在ext的本地执行上，脚本在浏览器上的解释运行速度太慢。如果有JS虚拟机的话，渲染速度一定能大幅提升。可惜没有，不知道各位怎么解决的！
playfish 2008-04-19
一直都没时间尝试ext，但是一看到上百k的js，真的是望而却步。至少在目前服务器资源跟带宽都有限的状态下，我觉得ext要达到普及还不是时候。

还是喜欢jquery，轻巧。不过缺陷就是它的ui现在还不够成熟，问题还很多。但是我觉得最好的地方在于它采用core+plugin来完成功能，这样的方式可以实现按需引入，而且方式很简单。没用过ext，不清楚ext的做法？ext是否是上百k的core js，如果要按需引入的话还要自己去裁剪？
sp42 2008-04-19
同感“EXT的影响:”之第四点，呵呵。忆起：

引用
如果采用 RIA 开发网站，和传统 web 开发有两点很大的区别，一是：对于服务端 View 层的依赖就没有了， 二是: 不需要在 server 端保存 session 信息。 无论是 rails, 还是 php, python, java 的各种 web 框架，session 和 server view 都是必须的， 从上个世纪中期到现在10年多的时间里， web 的发展和 http 本身无状态的特点使得我们无法脱离这两点来开发网站，几乎所有web 框架都会涉及到它们， 但是都会采用各自的方法来解决，每个方案都没有本质的不同，却在形式上差别很大，服务端 view 技术可能是每个框架中最麻烦的部分.


ext这类的框架（*注）的出现好像有点柳暗花明又一村，不过方向我觉得未来的RIA会强大很多，例如做做视频会议等好玩的内容。

*注：或者说“泛ext”的框架，ext说太多了 一定是那个“审美疲劳的”。好像现在，我都
全局多个变量了： obj = page = UI = Ext; 不用抬头满天星星都是'ext'云云~
链接

• 相关回复