Ajax 由 HTML、JavaScript™ 技术、DHTML 和 DOM 组成，这一杰出的方法可以将笨拙的 Web 界面转化成交互性的 Ajax 应用程序。Ajax这个东东不是一种新技术,而是Asynchronous JavaScript + XML等等技术的混合体。Ajax之父Jesse James Garrett于2005年提出这一新概念之后，这一沉睡了多年的技术，换上新衣，一下子变得容光焕发。
 |
| Ajax |
AJAX的应用使用支持以上技术的Web浏览器作为运行平台。这些浏览器目前包括：Mozilla、Firefox、Internet Explorer、Opera、Konqueror及Mac OS的Safari。但是Opera不支持XSL格式对象，也不支持XSLT。类似于DHTML或LAMP，AJAX不是指一种单一的技术，而是有机地利用了一系列相关的技术。
基于AJAX的“派生/合成”式（derivative/composite）的技术正在出现，如“AFLAX”。
AJAX(Asynchronous JavaScript and XML)被赢得广泛的认可，其原因是由于它缩短了Web应用程序和桌面应用程序之间的差距，并在其中充分结合可实现的技术和丰富的用户体验。
AJAX是多种技术的综合，它打破了面刷新的范式，使您的用户快速方便的与 Web 应用程序交互。AJAX是当前Web创新中的一个王冠。
基本简介编辑本段回目录
AJAX全称为“Asynchronous JavaScript and XML”（异步JavaScript和XML），是一种创建交互式网页应用的网页开发技术。它使用：
 |
| Ajax |
使用XHTML+CSS来表示信息；
使用JavaScript操作DOM（Document Object Model）进行动态显示及交互；
使用 XML 和 XSLT 进行数据交换及相关操作；
使用 XMLHttpRequest对象与Web服务器进行异步数据交换；
使用 JavaScript 将所有的东西绑定在一起。
传统的Web应用允许用户端填写表单(form)，当提交表单时就向Web服务器发送一个请求。服务器接收并处理传来的表单，然后送回一个新的网页。这个做法浪费了许多带宽，因为在前后两个页面中的大部分HTML代码往往是相同的。由于每次应用的交互都需要向服务器发送请求，应用的响应时间就依赖于服务器的响应时间。这导致了用户界面的响应比本地应用慢得多。
与此不同，AJAX应用可以仅向服务器发送并取回必需的数据，它使用SOAP或其它一些基于XML的页面服务接口，并在客户端采用JavaScript处理来自服务器的响应。因为在服务器和浏览器之间交换的数据大量减少（大约只有原来的5%），结果就能看到响应更快的应用。同时很多的处理工作可以在发出请求的客户端机器上完成，所以Web服务器的处理时间也减少了。
发展历史编辑本段回目录
 |
| Ajax |
部分观察家认为，Outlook Web Access是第一个应用了Ajax技术的成功的商业应用程序，并成为包括Oddpost的网络邮件产品在内的许多产品的领头羊。
2005年，许多事件使得Ajax被大众所接受。Google在它著名的交互应用程序中使用了异步通讯，如Google讨论组、Google地图、Google搜索建议、Gmail等。Ajax这个词由《Ajax: A New Approach to Web Applications》一文所创，该文的迅速流传提高了人们使用该项技术的意识。另外，对Mozilla/Gecko的
优点缺陷编辑本段回目录
 |
| Ajax |
Ajax不需要任何浏览器插件，但需要用户允许JavaScript在浏览器上执行。就像DHTML应用程序那样，Ajax应用程序必须在众多不同的浏览器和平台上经过严格的测试。随着Ajax的成熟，一些简化Ajax使用方法的程序库也相继问世。同样，也出现了另一种辅助程序设计的技术，为那些不支持JavaScript的用户提供替代功能。
对应用Ajax最主要的批评就是，它可能破坏浏览器后退按钮的正常行为。在动态更新页面的情况下，用户无法回到前一个页面状态，这是因为浏览器仅能记下历史记录中的静态页面。一个被完整读入的页面与一个已经被动态修改过的页面之间的差别非常微妙；用户通常都希望单击后退按钮，就能够取消他们的前一次操作，但是在Ajax应用程序中，却无法这样做。不过开发者已想出了种种办法来解决这个问题，当中大多数都是在用户单击后退按钮访问历史记录时，通过建立或使用一个隐藏的IFRAME来重现页面上的变更。（例如，当用户在 Google Maps中单击后退时，它在一个隐藏的IFRAME中进行搜索，然后将搜索结果反映到Ajax元素上，以便将应用程序状态恢复到当时的状态。）
技术开发编辑本段回目录
 |
