AJAX与RIA技术之我见

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开发之首选技术。

评论

8 楼 抛出异常的爱 2007-08-03  

用flash对dom进行控制是有点困难
但还有其它的问题，
比如每页flash的开发，维护成本高于 js才是关键。
还有网速的考虑。

7 楼 sp42 2007-08-03  

Javascript的再激活，除了在客户端上参与和(x)html的复兴外，亦正在驾临服务端的开发。参见一则消息：

引用

为了提升google的开发效率，Steve努力尝试说服公司采纳Rails（包括Ruyb）作为开发工具，但是google不予采纳(google不想再增加支持的语言的数量)。Steve决定把Rails移植到JavaScript上去。这意味着一个google有可能在未来开源一个新的项目Rhino on Rails。

限制语言的数量将使得开发人员对代码的贡献度更大，他们无需担心成为不熟悉的语法的牺牲。

每一个公司正式支持的语言都是有成本的：基础架构的支持，文档，培训，代码冗余还有其它因素。虽然编程语言的核心语法都是大同小异，但是剩下的各自独特的语法就难以辨认，尤其是没有明确标准的动态语言，例如Perl,Ptthon,Ruby。Google非常谨慎的保持使用语言的数量。这样就可以构建大量对所用语言非常熟悉的专家。goole目前只使用C++,Java,Python,javascript作为正式的产品开发语言。

详细：http://www.infoq.com/cn/news/2007/06/yegge-rhino-on-rails

6 楼 mistapostle 2007-08-02  

我要push信息到前端怎么办

5 楼 Jove 2007-08-02  

所以, 如果要做一个系统框架, 比如Netvibes这样的, 必须用HTML, 因为要整合各种widget. 而对于某个应用, 如果界面要求比较高,又不计成本,那可以用Flash/Flex

其实Flex/OpenLaszlo也不见得门槛有多低, 不见得熟悉JavaScript就能很快上手

4 楼 bluepower 2007-08-02  

weiqingfei 写道

为什么就不可以整个页面完全使用flash或者SilverLight呢？

完全可以，但似乎走向了一个极端，为何要抛弃 HTML 呢？

3 楼 bluepower 2007-08-02  

个人更喜欢开发 Ajax App，不过 YAHOO 的 flash 地图应用也不错哦～

2 楼 weiqingfei 2007-08-02  

为什么就不可以整个页面完全使用flash或者SilverLight呢？

1 楼 interpb 2007-08-02  

见过一些全flash的web 应用 叹为观止