2007-08-02
AJAX与RIA技术之我见
关键字: ajax flex
DHH于6月底曾经发表过一篇文章,名为《我就喜欢HTML/CSS/JavaScript,那又怎么样!》,大意是说,目前热炒的RIA技术并不能够取代AJAX技术,而事实上我们还没有发挥出HTML的全部潜力,我本人很享受HTML/CSS/JS给给我的开发体验云云。
我比较赞成DHH的观点,从另外一些角度谈谈我对RIA技术,主要是Flex的看法。
我在2004年曾经指导一个企业应用系统的开发,这个系统提出了比较高的实时反馈和交互式要求。由于同时有两个flash高手加盟,我们决定采取基于flash的RIA技术:
对于交互要求非常高的部分使用flash开发,flash通过AMF协议和服务器端通讯,服务器端使用了OpenAMF这个开源框架,可以解析AMF请求,转化为对Spring bean的调用,这个架构是一个标准的分布式系统调用:
flash <-----AMF-----> OpenAMF网关 <--> Spring Ioc
和现在很多人普遍采用的AJAX DWR框架是一个道理:
IE <-----XHR-----> DWR <--> Spring Ioc
客户端的flash是先用Flash IDE画好界面元素,保存为fla文件,然后程序员使用ActionScript编写代码,和服务器端进行交互。这是一个标准的基于Flash的RIA方案,但是项目最终放弃了Flash RIA。
时至今日,REST+Flex又被作为一个非常热门的方案被提出来了,那么REST+Flex比2004年我们采用的AMF+Flash方案有什么区别呢?
一、服务器端和客户端交换数据的方式不同
1、AMF+Flash采用的是标准的RPC方式,这种方式的被广泛的使用在EJB,XML-RPC,DWR等等,这种方式的缺点这里不赘述了,JavaEye以前有大量的讨论
2、REST+Flex采用的是REST方法,这种方式是现在非常热门的轻量级分布式系统解决方案之一,优点也不赘述了,JavaEye也有大量讨论
二、客户端描述界面的方式不同
1、AMF+Flash采用标准的Flash IDE来画界面,保存为fla后缀的二进制文件,界面文件不可直接用文本编辑器编辑,一般程序员很难使用。
2、REST+Flex采用Flex Builder来画界面,或者用文本编辑器手工编写MXML,这是一种带有namespace的XML的文件,程序员比较容易使用。
通过比较我们可以发现,REST+Flex的方案已经前进了一大步,但是我还没有提到为什么2004年那个Flash RIA方案会失败,为什么呢?失败的最重大的原因在于开发成本!
你会说,我们用AJAX开发成本也很高阿,HTML/CSS/JS跨浏览器兼容性的成本非常高。Flash不用考虑跨浏览器,界面还可以用IDE直接画,AS代码和MXML界面彻底分离,多棒的MVC,开发效率怎么想都比AJAX低很多。不错,Flash没有跨浏览器开发成本,但是Flash有一个巨大的和网页交互的成本。
这又牵扯出来一个更深层次的问题:互联网传播的主要载体是什么?文本?图片?视频?还是其他的什么?
HTML的诞生是适应于互联网大量文本内容的传播的,只要你的web应用还是以文本为主,就必须以HTML为主,这一点无法改变。那么就意味着你的Flash RIA必须要大量的和HTML页面进行交互。(也有一些纯网络游戏或者休闲游戏网站是纯flash的,几乎没有HTML,但这不是我们讨论之列)
所以问题就在于Flash和网页的大量交互,但很遗憾的是Flash操纵网页DOM的能力很弱,与传统的JavaScript无法相提并论!所以你会遇到各种意想不到的问题,而这些问题原本用JavaScript却是很简单的事情,例如驱动网页导航,刷新,打开关闭窗口,DIV隐藏显示等等,开发成本就是这么不知不觉升上来的。最终你会发现Flash的开发成本太高!
其实这不能怪Flash,根源在于:你开发的web应用最终还是一个基于文本形式的,所以你就无法使用纯Flash应用(Flash对于文本支持能力又很弱),必须大量依赖HTML;而要大量操纵HTML,最趁手的工具就是JavaScript,而Flash就是一个很蹩脚的工具,无论它的多媒体表现能力多么强大。
SilverLight能改变这一点吗?不能!Microsoft发明XMLHTTP绝对是天才的创意,XMLHTTP之所以成功根本原因在于它和HTML的良好交互性,而且使用JS操纵。SilverLight只是Flash的一个模仿品,却完全没有看到Flash的局限性在哪里?所以SilverLight完全继承了Flash的致命缺点。这也只能说明SilverLight是Microsoft商业竞争的一种手段,而不是本着创新精神去做的东西。
现在开发AJAX的确有其痛苦之处,跨浏览器兼容性是最让人头疼的。但是我们应该清楚,只要web应该是基于文本形式这一点不改变,那么HTML/JS的地位就不会改变,那么AJAX无论如果都是web开发之首选技术。
我比较赞成DHH的观点,从另外一些角度谈谈我对RIA技术,主要是Flex的看法。
我在2004年曾经指导一个企业应用系统的开发,这个系统提出了比较高的实时反馈和交互式要求。由于同时有两个flash高手加盟,我们决定采取基于flash的RIA技术:
对于交互要求非常高的部分使用flash开发,flash通过AMF协议和服务器端通讯,服务器端使用了OpenAMF这个开源框架,可以解析AMF请求,转化为对Spring bean的调用,这个架构是一个标准的分布式系统调用:
flash <-----AMF-----> OpenAMF网关 <--> Spring Ioc
和现在很多人普遍采用的AJAX DWR框架是一个道理:
IE <-----XHR-----> DWR <--> Spring Ioc
客户端的flash是先用Flash IDE画好界面元素,保存为fla文件,然后程序员使用ActionScript编写代码,和服务器端进行交互。这是一个标准的基于Flash的RIA方案,但是项目最终放弃了Flash RIA。
时至今日,REST+Flex又被作为一个非常热门的方案被提出来了,那么REST+Flex比2004年我们采用的AMF+Flash方案有什么区别呢?
一、服务器端和客户端交换数据的方式不同
1、AMF+Flash采用的是标准的RPC方式,这种方式的被广泛的使用在EJB,XML-RPC,DWR等等,这种方式的缺点这里不赘述了,JavaEye以前有大量的讨论
2、REST+Flex采用的是REST方法,这种方式是现在非常热门的轻量级分布式系统解决方案之一,优点也不赘述了,JavaEye也有大量讨论
二、客户端描述界面的方式不同
1、AMF+Flash采用标准的Flash IDE来画界面,保存为fla后缀的二进制文件,界面文件不可直接用文本编辑器编辑,一般程序员很难使用。
2、REST+Flex采用Flex Builder来画界面,或者用文本编辑器手工编写MXML,这是一种带有namespace的XML的文件,程序员比较容易使用。
通过比较我们可以发现,REST+Flex的方案已经前进了一大步,但是我还没有提到为什么2004年那个Flash RIA方案会失败,为什么呢?失败的最重大的原因在于开发成本!
你会说,我们用AJAX开发成本也很高阿,HTML/CSS/JS跨浏览器兼容性的成本非常高。Flash不用考虑跨浏览器,界面还可以用IDE直接画,AS代码和MXML界面彻底分离,多棒的MVC,开发效率怎么想都比AJAX低很多。不错,Flash没有跨浏览器开发成本,但是Flash有一个巨大的和网页交互的成本。
这又牵扯出来一个更深层次的问题:互联网传播的主要载体是什么?文本?图片?视频?还是其他的什么?
HTML的诞生是适应于互联网大量文本内容的传播的,只要你的web应用还是以文本为主,就必须以HTML为主,这一点无法改变。那么就意味着你的Flash RIA必须要大量的和HTML页面进行交互。(也有一些纯网络游戏或者休闲游戏网站是纯flash的,几乎没有HTML,但这不是我们讨论之列)
所以问题就在于Flash和网页的大量交互,但很遗憾的是Flash操纵网页DOM的能力很弱,与传统的JavaScript无法相提并论!所以你会遇到各种意想不到的问题,而这些问题原本用JavaScript却是很简单的事情,例如驱动网页导航,刷新,打开关闭窗口,DIV隐藏显示等等,开发成本就是这么不知不觉升上来的。最终你会发现Flash的开发成本太高!
其实这不能怪Flash,根源在于:你开发的web应用最终还是一个基于文本形式的,所以你就无法使用纯Flash应用(Flash对于文本支持能力又很弱),必须大量依赖HTML;而要大量操纵HTML,最趁手的工具就是JavaScript,而Flash就是一个很蹩脚的工具,无论它的多媒体表现能力多么强大。
SilverLight能改变这一点吗?不能!Microsoft发明XMLHTTP绝对是天才的创意,XMLHTTP之所以成功根本原因在于它和HTML的良好交互性,而且使用JS操纵。SilverLight只是Flash的一个模仿品,却完全没有看到Flash的局限性在哪里?所以SilverLight完全继承了Flash的致命缺点。这也只能说明SilverLight是Microsoft商业竞争的一种手段,而不是本着创新精神去做的东西。
现在开发AJAX的确有其痛苦之处,跨浏览器兼容性是最让人头疼的。但是我们应该清楚,只要web应该是基于文本形式这一点不改变,那么HTML/JS的地位就不会改变,那么AJAX无论如果都是web开发之首选技术。
评论
chuan315
2008-08-01
早就看到新闻了,说google,雅虎要开始支持flash搜索了。。。
chenjf2k
2008-07-02
快一年过去了,不知robbin对RIA的看法是否有变化?是否会觉得Flex+ROR REST 会是企业级应用(并非网站)的极好选择?谢谢!
咖啡舞者
2007-11-12
用FLEX的时候用FLEX,用AJAX的时候用AJAX。
可以同时用到嘛。
可以同时用到嘛。
jasongreen
2007-11-04
说到底还是性能与开发框架
dichengis
2007-11-04
那个apollo不是html,js和flex都可以的嘛!不知道是否是可以同时使用.
halfmile
2007-10-29
存在总是有道理的,
看看这个
http://preview.getbuzzword.com/
然后再是这个
http://blog.virtub.com/?p=8 - 为什么他们选择了flash而不是 ajax
看看这个
http://preview.getbuzzword.com/
然后再是这个
http://blog.virtub.com/?p=8 - 为什么他们选择了flash而不是 ajax
wuts
2007-10-09
看好Adobe AIR在桌面上的应用,比用VC++、VB编写桌面程序简单多了,当然目前功能有点弱。
sp42
2007-10-07
最近看中adobe AIR,对小弟来说,最大的卖点就是use existing skill(s) to develop,而且win2k上也可以用了。
年复一年,日复一日,不断升级,娴熟的技能不断被推翻,何必呢?
年复一年,日复一日,不断升级,娴熟的技能不断被推翻,何必呢?
ileile
2007-10-07
LZ明显没有了解过SilverLight就开腔...
afcn0
2007-09-30
对于SilverLight的观点不是很同意,xaml就是文本,1.0就是使用js来操作xaml的,使用上感觉就是一个canvas的实现,xmal里面起名也是canvas,和flash感觉不一样,都是xaml文本,应该有前途
swingchen
2007-09-30
Flex与基于传统技术的AJAX各有各的优缺点,这点毋庸置疑,对于交互性强偏向用Flex技术,对于传统以文本为的web网站,还是偏向于当前的AJAX技术。不过我个人的观点还是偏向Flex技术
1. 虽然DHH说目前还没发挥HTML的全部潜力,但只要底层支持的技术没更新改变,估计也是差不多了吧(说这话不小心会遭人口水)!现在想想底层技术还能有多大改动呢,JS2.0!CSS再增强!
2. FLEX目前是有些缺点,但毕竟目前势头凶猛,不对它看好的RIA爱好者,我想还是有必要好好去关注一下,尤其是IDE转移到ECLIPSE上之后,这也代表了Adobe发展Flex的决心,而且也开源很多项目。
3. 另外,Robbin说的没错:“只要web应该是基于文本形式这一点不改变,那么HTML/JS的地位就不会改变,那么AJAX无论如果都是web开发之首选技术”,那就得看web应用基于文本形式还能撑多久的问题了,现在网民对用户体验的要求可是越来越高了,当文本展现形式弱化的时刻,也就Flex相关技术成熟的时刻,到时关注可就晚了,况且Flex技术对文本的处理又不是一个不能解决的问题。
4. 最后补一点,对于基于B/S架构的软件开发(注:不是WEB)更应该关注Flex相关技术的进展与储备,对于这些传统类似管理软件来说,Flex技术可正合许多用户的胃口哟……
1. 虽然DHH说目前还没发挥HTML的全部潜力,但只要底层支持的技术没更新改变,估计也是差不多了吧(说这话不小心会遭人口水)!现在想想底层技术还能有多大改动呢,JS2.0!CSS再增强!
2. FLEX目前是有些缺点,但毕竟目前势头凶猛,不对它看好的RIA爱好者,我想还是有必要好好去关注一下,尤其是IDE转移到ECLIPSE上之后,这也代表了Adobe发展Flex的决心,而且也开源很多项目。
3. 另外,Robbin说的没错:“只要web应该是基于文本形式这一点不改变,那么HTML/JS的地位就不会改变,那么AJAX无论如果都是web开发之首选技术”,那就得看web应用基于文本形式还能撑多久的问题了,现在网民对用户体验的要求可是越来越高了,当文本展现形式弱化的时刻,也就Flex相关技术成熟的时刻,到时关注可就晚了,况且Flex技术对文本的处理又不是一个不能解决的问题。
4. 最后补一点,对于基于B/S架构的软件开发(注:不是WEB)更应该关注Flex相关技术的进展与储备,对于这些传统类似管理软件来说,Flex技术可正合许多用户的胃口哟……
antonio99
2007-08-28
在我看来,RIA提供了一个更坚实的基础——让很多公司把它们原有基于OS的软件产品客户端更容易地搬到网上来,比如办公软件,工作流客户端,...
paranoid945
2007-08-20
flex最终还是会火的,不过对html和ajax的影响不会太大。当然n年之后就不一定了,说不定那时候客户端别说文本,连3D都会很流畅的支持呢。预测未来,有很多东西可以想得更远,想想小时候玩的小霸王,再想想现在XBOX逼真得吓人的即时演算,仅仅过了10年多,那么10年之后是什么样子呢?20年之后3D的逼真程度和越来越低的成本是否可以代替演员?
一切皆有可能。
一切皆有可能。
sp42
2007-08-20
基本上Adobe是全盘通吃的策略。
美工出身的,或者玩过美工的,选取Flex 没问题;
程序员熟悉html/js的 但不熟悉时间轴、帧之类的,选取AIR,可利用旧有的知识。
当然不是说美工不熟悉html/js、做程序的搞flex会难用。
--哈哈 乱说了 可能flex现在都不用帧了(小弟是Ajax派,不懂flex 莫怪!)
美工出身的,或者玩过美工的,选取Flex 没问题;
程序员熟悉html/js的 但不熟悉时间轴、帧之类的,选取AIR,可利用旧有的知识。
当然不是说美工不熟悉html/js、做程序的搞flex会难用。
--哈哈 乱说了 可能flex现在都不用帧了(小弟是Ajax派,不懂flex 莫怪!)
terryzhou
2007-08-19
偶以前2000年是做FLASH的,2003年开始搞J2EE到现在,我觉得我还是比较有发言权的.
FLASH和JAVASCRIPT之间的通讯是很早就有了,并不是什么FLASH8才有的...
当初玩FLASH,就是因为做出来的东西太COOL了...其实在学校时候是学计算机的,但是在看了闪客帝国上外国闪客做的东西后..@#$%
那时候觉得如果FLASH能做UI的话,绝对是划时代的,但老实说,那时候用FLASH做UI..开发量是相当巨大的(FLEX真正改变了这点)....
今年6月份的时候因为工作原因研究了下FLEX,感觉开发起来和之前FLASH4(MX)时代简直是天壤之别....
我同样赞同FLEX不适合开发文字过多的UI,例如门户之类的,但一般的应用,FLEX做出来的用户体验绝对是其他任何技术无法比拟的....各种控件一应俱全,比JSF要好多了(东拼西凑)..
FLASH和JAVASCRIPT之间的通讯是很早就有了,并不是什么FLASH8才有的...
当初玩FLASH,就是因为做出来的东西太COOL了...其实在学校时候是学计算机的,但是在看了闪客帝国上外国闪客做的东西后..@#$%
那时候觉得如果FLASH能做UI的话,绝对是划时代的,但老实说,那时候用FLASH做UI..开发量是相当巨大的(FLEX真正改变了这点)....
今年6月份的时候因为工作原因研究了下FLEX,感觉开发起来和之前FLASH4(MX)时代简直是天壤之别....
我同样赞同FLEX不适合开发文字过多的UI,例如门户之类的,但一般的应用,FLEX做出来的用户体验绝对是其他任何技术无法比拟的....各种控件一应俱全,比JSF要好多了(东拼西凑)..
iiley
2007-08-18
文字为主的网站用Flex/Flash就是脑子进水了:)
图片为主的呢,各有优势,都可以。
Web Application的话,也要看情况,像GMail, Google Docs这样的,事实证明了AJAX非常适用,如果用Flex/Flash,估计效果不会好。
图片编辑类型的Web Application,Flex/Flash就明显占优势了。
当然仅限于编辑功能那部分,浏览部分,另当别论。
这样看来,Flex/Flash在Web上发挥的空间还是不大的,只有一些特定的地方,有特别的优势。
图片为主的呢,各有优势,都可以。
Web Application的话,也要看情况,像GMail, Google Docs这样的,事实证明了AJAX非常适用,如果用Flex/Flash,估计效果不会好。
图片编辑类型的Web Application,Flex/Flash就明显占优势了。
当然仅限于编辑功能那部分,浏览部分,另当别论。
这样看来,Flex/Flash在Web上发挥的空间还是不大的,只有一些特定的地方,有特别的优势。
b051
2007-08-11
robbin老大,我记得那年是2005年呀,不是2004。我的那部分历经了laszlo2.2.1到laszlo3.1.1。可以从roadmap看出。
如robbin的预言贴中倡导的一样,作为程序员,多学习一门课永远是好的。学完了,自然知道啥时候用ajax啥时候用ria。当然其实他们不矛盾,可以用air两句话画个webkit出来用ajax嘛。
如robbin的预言贴中倡导的一样,作为程序员,多学习一门课永远是好的。学完了,自然知道啥时候用ajax啥时候用ria。当然其实他们不矛盾,可以用air两句话画个webkit出来用ajax嘛。
koda
2007-08-11
小结:Robbin+lwz7512 已经基本准确地阐述了什么时候该用AJAX,什么时候该用Flex了。
neuhawk
2007-08-10
silverlight是否成功,要看是否实现wpf的功能
lordhong
2007-08-10
做了一个flex+j2ee的项目, 非常看好flex前景.
apollo和flex3都出来了, adobe的前景我很看好.
ms的silverlight是很明显冲着flex来的. PC上的应用我不看好, windows mobile上的可能会比较有意思, 可以看看这个silverlight在WM上的MLB demo: blogs.msdn.com/mikehall/archive/2007/05/03/medc-2007-sliverlight-on-windows-mobile.aspx
不过adobe也在做flex的mobile版本, 目前是flashlite和flashcast占主角, 但flex mobile应该很快就来了. WM上很有可能就不支持adobe的产品了, 直接推silverlight mobile了. =]
apollo和flex3都出来了, adobe的前景我很看好.
ms的silverlight是很明显冲着flex来的. PC上的应用我不看好, windows mobile上的可能会比较有意思, 可以看看这个silverlight在WM上的MLB demo: blogs.msdn.com/mikehall/archive/2007/05/03/medc-2007-sliverlight-on-windows-mobile.aspx
不过adobe也在做flex的mobile版本, 目前是flashlite和flashcast占主角, 但flex mobile应该很快就来了. WM上很有可能就不支持adobe的产品了, 直接推silverlight mobile了. =]
- 浏览: 1930994 次
- 性别:

- 来自: 上海

- 详细资料
搜索本博客
我的相册
iphone2.jpg
共 39 张
共 39 张
最近加入圈子
链接
最新评论
-
中国行业应用软件领域恶性 ...
比较同意,世界就这样
-- by smilerain -
发现JBoss Seam很棒呀!有 ...
JSF\Struts等这些框架主要是看用在做什么样的项目上.各有优缺点.因为他们 ...
-- by iamlibo -
中国行业应用软件领域恶性 ...
深有同感,心有戚戚焉,这确实是一个博傻的行业。Robbin一语中的,写得很有深度 ...
-- by slattn -
社区网站SNS化的思考 – ...
就算51.com和腾讯流量再大,我也不感兴趣豆瓣在心中的地位要比那些乱糟糟的社区 ...
-- by xifanlou -
发现JBoss Seam很棒呀!有 ...
也不说用过jsf有多深入,给我的感觉还是作的太复杂,有点因为技术而技术的感觉。这 ...
-- by nimrob






评论排行榜