AJAX 的七宗罪

AJAX的七宗罪 http://duduwolf.winzheng.com/post/115.asp
中国的互联网现状究竟相当于美国的哪一年？ http://home.wangjianshuo.com/cn/20050530_aecaeeccccccaeccaeie.htm
难道我们还是起点太高？ http://ppip.weblogs.us/archives/38

Web 应用首先需要对于最终用户友好，然后才需要考虑对于搜索引擎友好。你使用 HTML FORM 提交的数据也是没有链接的，这些数据可以被搜索引擎搜索到吗？换句话说，可以添加在链接 URL 中的只有通过 GET 方法发送的请求。搜索引擎难道连使用 POST 方法提交的 FORM 数据都能搜索到吗？如果搜索引擎能搜索到这些数据，搜索引擎搜索到同样通过 HTTP 协议以明文形式发送的 XML 数据难道是很困难的事情吗？



M$ Visual InterDev、Office 2003 中带的 Script Debugger 都是非常好用的调试工具。如果不愿意花钱买这些工具，还可以使用 Mozilla 开发的 Venkman，调试功能已经非常完善了。

3、

如果通过不同的文件对于 JS 代码进行了认真的组织，将 JS 函数分到很多小文件中，一个页面仅仅只需要加载它自己使用到的 JS 文件，何来冗余代码之说？

4、

这里如果简单地将 span 换成 a 难道不是很容易的事情吗？如果使用 a 就不能使用 onclick 了吗？按照作者的想法，似乎所有的 a 都应该只能是简单链接，不能加上 onclick，加上 onclick 就变成了 Ajax，就触犯了天条，破坏了 Web 标准。况且给 span 加上一个 onclick 居然就上纲上线到破坏 Web 标准的层次，我研究 Web 标准这么多年，也没有看出究竟破坏了哪一款哪一条的 Web 标准。Web 标准中什么地方规定只允许使用 a，不允许使用 span 来实现了？况且在最新的 XHTML 1.2 标准中，a 已经变成了一个不推荐使用的标记。

5、

创建 XMLHTTP 对象的不同语法只是一个非常小的问题，这是在 XMLHTTP 没有被完全标准化之前的暂时问题。现在基于 Web 标准做开发，必须要写针对不同浏览器的代码片断的场合已经非常少了，并且封装这些差异的 JS 库网上也已经有很多了。

6

Google Maps 服务器端传给客户端的数据就是不折不扣的 XML，其它的开发人员还可以对这个 XML 进行定制加入自己的数据。Google Maps 还在客户端几个功能上使用了 XSLT。

7、

说大公司不会使用 Ajax 完全是主观臆测。事实上，大量使用客户端 JS 的大公司包括以下这些：
Macromedia：在 Dreamweaver 产品中包括了大量的 JS 代码。
Oracle：很多产品都使用了 JS，目前对于 Ajax 很感兴趣。这个消息是我在深圳 Oracle 做开发的一个朋友亲口告诉我的。
SAP：早在很多年以前，SAP 就在其产品中大量使用了 JS+XMLHTTP 的技术，仅仅是 SAP 没有炒做这个概念而已。说 Ajax 不适合企业应用，SAP 是靠做什么吃饭的？
Google：我已经不需要再说什么了。

1.
现在web站点的大量新增用户从何而来，还不是从搜索引擎来？你对
搜索引擎不友好？嘿嘿，去问问stakeholder答应不答应。



说真的你这段话逻辑挺混乱的。现在Get的方式是搜索引擎的巨大一块阿,你从搜索引擎搜到的大量信息，
有多少是以get方式的连接表达的，就说javaeye论坛自己这些文章把，
还不都是viewtopic.php?...么。Form提交不能搜索到，
好像不能推论Get方式也无所谓把。



?
有限的？所有的web网站，哪一个不希望尽可能多的被google搜索到，
哪一个不希望自己在google中的rank高，哪一个不希望google可以
检索自己站点的文件尽量的多。有限？那里有限了？

不要拿假如出来说话。
国际大专辩论会相信你也看过的吧，辩论都要基于事实
和真理，不要用假如出来说话。

