（本文转载自“Java视线”，作者Michael Chen，原文地址：http://forum.javaeye.com/viewtopic.php?t=13844）
[1. 为什么争吵]
我本不是一个爱凑热闹的人，看到这些争吵与我所做的工作相关，还是忍不住说几句话。我试图以一种平和的语气来描述问题，而不是引起新的争吵。我所做的工作大家都能看见，所以说话应该还有点分量。从一开始提出amowa到现在的buffalo，我所提倡的都是"面向异步消息的web应用(amowa)"，buffalo只是一种"web remoting library", 从未提出说在整个站点的范围内应用amowa或者buffalo, 最多的说法也就是buffalo能够非常容易的给现有应用添加Ajax特性，同时我从没有强求任何应用使用buffalo, 许多时候我都是跟jsonrpc, dwr同等而说的：如果不使用jsonrpc, 可以使用buffallo; 如果不要求对远程调用的返回值进行处理，可以使用dwr. 我的说法是很慎重的，同时也代表了我对Ajax的观点——从来没有任何一种依赖特定技术的东西能够长久。这是一个客观而严肃的认识——这个认识可以解释很多人为什么恼火——有些人是因为不了解而攻击，有些人是因为太了解而攻击。从人性的本质来说，除非自省，否则很难快速接受尤其是跟自己利益相背的观点或者立场。
我从未点名提出使用xmlhttp或者xml, javascript. 上述的任何一种技术，例如ajax所包含的，javascript, xml我从未强制要求这样。Amowa提供一种概念，代表了一种界定制作包含消息特性的web应用的新型思路。这种思路从根本上说，将传统网站或者内容相关的应用与交互型或称消息型应用区分开来。Ajax之所以概念成功，是因为顺应了时代，而Amowa没能得到大面积接受，是因为超前了...
[2. 不要强求Ajax能够胜任所有需求——不去胜任又如何！]
谈Ajax, 要放在一定的场景中，否则一定会陷入迷惑，而且在企业应用方面经验越丰富的人越容易迷惑。如同那位网友的说法，它所说的Ajax七宗罪，其实在传统web开发（网站或者内容系统的应用），这七宗罪说得都对，一点都不错，只是炮火轰错了地方。Ajax从来都不妄图统一web开发所有方面，对于传统的方面，Ajax表现的非常脆弱，比如WebStandards, 比如搜索引擎友好。对于整站都采用Ajax的网站，除非是一个内部应用系统，如果放在www上，它的生命力将会非常差，非常差。Google不能正确的检索它——因为大部分内容都是运行时生成的；它不是一个兼容WebStandards的网站，许多动态样式都是runtime时刻通过javascript产生——但是，so what? 谁规定Ajax一定适应所有方面？谁指派Ajax解决web应用中所有问题的义务？
那么，Ajax适合哪些应用？从外观看来，适合那些对URL不敏感的web应用。如果一个应用对url的关心程度大于对交互特性关心程度，那么就不要妄想整个应用采用Ajax, 否则可以完全采用Ajax. 例如，一个论坛系统，如果用户不能通过url定位到一个确定的页面，那么这个应用是失败的；但是如果是一个email系统，传统的email每次点击都需要download整个page, 相比gmail的交互性与操作性，哪个成功哪个失败显而易见了。
www.backbase.com实际上提供了一个反例：将所有内容都放到了同一个page内，通过Ajax读取不同页面内容然后显示。用户无法通过permanent link来快速定位某一个页面，搜索引擎更是难以搜索。
[3. 如何应用Ajax?]
在应用Ajax的时候，针对传统的web开发，有两个问题我们一定要问问自己：
[这个应用，搜索引擎需要搜索所有东西吗？]
答案往往是否定的。哪怕是像论坛这种内容特征非常明显的应用，Ajax都有其用武之地。例如，在发贴的时候，是希望一个新的页面开启告诉你发贴成功还是在原页面有一个人性化的loading标志提示你操作成功？这些例子数不胜数：很多时候，我们并不需要搜索引擎搜索所有的东西。OK, 那么，对于搜索引擎需要的东西，让它遵循普通页面规范；而不需要搜索的，就采用Ajax来增强用户体验。大多数的blog站点都有针对时间的blog索引，例如指向某年某月某日的blog归档，绝大多数blog应用都只能在点击类似于archive/2005/05/01或者archive.xsp?year=2005&month=06&day=01之类的链接之后，转到另外一个页面。然而forgetfoo.com就提供了一个新的方式：点击Calendar的某一个日期之后，当前页面会出现一个浮动层，然后出现对应日期存在的blog列表——不需要切换页面。这个应用能被搜索引擎搜索吗？可以。他是Ajax应用吗？也算是。传统web应用与Ajax特性的结合，并不是一种非此即彼你死我活的，而是可以非常亲密的合作。
[WS需要所有的页面都遵循吗？]
答案可能还是否定。web应用发展到现在，基本上没有纯粹的网页应用了。哪怕是最简单的一个网站，往往存在一个对应的后台管理系统。对于前台的网页，该怎么样怎么样去；然而对于后台的管理，需要遵循web standards吗？需要被搜索引擎搜索吗？不需要。用户最关心的就是如何快速的响应自己对应的操作。那么，Ajax还是有用武之地了。Ajax提供了在不刷新页面前提下，将数据流量减到最小，并且能够以更友好的方式提示用户等待。
[4. 如何应用Ajax?]
j2ee blueprints的Ajax Demo提供了以最原始方式进行Ajax特性开发——直接使用xmlhttp request. 已经相当多成熟的中间库可供使用了，jsonrpc, dwr, buffalo, prototype...这里不再赘述。
需要提及的是——无论愿意不愿意，无论有没有人要造一个新的概念，Ajax相关技术的学习门槛相当低。以j2ee社群参与者的聪明才智，学习并掌握Ajax, 都不是难事。web开发的特点在于知识相对分散，但每个方向都有足够的学习前景——这正好符合了大部分如我j2ee开源学习者的思维模式。只要你愿意，你可以在Ajax的道路上走的足够远。当你半个月、一个月后看这篇文章——或者现在就可能感受到，我们其实处在同一起跑线上。我在开发buffalo过程中，心中时常惴惴不安: buffalo只是一个简单的库，读过代码的朋友应该都能看出来，代码量并不大，也不复杂，比起spring, hibernate或者其他的库，既没有优秀的设计，也没有复杂耐人品读的结构，但是得到了许多朋友的肯定和使用，这让我非常高兴，得到了更多的动力。
然而，Ajax目前并不成熟——许多公司(backbase)、个人(如我)都提供了不同的实现，这些实现或简单，或复杂，但都不兼容。开发者需要以非常清醒的头脑来做出选择。无论做出什么选择，我的经验是，javascript编码能力还是需要的，html Dom的了解还是需要的，至少在目前。Ajax首先是用户的特性，而不是工程的特性。想从工程的角度进行ajax开发在目前不太现实——我在51js的朋友宝玉，给某厂商做的Web messenger, js代码写了1w行。js存在天生的弱点，这些弱点使得跨厂商的积累和重用比较困难。在目前状况看来，ajax的相关开发还需要走一段手工的路。
从应用的角度，我们缺乏的不是Ajax相关的技术，而是缺乏足够应用Ajax的眼界和创意。有些朋友给我发信来，表示了buffalo给他们带来的灵感，说要对原有应用进行重构；还有一些处在学习中，但也愿意尝试。我的建议是：尽可能多的想到页面无刷新，尽可能多的想到Ajax, 尽可能多的站在用户的交互，尽可能多的为用户考虑。我想，Ajax可能是j2ee社群以来，头一个不是以优良设计，而是以用户体验为核心的新的名词。
[5. 眼界高一些]
我很庆信自己做过很多种类的web应用，这样我能够从这些乱糟糟的争论中解脱出来。Ajax只代表了xml+javascript, 而Amowa代表了面向异步消息的web应用。当某一天，web开发不再以html+javascript为载体，而以flash+actionscript, 或者xaml+javascript，请不要奇怪，相信我，异步响应是改善用户体验的终极之道。
Michael Chen