AJAX与RIA技术之我见
程序员文章站
2022-03-08 21:21:52
...
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开发之首选技术。
上一篇： 从分布式系统的角度看REST