AJAX 的七宗罪

to 庄表伟：
是啊，Ajax 从来也没有承诺过解决 Web 表示层开发的所有问题。它仅仅是在用户友好这方面前进了一步，这一步对于很多应用是非常关键的。
我也同意  mechiland 的“异步响应是改善用户体验的终极之道”这个判断。

1，就目前web的开发，确实有必要区别网站开发和企业内部系统开发，而就当下，一个对搜索引擎不友好的技术是很难在网站开发中立足的。
2，js的debug确实是一个问题，虽然有工具但比传统的ide差的远。尤其是对新手而言。
3，ajax确实是提高了客户体验，我也同意“异步响应是改善用户体验的终极之道”。

换一个角度来看这个问题罢。就是我们做技术是为了什么？我们当然不是为了技术而技术，而是为了实现商业价值。
那么，在实现商业价值的前提下。我们来看看前面讨论的各项内容罢。
关于网站，首先，对用户友好是一方面，这就把网站的老用户留住。
  其次，对搜索引擎友好，这就能不断发展，吸纳新用户。
  两个方面都重要，都是一个网站实现商业价值的重要组成部分。
  （如果换用交互式设计来讨论的话，同样可以得到两个方面都重要的结论，因为两个方面代表了两种类型的player，需要对他们都进行考虑）
  那么，在这种情况下，ajax处于何地呢？
  先说第二种情况罢，针对搜索引擎，至少ajax目前对于搜索引擎极不友好。所以如果那些需要被搜索引擎搜索到的，当然用ajax就不好了。
  然后再说第一种情况，对于用户友好。事实上，ajax作为改善用户体验的一部分，可以合理利用。然而这也不摈弃传统的以url连接为主的网站开发模式。就比如china-pub,javaeye等这种基于连接的，我们并不会觉得不友好。
  所以这就有两个推论。推论一，ajax有用户友好度并不能推论传统link方式没有用户友好度。
然后又推出推论二，ajax只是作为传统网站开发技术的有益补充。

再说dlee关于对google能搜索ajax的预测。事实上我并不看好。
  同样的道理，也是商业价值。并不是google能做一件事情，他就会去做的。看看google推出的各项服务，
