1.3.3 富浏览器端开发（RWC）与AJAX

1.3.3  富浏览器端开发（RWC）与AJAX

事情很快发生了变化——起码，看起来时代已经变了。因为从2005年开始，几乎整个B/S开发界都在热情地追捧一个名词：AJAX。

AJAX中的“J”就是指JavaScript，它明确地指出这是一种基于JavaScript语言实现的技术框架。但事实上它很简单——如果你发现它的真相不过是“使用一个对象的方法而已”，那么你可能会不屑一顾。因为如果在C++、Java或Delphi中，有人提出一个名词/概念（例如Biby），说“这是如何使用一个对象的技术”，那绝不可能得到如AJAX般的待遇。

然而，就是这种“教你如何用一个对象”的技术在2005至2006年之间突然风行全球。Google基于AJAX构建了Gmail；微软基于AJAX提出了Atlas；Yahoo发布了YUI（Yahoo! User Interface）；IBM则基于Eclipse中的WTP（Web Tools Project）发布了ATF（AJAX Toolkit Framework）……一夜之间，原本在技术上对立或者竞争的公司都不约而同地站到了一起：它们不得不面对这种新的技术带来的巨大的网络机会。

事实上在AJAX的早期就有人注意到这种技术的本质不过是同步执行。而“同步执行”其实在AJAX出现之前就已经应用得很广泛：在Internet Explorer等浏览器上采用“内嵌帧（IFrame）”载入并执行代码；在Netscape等不支持IFrame技术的浏览器中采用“层（Layer）”来载入并执行代码。这其中就有JSRS（JavaScript Remote Scripting），它的第一个版本发布于2000年8月。

但是以类似于用JSRS的技术来实现的HTTP-RPC方案存在两个问题：

IFRAME/LAYER标签在浏览器中没有得到广泛的支持，也不为W3C标准所认可；
HTTP-RPC没有提出数据层的定义和传输层的确切实施方案，而是采用B/S两端应用自行约定协议。

然而这仍然只是表面现象。JSRS一类的技术方案存在先天的不足：它仅仅是技术方案。JSRS并不是应用框架，也没有任何商业化公司去推动这种技术。而AJAX一开始就是具有成熟商业应用模式的框架，而且许多公司快速地响应了这种技术并基于它创建了各自的“同步执行”的解决方案和编程模型。因此真正使AJAX浮上水面的并不是“一个XMLHttpRequest对象的使用方法”，也并不因为它是“一种同步和异步载入远程代码与数据的技术”，而是框架和商业标准所带来的推动力量。

这时人们似乎已经忘却了RWC。而W3C却回到了这个技术名词上，并在三个主要方面对RWC展开了标准化的工作：

 复合文档格式（Compound Document Formats，CDF）；
 Web标准应用程序接口（Web APIs）；
 Web标准应用程序格式（Web Application Formats）。

这其中，CDF是对AJAX中的“X”（即XML）提出标准；而Web APIs则试图对“J”（即JavaScript）提出标准。所以事实上，无论业界如何渲染AJAX或者其他的技术模型或框架，Web上的技术发展方向，仍然会落足到“算法+结构”这样的模式上来。这种模式在浏览器上的表现，后者是由XML/XHTML标准化来实现的，而前者就是由JavaScript语言来驱动的。

微软当然不会错过这样的机会。微软开始意识到Flash已经成为“基于浏览器的操作平台”这一发展方向上不可忽视的障碍，因此一方面发展Altas项目，为.NET Framework+ASP.NET+VS.NET这个解决方案解决RWC开发中的现实问题，一方面启动被称为“Flash杀手”的Silverlight项目对抗Adobe在企业级、门户级富客户端开发中推广RIA思想。
现在，编程语言体系也开始发生根本性的动摇。Adobe购得Macromedia之后，把基于JavaScript规范的ActionScript回馈给开源界，与Mozilla开始联手打造JavaScript 2；SUN在Java 6的JSR-223中直接嵌入了来自Mozilla的Rhino JavaScript引擎，随后Java自己也开源了。在另一边，微软借助.NET虚拟执行环境在动态执行上天生的优势，全力推动DLR（Dynamic Language Runtime），其中包括了Ruby、Python、JavaScript、VB等多种具有动态的、函数式特性的语言实现，这使得.NET Framework一路冲进了动态语言开发领域的角斗场。