2.
非常好用？你跟idea的调试比比，或者不济也跟
eclipse的调试比比。说真的，你总是说可用性概念，
我一开始还非常相信的，可是现在不得不怀疑，到底你对可用性
的理解和界定是怎样的，这么难用的东西居然都叫"非常好用"?
另外，罪之二为编写复杂、容易出错。你把原作者的其中一句话拿出来
批判，能说明什么东西呢？

7.


大公司还用c咧,那么你们公司用c作程序么?每种技术都有其适用范围阿,
ajax不是银弹，最多只能作为主要程序的有益补充
另外再看看原作者的话吧

原作者已经明确区分了网站应用和企业应用市场的区别,
回头看看你的反驳,
原作者不是已经区分了网站应用和企业应用市场的区别了么，他强调指出网站应用并不适合用ajax，而企业应用市场兴许还有一席之地。
不明白你在攻击什么。
（不过原作者说“不过在MS、SUN不会看着AJAX这个野孩子来在他们的地盘上撒泼的"
却是错误的，ajax只是有益补充，不会对java或者.net的整体有什么动摇的。）

记得以前dlee写过。
评价AJAX 不能只是评价javascript xmlhttp.

太片面了。
虽然我也不清楚AJAX包括哪些范畴，但这几年B/s开发经验，让我不自觉的觉得这是个趋势。

希望dlee于大家在这个板块把AJAX剖析清楚

[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

关于Ajax的应用，我觉得也是有一个应用范围的，我想本来也没有人把Ajax当作web开发的救世主，Ajax的出现也是为了解决特定问题而出现的，那就是交互比较频繁的web应用，当然flash等等也是很不错的解决方案，但是基于Javascript的方案，应该说是升级成本最小的一种解决方案。

Ajax应该说是一个框架，仅仅理解为Javascript+xmlhttp似乎简单了一些，xmlhttp仅仅是无刷新体验的技术解决，Ajax还包括对象的绑定，以及一系列的可复用组件。

:idea: 
amowa到现在的buffalo的作者。:-)

关于amowa
http://michael.nona.name/archives/78

“而Amowa代表了面向异步消息的web应用”

这个“异步消息”是什么意思呢？只是说有延迟效应，如在线聊天，游戏。其实用户还是期望能够在较短的时间内得到回应？

关于“异步内容”，我觉得，RSS/Email等协议，将是真正的“异步”。
(1) 上午通过Email 发出一个贴子，or blog。
(2) 下午通过RSS阅读器，察看反馈。

to mechiland：
根据我对于各种 Web 标准的了解，其实 Ajax 与 Web 标准是完全不矛盾的。因为 JavaScript 更确切地称为 ECMAScript 本身就是 Web 标准的一部分。基于 ECMAScript 和 DOM，完全有可能只开发一套符合标准的代码运行在所有最新版本的浏览器上。《网站重构》中已经做了令人信服的讲解。虽然现在还需要一些 workaround（例如封装各种浏览器差异的组件库，Sarissa、etc.），但是数量已经非常少了（相对于我在 01 年必须为 IE4/Netscape4 分别开发两套代码的时代），我认为这并不是很严重的问题。
多使用了一些 JavaScript 就变成了不符合 Web 标准，这完全是不学无术者的 FUD。与大家对于这篇文章作者的宽容不同，我对于他对自己不了解的事物大放厥词的态度是非常反感的。如果不是有人在这里提出来，本来我根本没有什么讨论的兴趣。

amowa 主要还是侧重于 remote message，这方面解决得很好。我在 Oracle 的朋友问我 buffalo 是否足够 rich，我说 buffalo 其实解决的并不是这个问题。我想 remote message 和 rich 两部分相结合才是 Ajax。对于 Ajax 的判断，我很同意清风的意见，Ajax 确实是有着比 JS+XMLHTTP 更加丰富的内涵。

搜索引擎友好与用户友好，为什么必须在一个技术框架中实现？

RSS，以及现在google推出的sitemaps之类的技术，才是真正对搜索引擎友好的技术。在HTML这样的页面里做文章，会越来越行不通的。

http://www.google.com/webmasters/sitemaps/stats

再说用户友好，mechiland一语道破：异步响应是改善用户体验的终极之道！前进、后退这样的东西，根本就是静态页面时代的残留技术，更好的导航体验，不是前进、后退可以涵盖的。