| Ajax |
进行Ajax开发时，网络延迟——即用户发出请求到服务器发出响应之间的间隔——需要慎重考虑。不给予用户明确的回应，没有恰当的预读数据，或者对XMLHttpRequest的不恰当处理，都会使用户感到延迟，这是用户不欲看到的，也是他们无法理解的。通常的解决方案是，使用一个可视化的组件来告诉用户系统正在进行后台操作并且正在读取数据和内容。
一些手持设备（如手机、PDA等）现在还不能很好的支持Ajax；用JavaScript作的Ajax引擎，JavaScript的兼容性和DeBug都是让人头痛的事；Ajax的无刷新重载，由于页面的变化没有刷新重载那么明显，所以容易给用户带来困扰――用户不太清楚现在的数据是新的还是已经更新过的；现有的解决有：在相关位置提示、数据更新的区域设计得比较明显、数据更新后给用户提示等；对串流媒体的支持没有FLASH、Java Applet好。
核心性能编辑本段回目录
 |
| Ajax |
JavaScript编程的最大问题来自不同的浏览器对各种技术和标准的支持。XmlHttpRequest对象在不同浏览器中的有不同的创建方式。
使用场景编辑本段回目录
 |
| Ajax |
基于表单的交互
表单是很慢的，非常慢。尝试编辑位于del.icio.us上面的一个书签，点击编辑链接打开一个编辑书签的表单页面，然后编辑你的内容并点击提交按钮等待整个提交过程结束，最后返回上一页并向下滚动到你刚才编辑的书签那里查看内容是否已经正确更改。点击编辑链接马上开始更改标签内容，点击提交按钮开始异步传输标签编辑的内容并立即看到更改后的内容而无需重载整个页面。
深层树状导航
带有深层树状导航的应用程序通常是一个噩梦。在大多数情况中简单平直的拓扑结构以及搜索/标记可以很好的工作。但是如果一个应用程序真正使用深层树状导航，使用JavaScript来管理拓扑ui(userinterface用户接口)，则使用Ajax懒加载深层数据可以降低服务器的负载。举例来说，为了阅读一个只有一行的结果来加载整个一个新页面是非常耗时的。
实时用户对用户通讯
在一个允许用户创建实时讨论的信息公告系统中，迫使用户一次又一次的更新完页面看到答复是非常愚蠢的。回复应该是实时的，用户不应被迫总是去痴迷于刷新操作。即使是gmail这个已经对以前像hotmail/yahoomail的收件箱刷新，刷新收件箱标记的操作有所改进，也并没有充分的使用Ajax的功能来提示有新邮件到达。
投票、是否选择、等级评价
如果Ajax提交过程没有一个协调的UI提示是非常糟糕的，通过使用Ajax来提交一个调查或是否选择可以减少提交过程等待的痛苦。通过减少点击的等待时间，Ajax应用程序变得越来越有交互性，如果要用40秒来提交一个投票，除非非常在意的话大多数人会选择放弃。如果只花1秒呢，非常大比例的人会乐于参加投票的。
 |
| Ajax |
应用一个过滤、按日期排序、按日期和姓名排序、打开或关闭过滤器等等。任何一种高交换型操作应该交给JavaScript来处理而不是通过向服务器来提交一系列的请求。在查找或者操作大量数据的时候带来的视图上的改变最多不会超过30秒，Ajax真的使这些操作加速了。
普通录入时的提示/自动补齐
一些软件JavaScript是擅长于帮助用户完成键入相同的文字或可以预测的文字的工作的。在del.icio.us和Gmail中该功能是非常有益的，可以用来快速增加标记/email等。对于一个频繁使用的应用程序诸如网页邮件客户端或博客阅读器来说，用户有充足的时间来学习如何使用新的UI概念但是他们却无法接受一个非常缓慢的反应速度。这种应用为Ajax变的更加普及起到了一个完美的杠杆作用。随着用户使用频率的增加，更多的Ajax部件应该加强用户的使用体验。但是对于网页应用程序来说，把每件事甚至任何事都用JavaScript来实现也是没有意义的。Ajax只是针对一些特定的环境才能带来显著的帮助。在Ajax出现之前网页应用程序已经可以工作的很好了并且目前在网页开发中Ajax还存在着许多的缺陷和缺点。就算不从服务器端取得一个异步的信息数据流一个平直的html网页日志也可以工作的很好。对于文档或文档之间的跳转来说，老旧的纯HTML仍然是最好的选择。简单或很少使用的应用程序就算不用JavaScript同样可以很好的工作。
下面是一些不应该用到Ajax的地方：
简单的表单
就算表单是Ajax技术的最大受益人，一个简单内容的表单，或提交订货单，或一次性的很少用到的表单都不应该使用以Ajax驱动的表单提交机制。总的来说，如果一个表单不是很长用，或已经工作的很好，那么就算使用Ajax也没有什么帮助。
挑战危机编辑本段回目录
 |