比如news搜索或者image搜索，都是有庞大用户群的。
而且对于网页搜索来说都是有益补充。（或者说边际效益很大）
而ajax这种只是网页的一个有益补充，又只是信息海洋中非常小的一块(采用ajax的网页信息量比起传统方式网页的信息量必然是非常非常小的一个比值），那么这种情况下，google作ajax搜索就实在毫无疑义，或者说，边际效益甚小以至于不值得作。
  讨论完商业考虑，也可以看看技术考虑，技术上ajax现在实现五花八门，传输格式也不统一，而且也有不采用
xml传输的比如jsonrpc的方案存在，这就使得ajax搜索，即便不是不可能，也变得非常复杂，以至于google在那么小的商业价值上来实现它，真的是非常没有必要。
  再讨论标准化和flash的搜索。关于flash搜索，至少bytecode还有一个标准，这使得技术支持变得相对容易，然而仍然是商业价值，除非flash应用变得大规模
而普遍，在flash应用上的信息量非常之巨大，可以达到
支持flash搜索具有商业价值的时候，那么google才会考虑加上对flash搜索。所以我对这点持观望态度。
  关于标准化的态度，以前跟庄表伟讨论过，有些标准走的太极端了，比如像不推荐使用table,建议全用css来做等等，就是矫枉过正了，不仅没有必要，而且现有的开发
人员是不会去这样做的，因为没有必要，同样也是边际效益太低呵呵。而且google也不会在乎你的网页里头有<table>,有<b>什么的，他老早就解决这些问题了。

 
  又想起来一点，更新一下，ajax搜索和flash搜索完全不能类比。ajax等价与Form Post,因为要提交的数据未知，google直到目前都不支持Post搜索，那么
有什么理由相信他会支持ajax搜索。至于flash搜索其实跟传统网页是等价的，
就是信息已经放好在那个网页里或flash里了。

用户对于交互的期望其实并不是传统的基于 HTML  FORM 的交互模式所能满足的。这种交互模式的缺点非常明显，有些用户所期望的交互行为完全依靠服务器端的 Struts/WebWork/JSP/JSTL（所有的表示逻辑全部在服务器端执行）是很难实现的。这也是 WebWork 决定加大对于 Ajax/XMLHTTP 的支持的原因，我并不认为这是单纯的迎合市场的行为。其实服务器端的架构到是可以稍微马虎一点（例如：不必过多地争论 Struts/WebWork 的优劣），只有界面和交互设计是无法马虎的，因为这是用户立即可以感受到的，事关他们对于你的产品的评价。更进一步，关系到你的产品的市场。

改善用户的交互体验，JS 就是放在你手边的一把刀，是你马上就可以加以利用的资源，因此如何充分利用好 JS 的功能就是一个非常合理正当的思路。不使用 JS，使用其它的方法都是舍近求远。robbin 开设这个版，其目的就是讨论和探索使用 JS 的各种可能性。这个版也是为感兴趣的网友开设的，因为目前确实有很多开发者对 JS 开发感兴趣。而基于 JS 的开发最近一段时间越来越多也是一个事实，而且看起来是一个明显的趋势。

这个版讨论的是使用 JS 的各种可能性和解决办法，为大家开阔思路，而不是长篇累犊地争论 Ajax 有没有存在的价值，是否应该生下来的问题。现在的情况是不管怎样，他已经生下来了，我们如何利用好这些技术达到我们的目的

Ajax 并不是包治百病的灵丹妙药，也有其适用的范围，仅仅因为没有满足搜索引擎友好就忽略掉 Ajax 其它方面的优点，实在是太一叶障目了。这些做法没有绝对的对错，最终还是由用户的选择和市场来做决定好了。

说一点题外话，很早我就和一个朋友交流过这样的观点──一个新技术或者新思想出来以后，往往会带有一些缺点和不足，大家都在讨论它的不足，但是有的人在想办法完善它，有的人只是指责，如果这个新东西成功了，受益的是前者，吃亏的是后者，如果失败了，前者固然吃亏，后者也一样受损──因为他已经把时间和精力浪费在争论上了。
所以小平说过一句话──“不争论”，我认为非常有见地。

精彩啊,呵呵,两天没来,又走宝了...

AJAX技术只是RIA目标的一个实现手段.而RIA和目前我们所理解的WEB是完全不同的东西,拿评价WEB的标准来评价一个RIA的技术是不适用的.

RIA要做的是"基于互连网客户体验丰富的应用",我们如果把它想象成为"多人联网的网络RPG"或者"通过互联网运行的ERP",那么你肯定是不会使用WEB的标准来衡量它的,肯定不会关注它是不是遵循W3C的规范,肯定不会管Google是不是能够有效的索引,-----因为它就不是网站.

你不会用WEB的标准来衡量FLASH/FLEX,不会用WEB的标准来衡量XUL,不会用WEB的标准来衡量APPLET,也肯定不会用WEB的标准来衡量传说中的XAML,那么为什么要用WEB的标准来衡量AJAX呢?----难道就仅仅是因为它也是运行在浏览器中,而且它也用了DHTML技术么?

在我看来,它的设计思路是比较务实的.依托现有的浏览器能力而不是另创一套运行环境.现在就能用,这总比我们一等再等还要继续等的XAML要来得实际一些吧.

其实我倒希望web browser能支持一些其他脚本，比如python,ruby什么的，来一个新的编程范型。
否则很多东西都用js作来太累了。

现在讨论AJAX有多少罪 完全没有必要.当务之急是如何完善AJAX.

我想完全依靠客户端来控制流程肯定是不行的 不仅权限的问题会变得复杂, 这样做还会让我们失去灵活性(不可控制决不是灵活).

AJAX的新特点是值得肯定的 但想脱离server端的是错误的 这个思路会害死人. 这和企图用jsp替代一切页面中的js一样极端和愚蠢. 


现在流行的WEB开发框架没有一种适合AJAX 要让AJAX发挥作用还要做很多工作.

和ajax相匹配的开发框架应该具备这样的特点

1 比较方便的处理soap请求 至少不需要自己封装和解封

2 能够方便的处理xml 比如sql->xml

3 让xul js server端结合起来 形成统一组件. 开发者不用考虑那些是server端实现的效果 那些是js的功效 只需要将其看成一个可用的组件即可. 避免开发人员 在server端 cilent端 两面作战的局面(这样做肯定会引起混乱).

我认为AJAX可广泛应用在交互频繁、流程复杂的业务系统中，而需要对搜索引擎提供良好支持的多数都是信息发布系统。AJAX在后类系统中并不具有优势。采用RSS+AJAX的框架一样可以兼顾这两点。（通过Proxy方式可绕过browser对访问不同RSS源的安全限制）
代码的组织性并不是AJAX的缺陷，有良好的框架这个不是问题。
其余几点就不用说了。除了第5点。

Browser没有统一的标准确实是真正的根本有待解决的问题。FireFox在Dom模型上较IE有了几点非常重要的改进，页面在整个应用中的地位，是相对孤立的页面还是有从属整个应用的一个模块？这些仅仅靠 共享cookie，或者能通过window handle 访问其他的页面是不够的。例如：一个页面可以捕获另外一个页面抛出来的异常，instaneof的逻辑可以跨页面等等。IE更有待改进，据说IE7即将推出，在这几个问题上，我拭目以待。[/i]