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开发之首选技术。
评论
咖啡舞者 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
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技术可正合许多用户的胃口哟……
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 莫怪!)
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要好多了(东拼西凑)..
iiley 2007-08-18
文字为主的网站用Flex/Flash就是脑子进水了:)
图片为主的呢,各有优势,都可以。
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嘛。
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了. =]
lwz7512 2007-08-10
头一次看见老大robbin对RIA发表看法,机会难得啊,我也来说两句:

1。首先讲讲楼主谈到项目的时代背景
在2004年是众多flash设计和开发人员以flashmx/flashmx2004为工具的年份,当时的flashplayer版本为7,flash虽然火爆,但是停留在设计广告、片头、宣传片、演示、个人网站、个性化的产品网站、小游戏等等层面上。本身就flashmx/as2/flashplayer7这样的工具,应该说它还只是“设计人员”的吃饭家伙,如果让它来承担“比较高的实时反馈和交互式要求”这样的任务,本身就是“不可能的任务”或者说是风险很大很大的,虽然说也能实现实时性和丰富的交互体验,但是很可能不能满足企业级软件的要求,失败也就变的正常了。RIA的概念在2004年才刚刚提出来,flex1.0才刚刚推出,还稚嫩的很,用flashmx来做企业应用那简直就是吃螃蟹。

2。接着在讲讲Flash RIA的开发成本
“Flash有一个巨大的和网页交互的成本”这在2004年是成立的,因为flash的外部接口(ExternalInterface)是在2005年flash8发布时才增加的功能,如果没有这个接口,as<--->js之间的通讯是不可能的。如果有大量交互的话,那真应该反思一下设计,这种方案是否有问题,当然现在这种需求技术上是没有任何问题的,比如google finance ,yahoo finance 。flash/flex RIA的开发成本目前来说,一点都不高,应该是低于j2ee的,高于ROR的,技术层面没有瓶颈问题,人力成本也不是很高,一个flash/flex程序员的工资比j2ee程序员的工资高不了哪去。

3。然后讲讲flashIDE与开发效率
flashmx/flashmx2004/flash CS3严格来讲都属于设计工具,如果用它来做产品的原型设计,网站原型设计,界面设计都是很合适的,我就是非常喜欢用它们来画界面,现在的flashcs3绘图功能又增强了许多,与photoshop/flex3的完美协同工作(官方叫工作流)也是前所未有的,不能用开发工具的要求来要求他们,更不能用“一个很蹩脚的工具”来形容它,企业级RIA的开发应该由flexbulider来承担,它才是正儿八经的IDE,用过它的人都知道,它是基于eclipse的,除了收费这点让我们不爽,其他还是可以的,但是它离专业的java开发工具还是有差距的,比如代码重构、自动生成、代码查找、性能评估(profiler)、增量编译等方面,毕竟这个工具是2005年adobe接收(以前是macromedia的产品)过来重新改造的产品,要给人家时间吗。

4。之后讲讲html应用_PK_flash应用
不管是走公网的应用还是企业内部应用,如果是要表现文本信息或者再加个图片什么的,普通html页面就可以做的很好,如果硬要用flash来做自己不擅长的东西,反过来说flash不好,那可真是冤枉了。在flash9/as3以前的时代(2006/06以前),flash内容的基础构成是movieclip以及符号,完全是针对动画和多媒体来设计的整个架构(包括flashplayer),而到了swf9/as3/flashplayer9的时代(adobe财大气粗的结果)整个架构才完全改变,整个平台发生根本转变,flashplayer的虚拟机AVM2脱胎换骨,更快,flash的单元构成也不再是电影片段,而是显示对象(displayobject/sprite)这样更具有扩展性的东西,然而由于flashplayer的特殊性,其渲染文本的性能还是比不上浏览器。所以,做web应用就必须定位好它的内容、受众、发布渠道,能用html做好的,就别让flash来做,html做不好的或者做不了的让flash来做。为什么互联网上的flash应用比较少,是因为多种因素造成的,比如带宽限制、文字信息主体性、用户习惯等等,而在企业内部的应用,一些以数据、图形为主的应用flash绝对可以胜任,而且能大显身手。

5。最后杂七杂八讲点
以flash/flex为代表的RIA技术正在不断进步,以前根本不敢涉足的门户(portal)、报表、商业智能(BI)等领域都会有所成就,比如说flex的module为widget/portlet做好了技术准备,而flex3的高级表格也为报表功能提供了基础。在企业web应用方面,flash/flex绝对可以大显身手,让我们有更多的选择和惊喜。silverlight(formerlly WPF/E)虽然正式推出时间不长,但是其定位是明确的,移动设备以及高清视频、3D图形等方面,它的市场策略应该是针对flash,但是要比flash还要高端一些。这里再拍一下dlee的马屁,李老师说话还是很中立的,而且每次说话都论据充足、翔实,对flash的态度比较积极。

一不小心,说了这么多,不好意思。
ltian 2007-08-09
我认为“你开发的web应用最终还是一个基于文本形式的”这句话不全面,对于企业应用而言,基于图形化的应用才有作为,而基于文本的形式的WEB应用则适合于网站\论坛等类似系统.
发表评论

提醒: 该博客已发表在公共论坛,博客所有留言会成为论坛回贴,留言请注意遵守论坛发贴规则

您还没有登录,请登录后发表评论

robbin
搜索本博客
我的相册
213cbb75-7dae-37b2-b9ce-9e7b49f784d3-thumb
游乌镇
共 33 张
其他分类
存档
最新评论