| Ajax |
Ajax在本质上是一个浏览器端的技术，首先面临无可避免的第一个问题即是浏览器的兼容性问题。各家浏览器对于JavaScript/DOM/CSS的支持总有部分不太相同或是有Bug，甚至同一浏览器的各个版本间对于JavaScript/DOM/CSS的支持也有可能部分不一样。这导致程序员在写Ajax应用时花大部分的时间在调试浏览器的兼容性而非在应用程序本身。因此，目前大部分的Ajax链接库或开发框架大多以js链接库的形式存在，以定义更高阶的JavaScriptAPI、JavaScript对象（模板）、或者JavaScriptWidgets来解决此问题。如prototype.js。
Ajax技术之主要目的在于局部交换客户端及服务器间之数据。如同传统之主从架构，无可避免的会有部分的业务逻辑会实现在客户端，或部分在客户端部分在服务器。由于业务逻辑可能分散在客户端及服务器，且以不同之程序语言实现，这导致Ajax应用程序极难维护。如有使用者接口或业务逻辑之更动需求，再加上前一个JavaScript/DOM/CSS之兼容性问题，Ajax应用往往变成程序员的梦靥。
针对业务逻辑分散的问题，Ajax开发框架大致可分为两类：
将业务逻辑及表现层放在浏览器，数据层放在服务器：因为所有的程序以JavaScript执行在客户端，只有需要数据时才向服务器要求服务，此法又称为胖客户端（fatclient）架构。服务器在此架构下通常仅用于提供及储存数据。此法的好处在于程序员可以充分利用JavaScript搭配业务逻辑来做出特殊的使用者接口，以符合终端使用者的要求。但是问题也不少，主因在：
第一，JavaScript语言本身之能力可能不足以处理复杂的业务逻辑。
第二，JavaScript的执行效能一向不好。
第三，JavaScript存取服务器数据，仍需适当的服务器端程序之配合。
第四，浏览器兼容性的问题又出现。有些Ajax开发框架如DWR企图以自动生成JavaScript之方式来避免兼容的问题，并开立通道使得JavaScript可以直接叫用服务器端的Java程序来简化数据的存取。但是前述第一及第二两个问题仍然存在，程序员必须费相当的力达到要求。
将表现层、业务逻辑、及数据层放在服务器，浏览器仅有使用者接口引擎（UserInterfaceengine）；此法又称为瘦客户端（thinclient）架构，或中心服务器（server-centric）架构。浏览器的使用者接口引擎仅用于反映服务器的表现层以及传达使用者的输入回到服务器的表现层。由浏览器所触发之事件亦送回服务器处理，根据业务逻辑来更新表现层，然后反映回浏览器。因为所有应用程序完全在服务器执行，数据及表现层皆可直接存取，程序员只需使用服务器端相对较成熟之程序语言（如Java语言）即可，不需再学习JavaScript/DOM/CSS，在开发应用程序时相对容易。缺点在于使用者接口引擎以及表现层通常以标准组件的形式存在，如需要特殊组件（使用者接口）时，往往须待原框架之开发者提供，缓不济急。如开源码Ajax开发框架ZK目前支持XUL及XHTML组件，尚无XAML之支持。
Ajax是以异步的方式向服务器提交需求。对服务器而言，其与传统的提交窗体需求并无不同，而且由于是以异步之方式提交，如果同时有多个Ajax需求及窗体提交需求，将无法保证哪一个需求先获得服务器的响应。这会造成应用程序典型的多程序（process）或多线程（thread）的竞争（racing）问题。程序员因此必须自行处理或在JavaScript里面动手脚以避免这类竞争问题的发生（如Ajax需求未响应之前，先disable送出按钮），这又不必要的增加了程序员的负担。目前已知有自动处理此问题之开发框架似乎只有ZK。
AJAX的七宗罪来源: javaeye编辑本段回目录
引子
2005.2.18，Jesse James Garrett 的一篇A New Approach to Web Applications引出了AJAX这个web界的新名词。加上新宠儿在降生下来就和足球名队阿贾克斯、Google Suggest Google Maps这些大腕息息相关，不想出名都难啊。但似乎人们给与AJAX的期望有点太高了，甚至有人提出了用AJAX取代Java Applet和Flash。不知Flickr是不是也听到这种呼声才把自己的Flash UI转向了普通的Javascript。AJAX是个伟大的东西，它是在不创造新技术的前提下诞生的一个标准，凭这一点就能招来大批的狂热追随者，AJAX看起来更像是杨过和小龙女练得玉女素心剑一样，分开来没有什么破坏力，但是二者合一就威力无比。
罪之一：对搜索引擎的支持不好
这其实更像一个大大的讽刺，AJAX的鼻祖是Google，但却对Google自己支持最不好了，GMail主界面除过Top和Bottom外没有一个链接就是最形象的讽刺了。虽然Mail本身是个私人的应用系统，但这个无链接的设计界面恰恰给AJAX开了个坏头。Flash也有同样有这个毛病。没有链接的web就像森林中迷路的羔羊，这句看似广告语，其实是web设计的根本原则。
罪之二：编写复杂、容易出错
javascript本是是个轻量级的小东西，现在被强迫重用起来，负担可想而知。javascript对OOP的支持很少，这就限制了javascript代码的可重用可封装等等，从Google Mpa还是其他一些应用中能看到的都是无数的<script src="..."></script>这样的文件包含，这些除了让程序员头昏的更快点，一点好处都没有。更可怕的是在javascript中竟然没有一款顺手的Debug软件，很多写js的老手到今天还是用最原始的alert("")来调试，splinetech JavaScript HTML Debugger 算是一个看起来还像个样子的调试器吧，可惜不是免费的，几十大刀让我这种穷人只能望而生叹了。
罪之三：冗余代码更多了
和上面说的差不多，层层包含js文件是AJAX的通病，再加上以往的很多服务端代码现在放到了客户端，所以每次打开一个页面会包含很多的无用的js文件也一同下载下来。虽然宽带越来越普及，但是减少代码冗余还是每个web设计者的必修课。
罪之四：破坏了Web的原有标准
什么叫破坏web标准？这就是破坏了web标准。好好的A标签放着不用，偏要用span。这种例子很多，flickr中的标题单击后可以更改，这虽然（也包括我）是大家一致叫好觉得方便的设计，但同时这也是歧义了web元素本身的含义，物是人非这个词不知道用的合不合适？
罪之五：缺少一个没有标准之争、没有back和history的浏览器
哈哈，这句话语有点讽刺意义。现在的浏览器市场，不管是IE还是FireFox还是Opera等等。浏览器和浏览器之间的差异一直都是web设计者心中永远的痛，支持的css不一样，支持的客户端脚本不一样，有的竟然连客户端脚本的用法都有不同。这让程序员非常苦恼，最明显的就是调用xmlhttprequest了，req=(window.XMLHttpRequest)?new XMLHttpRequest():new ActiveXObject("Microsoft.XMLHTTP");这段创建xmlhttp对象的代码就是为了适应IE和非IE两天阵营的浏览器的经典例子。说是没有back和没有history的浏览器，这也是一个讽刺，主要是指在AJAX下点击链接是不Redirect页面，所以不存在后退和前进了，同样，没有后退和前进也就无存找浏览历史纪录了。back和history存在的根本就是url的改变，在AJAX下人们发现不改url也同样能达到内容改变这个酷酷的特点，何乐而不为呢？look http://www.dux2005.org/和http://www.zagodesign.com/，我承认这两个站确实做得非常棒，但除了酷酷的感觉外，毫无用处。
罪之六：XML只是用来打幌子
xml从诞生那天起就被一致看好，大有非xml不娶之势，我想Jesse James Garrett也是为了趋于流行才把xml强行加入ajax的吧。xml有一个致命的缺点，那就是加载的资源耗费，这好像是所有平台下xml的通病。google map虽然是Jesse James Garrett推荐的AJAX的品牌代言人，但是gmap并没有用xml，而是用了原生的javascript数组，我自己在用AJAX从服务端传回数据时也从来不用XML，因为它让我更繁琐让系统更慢。服务端首先要调用xml对要传输的数据进行封装，客户端得到数据后再调用xml进行解析，简直是画蛇添足。AJAX的一个重要特点是要身法轻盈，数据的传输尽量单一和简陋，如果确实需要传输大量复杂的数据，也应该通过多次调用传回。
罪之七：世界这么大却找不到自己的家
AJAX适用于什么？能干什么？能带来什么？在网站上用AJAX那是笑话，除非像Google Map和Flickr这样的专业领域的网站外，普通网站根本没必要用这个技术；在庞大的企业应用市场估计还能有AJAX的一点容身之地，不过在MS、SUN不会看着AJAX这个野孩子来在他们的地盘上撒泼的，如果大家都用AJAX，那java给谁卖？.net给谁卖？所以AJAX在企业应用也不是长久之地。所以，AJAX现在找不到自己合适的位置是个很大的尴尬。疑病乱投医，最近把AJAX的矛头指向Flash和Applet就是一个例子。
当然，我也不是要把AJAX扁的一无是处，我本人就非常喜欢这门技术，它能让web设计者的眼球更加宽广，让一些大胆的设计成为现实，但是我也会很冷静的小心翼翼的利用这个利器，利器虽好，一不留神刺伤的是自己。
PS：这篇文章是昨晚写的，今早却神奇般的从网上看见了一篇文章Ajax: 99% Bad，文章是针对2000年那片著名的Flash: 99% Bad 写的，其中的观点和我所说的七宗罪中的几宗相似。
驳“AJAX的七宗罪”
（原文地址：http://forum.javaeye.com/viewtopic.php?t=13844，作者：dlee）
我不带任何主观色彩来评一下这个所谓的“AJAX的七宗罪”。
1、连带着Flash和Ajax一块骂了。
引用:没有链接的web就像森林中迷路的羔羊，这句看似广告语，其实是web设计的根本原则。
这句“原则”至少我并不知道，因此看起来不过就是一句广告语而已。我的原则是Web应用首先需要对于最终用户友好，然后才需要考虑对于搜索引擎友好。你使用HTML FORM提交的数据也是没有链接的，这些数据可以被搜索引擎搜索到吗？换句话说，可以添加在链接URL中的只有通过GET方法发送的请求。搜索引擎难道连使用POST方法提交的FORM数据都能搜索到吗？如果搜索引擎能搜索到这些数据，搜索引擎搜索到同样通过HTTP协议以明文形式发送的XML数据难道是很困难的事情吗？
必须要考虑对于搜索引擎友好的应用也是有限的。你以为Google真的没有办法解决这些问题吗？太小看Google了吧？
2、这个作者显然很少做JavaScirpt开发，以至于说出这样没有调查的话来：
引用:更可怕的是在javascript中竟然没有一款顺手的Debug软件，很多写js的老手到今天还是用最原始的alert("")来调试，splinetech JavaScript HTML Debugger算是一个看起来还像个样子的调试器吧，可惜不是免费的，几十大刀让我这种穷人只能望而生叹了。
M$ Visual InterDev、Office 2003中带的Script Debugger都是非常好用的调试工具。如果不愿意花钱买这些工具，还可以使用Mozilla开发的Venkman，调试功能已经非常完善了。说JS没有很好的IDE是实情，说JS没有很好的调试工具简直是天大的笑话。
3、引用:和上面说的差不多，层层包含js文件是AJAX的通病，再加上以往的很多服务端代码现在放到了客户端，所以每次打开一个页面会包含很多的无用的js文件也一同下载下来。虽然宽带越来越普及，但是减少代码冗余还是每个web设计者的必修课。
完全是没有调查的胡说，如果通过不同的文件对于JS代码进行了认真的组织，将JS函数分到很多小文件中，一个页面仅仅只需要加载它自己使用到的JS文件，何来冗余代码之说？
4、引用:什么叫破坏web标准？点击查看全部，这就是破坏了web标准。好好的A标签放着不用，偏要用span。这种例子很多，flickr中的标题单击后可以更改，这虽然（也包括我）是大家一致叫好觉得方便的设计，但同时这也是歧义了web元素本身的含义，物是人非这个词不知道用的合不合适？
这仅仅是一个具体应用中的用法，居然也归到了Ajax头上，真是欲加之罪，何患无词。这里如果简单地将span换成a难道不是很容易的事情吗？如果使用a就不能使用onclick了吗？按照作者的想法，似乎所有的a都应该只能是简单链接，不能加上onclick，加上onclick就变成了Ajax，就触犯了天条，破坏了Web标准。况且给span加上一个onclick居然就上纲上线到破坏Web标准的层次，我研究Web标准这么多年，也没有看出究竟破坏了哪一款哪一条的Web标准。Web标准中什么地方规定只允许使用a，不允许使用span来实现了？况且在最新的XHTML1.2标准中，a已经变成了一个不推荐使用的标记。什么是Web标准，什么是破坏Web标准？回去翻翻书吧。
5、引用:浏览器和浏览器之间的差异一直都是web设计者心中永远的痛，支持的css不一样，支持的客户端脚本不一样，有的竟然连客户端脚本的用法都有不同。这让程序员非常苦恼，最明显的就是调用xmlhttprequest了，req=(window.XMLHttpRequest)?new XMLHttpRequest():new ActiveXObject("Microsoft.XMLHTTP");这段创建xmlhttp对象的代码就是为了适应IE和非IE两天阵营的浏览器的经典例子。说是没有back和没有history的浏览器，这也是一个讽刺，主要是指在AJAX下点击链接是不Redirect页面，所以不存在后退和前进了，同样，没有后退和前进也就无存找浏览历史纪录了。back和history存在的根本就是url的改变，在AJAX下人们发现不改url也同样能达到内容改变这个酷酷的特点，何乐而不为呢？
我提到过多次《网站重构》，这本书要解决什么问题？femto开始读了吗？曾经产生过读这本书的欲望吗？
创建XMLHTTP对象的不同语法只是一个非常小的问题，这是在XMLHTTP没有被完全标准化之前的暂时问题。现在基于Web标准做开发，必须要写针对不同浏览器的代码片断的场合已经非常少了，封装这些差异的JS库网上也已经有很多了。
无法利用back/history的问题在Google Maps中是使用IFrame来解决的，这个问题我在BEA User Group的演讲中已经说过了。
6、引用:xml有一个致命的缺点，那就是加载的资源耗费，这好像是所有平台下xml的通病。google map虽然是Jesse James Garrett推荐的AJAX的品牌代言人，但是gmap并没有用xml，而是用了原生的javascript数组，我自己在用AJAX从服务端传回数据时也从来不用XML，因为它让我更繁琐让系统更慢。服务端首先要调用xml对要传输的数据进行封装，客户端得到数据后再调用xml进行解析，简直是画蛇添足。
致命吗？我做了这么多浏览器端的XML开发，为什么至今没有感受到？Google Maps服务器端传给客户端的数据就是不折不扣的XML，其它的开发人员还可以对这个XML进行定制加入自己的数据。Google Maps还在客户端几个功能上使用了XSLT。说Google Maps没有使用XML，要不要我把我亲自整理过的Google Maps客户端的代码发给你你才能闭嘴？
7、引用:AJAX适用于什么？能干什么？能带来什么？在网站上用AJAX那是笑话，除非像Google Map和Flickr这样的专业领域的网站外，普通网站根本没必要用这个技术；在庞大的企业应用市场估计还能有AJAX的一点容身之地，不过在MS、SUN不会看着AJAX这个野孩子来在他们的地盘上撒泼的，如果大家都用AJAX，那java给谁卖？.net给谁卖？所以AJAX在企业应用也不是长久之地。所以，AJAX现在找不到自己合适的位置是个很大的尴尬。疑病乱投医，最近把AJAX的矛头指向Flash和Applet就是一个例子。
又是一番奇谈怪论。说大公司不会使用Ajax完全是主观臆测。事实上，大量使用客户端JS的大公司包括以下这些：
Macromedia：在Dreamweaver产品中包括了大量的JS代码。
Oracle：很多产品都使用了JS，目前对于Ajax很感兴趣。这个消息是我在深圳Oracle做开发的一个朋友亲口告诉我的。
SAP：早在很多年以前，SAP就在其产品中大量使用了JS+XMLHTTP的技术，仅仅是SAP没有炒做这个概念而已。说Ajax不适合企业应用，SAP是靠做什么吃饭的？
Google：我已经不需要再说什么了。
