关于“重量级”使用Ajax的利与弊问题(希望大家帮忙)
关于Ajax的好处，我想大家都应该很清楚，
这种“交互性”，
这种“用户体验”，
还别说“用户”体验了，我自己做的，我自己感觉都非常好 ^_^。
现在遇到个让人疑惑的问题，自己也不敢轻易的下决定且能力有限.
问题是这样的: 在项目中“重量级”的应用Ajax会带来什么负面影响?
比如说性能啊？还有等等方面（具体多少方面大家得帮忙想想），
所谓“重量级”在我这可以理解为“桌面应用程序”，
举个简单的例子，
一个服务器端的控件：DataGrid，它完全可以用Javascript来控制生成动态的表格,表
格上实现分页，删除等等操作，然后再将其封装，可以说从功能上和DataGrid几乎相同。
究竟这样做会对性能或者哪些方面带来不好的影响呢?
大量的使用这种客户端技术对机器有什么特别的需求？
不知道这种“重量级”的Ajax操作会不会带来“意外”的弊端??
有或者安全性存在隐患？
请大家各抒己见，发表下对此问题的看法，谢谢大家
[解决办法]
目前只用轻量级的ajax应该，以前也试着用过像ajaxpro.dll之类的Ajax框架，但是感觉调试错误时不太方便，可能是版本问题吧
[解决办法]
不敢用太多Ajax总感觉有很多问题。
[解决办法]
用ajaxpro.dll调试是不方便，自己写XMLHttpRequest直接alert（xmlhttp.responseText)可以看到错误信息
[解决办法]
任何东西是一个双仞剑,总有利或弊
[解决办法]
赞成楼主意见
[解决办法]
ajax的缺陷还是有不少的，如果你觉得你能忍受的话就无所谓
1、破坏了浏览器的后退机制，后退按钮是一个标准的web站点的重要功能，但是它没法和js进行很好的合作。这是ajax所带来的一个比较严重的问题，因为用户往往是希望能够通过后退来取消前一次操作的。gmail可以实现后退，它只是采用的一个比较笨但是有效的办法，即用户单击后退按钮访问历史记录时，通过创建或使用一个隐藏的IFRAME来重现页面上的变更。（例如，当用户在Google Maps中单击后退时，它在一个隐藏的IFRAME中进行搜索，然后将搜索结果反映到Ajax元素上，以便将应用程序状态恢复到当时的状态。）
2、安全问题
技术同时也对IT企业带来了新的安全威胁，ajax技术就如同对企业数据建立了一个直接通道。这使得开发者在不经意间会暴露比以前更多的数据和服务器逻辑。ajax的逻辑可以对客户端的安全扫描技术隐藏起来，允许黑客从远端服务器上建立新的攻击。还有ajax也难以避免一些已知的安全弱点，诸如跨站点脚步攻击、SQL注入攻击和基于credentials的安全漏洞等。
3、对搜索引擎的支持比较弱。采用ajax技术的话搜索引擎更难搜索到该页面
4、破坏了程序的异常机制。至少从目前看来，像ajax.dll，ajaxpro.dll这些ajax框架是会破坏程序的异常机制的。关于这个问题，我曾经在开发过程中遇到过，但是查了一下网上几乎没有相关的介绍。后来我自己做了一次试验，分别采用ajax和传统的form提交的模式来删除一条数据……给我们的调试带来了很大的困难。
5、另外，像其他方面的一些问题，比如说违背了url和资源定位的初衷。例如，我给你一个url地址，如果采用了ajax技术，也许你在该url地址下面看到的和我在这个url地址下看到的内容是不同的。这个和资源定位的初衷是相背离的。
.....
详见我blog：http://www.cnblogs.com/ustbwuyi/archive/2007/02/08/645061.aspx
[解决办法]
我的系统有问题，字看得不太全。你所谓的重量级ajax是什么呢？
asp.net ajax 以及ajaxpro 我在项目中都层有所使用。当一开始使用asp.net ajax的时候很开心，觉得这下使用ajax方便多了，也不用担心js的浏览器兼容问题了，所以在其中的一个项目中可以说的大量的使用了这个，后台程序发布的时候因为是放在虚拟主机上使用，才感觉出来不太好，觉得最大的问题还是性能下降了不少。所以现在放弃了这个，将asp.net ajax从程序全部移除
我个人喜欢ajaxpro多一些。在局部实现ajax会比较方便,只是需要考虑不同类型的浏览器，在js方面需要下点工夫。不过性能我个人认为比asp.net ajax好一些。
[解决办法]
我个人不太建议大量使用ajax，不过在一些局部的，比较消耗时间的地方使用ajax会是一个比较好的选择。比如：在一个页面打开的时候它需要从其他的网站上抓取一个你很需要的东西，如果你直接在后台代码的pagelode中执行这个操作时间可能会比较长，在这个地方使用ajax来实现将会比较使用，等页面其他地方都加载完了，在去抓取这个数据并显示，一般在这类情况下我会使用JS+ajaxpro 或者js+xmlhttp来实现。
[解决办法]
ajax还没用熟..
个人倾向于部分页面使用，以前不是某人写过AJAX的七宗罪么
[解决办法]
唉，AJAX 不熟，
只是玩玩 AjaxPro，容易驾驭，个人喜欢，特别是 06.10.4 那个版本的 JSON 算法特快，
序列化16k， AjaxPro < 520ms, Altas Release 1.0 近 20s
我看，从纯应用角度选择，
Altas 适合全站单纯网站或者诸如社区型的Web应用程序， 因为它提供了和多 UI 方面的 Controls，并且便于与 ASP.NET WebControls WebPart 进行交互，有效的提高开发效率，
真的自己开发一套，客户端将数据集呈现为 table 的库，并不是一件轻松的事，特别是当你要考虑跨浏览器，这个前提还是你非常熟悉 JS dhtml css，为了能开发出高效的可维护行代码，你还必须精通基于 OO 的 js 设计，否则，一个项目完成之后，看着一陀一陀脚本代码，都是惨不忍睹
而像 AjaxPro AjaxMagic 这样的轻量集框架，适合偏重应用的系统，可以更加灵活的定制开发，
一般的，我是会包装一次某个框架，以适合自己的项目需求
------解决方案--------------------
AJAX太多了很难维护，其实我认为一直只需要在局部更新,而且这个局部不是比较小，如果只是为了更新这个局部而postback就很浪费，这个时候就用AJAX，如果这个页面就1个datagird，这个datagrid分页刷新也用AJAX，这个时候我觉的没必要了，因为这个时候AJAX要回传的数据和直接postback回传的数据相差不了多少，完全没必要这样做。
还有就是有的大数据需要加载出来，而一开始就加载出来，页面会要等很久，这个时候就用AJAX来延迟加载！！！
[解决办法]
顶起来
[解决办法]
权衡利弊，当利大于弊，用之，反之亦然
[解决办法]
学习
顶
[解决办法]
帮楼住顶人气.顶了再说
[解决办法]
我是做企业级的.用了AJAX后,上面最后不让用,说影响性能,还有很多不知的因素,可能导致很多问题,所以不敢用了,小的网站什么的还可以用下
[解决办法]
增加程序的复杂度，破坏程序的良好架构。很难调试。
[解决办法]
zhulei2008(滴水浪流) ( ) 信誉：100 Blog 加为好友 2007-07-12 17:11:32 得分: 0
郁闷，刚才用Ajax读取百万条数据然后一次性加载到表格上
竟然 -_-
aspnet_wp.exe 进程: 内存占用250
IEXPLORE.EXE 进程: 内存占用180
汗，百万条，强
前阵子用ajax做了个类似google日历的东西，也是用ajax来获取数据绑定，不过数据量比较小没什么，数据量大的话估计比较吃力
[解决办法]
ajax 实际上就是对XMLHttpRequest的封装
[解决办法]
你说的所谓重量级 其实只是对js的操作,大量应用js的话,就看你自己的功力了.
[解决办法]
、破坏了浏览器的后退机制，后退按钮是一个标准的web站点的重要功能，但是它没法和js进行很好的合作。这是ajax所带来的一个比较严重的问题，因为用户往往是希望能够通过后退来取消前一次操作的。gmail可以实现后退，它只是采用的一个比较笨但是有效的办法，即用户单击后退按钮访问历史记录时，通过创建或使用一个隐藏的IFRAME来重现页面上的变更。（例如，当用户在Google Maps中单击后退时，它在一个隐藏的IFRAME中进行搜索，然后将搜索结果反映到Ajax元素上，以便将应用程序状态恢复到当时的状态。）
2、安全问题
技术同时也对IT企业带来了新的安全威胁，ajax技术就如同对企业数据建立了一个直接通道。这使得开发者在不经意间会暴露比以前更多的数据和服务器逻辑。ajax的逻辑可以对客户端的安全扫描技术隐藏起来，允许黑客从远端服务器上建立新的攻击。还有ajax也难以避免一些已知的安全弱点，诸如跨站点脚步攻击、SQL注入攻击和基于credentials的安全漏洞等。
3、对搜索引擎的支持比较弱。采用ajax技术的话搜索引擎更难搜索到该页面
4、破坏了程序的异常机制。至少从目前看来，像ajax.dll，ajaxpro.dll这些ajax框架是会破坏程序的异常机制的。关于这个问题，我曾经在开发过程中遇到过，但是查了一下网上几乎没有相关的介绍。后来我自己做了一次试验，分别采用ajax和传统的form提交的模式来删除一条数据……给我们的调试带来了很大的困难。
5、另外，像其他方面的一些问题，比如说违背了url和资源定位的初衷。例如，我给你一个url地址，如果采用了ajax技术，也许你在该url地址下面看到的和我在这个url地址下看到的内容是不同的。这个和资源定位的初衷是相背离的。
[解决办法]
我的电脑本来不用升级的，可以多省点钱养老婆的
可以现在ajax满天飞，搞的电脑不升级看网页就是不舒服
唉！该死的ajax
[解决办法]
up
[解决办法]
楼住,根据实际情况用吧
[解决办法]
跟着后面学习了。
[解决办法]
ustbwuyi() 分析的很透彻，学习！
[解决办法]
高手真多，学习一下
[解决办法]
尽量还是用轻量一点的好感觉,往往用的多了需要考虑的方面太多造成在其他浏览器崩溃的问题...
[解决办法]
个人觉得还是少用为好，通常偶只用来填填下拉框什么，至于提交更新还是比较喜欢提交到iframe中，稳定且效率高，就是JS一定要熟才行。其实iframe用好了比ajax用着更爽。
[解决办法]
最大的坏处就是打起来比较慢，因为前台提示比较少
再就是调试，找错真的很慢
[解决办法]
第一,ajax本身是什么,楼主想过没??
第二,所谓重量级是什么意思?走httpmodule httphandle的去调用服务端的东西?
本身ajax的目的是增加客户体验用的,其实我更多的是用ajax调用webservice,自己写些东西,去更
改innerhtml或者局部变更,但是后来看了那些框架后,发现他们取巧了,但是浪费的资源也更多了
其实在不是特别要求效率的情况下,大量使用这种技术没有什么问题.不过有时宁愿自己封装。
还有ajax不是xmlhttpRequet这个是w3c的而不是ms的，自己封装xmlhttp不是什么有难度的事情
还有现在用的json技术，大家也应该看看
[解决办法]
Java确实比.Net好。单Applet就把.Net比下去了，拼命推ajex有个鸟用。
[解决办法]
AJAX的重量级应用 绝对不是大量的应用AJAX
AJAX要结合其他技术才是未来的方向.
AJAX对服务器压力几乎没有什么减小(熟悉实现机制的人肯定知道这个事实)
再就是AJAX简单的异步请求和显示也只是有限的改变了 "体验 "
AJAX的优势是在客户端建立一个简单的CLIENT.(我估计以后的浏览器绝对不会是超文本解析了,应该是直接运行代码对象)
这个CLIENT可以方便的访问网络上的各种数据源.可以是现在的页面,可以可是MS推广的服务.也可以是XML,可以是RSS等等东西.
AJAX结合WEBSERVICE才是AJAX近期比较实际又有价值的方向.
以最小的网络传输量,最精简的服务器处理量获得自由广泛的信息.
AJAX不会太长久,它必然被其他技术取代.
其实B/C还是C/S也没多大差别,浏览器本身就是个C.而以后应该出现一个类似现在ACTIVE X的东西 直接与服务器进行简单对象通信.超文本的缺陷将得到改善.
[解决办法]
虽然AJAX会被其他东西取代 但是我估计还是需要相当的时间的.
[解决办法]
rich client......
[解决办法]
性能上...
看你怎么用,如果你搞个自动完成的Textbox用户每敲两下键就给你服务器来个请求肯定死...
如果你用在列出数据表这样的应用上,甚至加上自己的cache机制的话,性能无疑提升很多...
工程管理上...
用别人的框架有很多问题上面的牛人们都有说了...
自己实现呢...JS这玩意一向被人说不好管理...
总之ajax算是新技术...还不算太成熟...
[解决办法]
TO LS
AJAX已经可以说成熟了
关键标准已经很明确
只是套装和散装还有区别.
自己实现的局限性还比较大
但是拿TELERIK的套件来说 已经相当牛B了比MS的还丰富 甚至解决MS解决不了的FILEUPLOAD问题
我也见过一个非常牛B的人仿造了TELERIK的AJAX
功能可以说实现了70% 但是性能只达到人家的29%
[解决办法]
可以局部使用，比如页内使用，但整个应用使用ajax确实降低效率。
后退是一个问题，还有每次使用都要重新加载，如果程序很大又每天要用，这种方式就不可忍受了。
[解决办法]
还有就是调试起来不方便，客户端报错根本无法跟踪具体什么error
[解决办法]
...
[解决办法]
不敢用的太多
[解决办法]
O
[解决办法]
up
[解决办法]
我目前能力有限，只对AJAX略知皮毛。所以就在必须用AJAX的时候才用。
[解决办法]
xmlhttp base64 adodb.stream实现的上传?那有权限问题啊
[解决办法]
刚遇到一个问题:
由于iis启动不了，重装了，启动一次后又启动不了了，提示地址已被使用。把端口号改了，可以启动，可是打开网站之后，原来那些漂亮的界面都不见了，图片也不能显示。应用ajax框架.why ?
[解决办法]
ding
[解决办法]
mark!
[解决办法]
目前我见过最重的AJAX:
http://armory.worldofwarcraft.com/
我自己也在用AJAX,不过一般是用在细节上.
现在用户已经习惯页面跳转的浏览方式.AJAX只是作为补充.
如果要花很多力气, 去用AJAX模拟浏览器的前进后退, 是很不值得的.
如果说AJAX是XmlHttpRequest, 那么AJAX很成熟.
如果说AJAX是整站的无刷新, 那么AJAX只是个还不会爬的BB.
------解决方案--------------------
个人认为 Ajax 只是功能上的一个点缀而已，非要用 Ajax 来处理大批量数量或是重要功能，那只能是适得其反
[解决办法]
百万级的建议使用JSON代替XML来返回数据
[解决办法]
先顶一下再说
[解决办法]
即使Ajax倒下，不过不要紧，它本身就是一个过渡性技术。不过，Ajax所要做的，就是给我们洗脑：
Ajax告诉我们，重视脚本，因为他们灵活。
Ajax告诉我们，重视用户，因为他们掏钱。
Ajax告诉我们，重视交互，因为软件就是服务。
Ajax告诉我们，重视Web，因为方便比什么都重要。
Ajax告诉我们，摘下眼罩，换种方式思考问题吧。当你背过脸无视世界的变化时，是世界抛弃了你，而不是你以为的掩耳盗铃。
[解决办法]
为Ajax而Ajax(Using Ajax for the sake of Ajax.)
很同意这点，当一个技术本身的生存意义由于它自身的亮点而被抹杀，不知道是这个技术的幸运还是不幸。
干掉了back按钮(Breaking the back button)
back按钮是一个标准的web站点UI的重要功能。然后，后退按钮没法和js很好的合作……
gmail似乎作的很好？不过没去仔细看过gmail如何实现后退和js相容的，被这个mistake一提醒，也许这也是ue的一个切口哦。
点击的时候没有提供一个可视化的提示(Not giving immediate visual cues for clicking widgets)
……也许是我没看懂，觉得写这段的人自相矛盾。。他说没提供可视化提示，不过是拿gmail右上角的红色提示作为例子。
阻挡了离线用户于门外(Leaving offline people behind)
看标题就清楚了，不过我持保留意见，web application和离线浏览本身似乎就存在着矛盾，要整合，可能要动很多脑子
别让我等(Don’t make me wait)
不过，ajax本身就存在着如果客户端的带宽不够，它的展示就会一塌糊涂的问题，这是它的先天缺陷，也是它崛起的先天因素－－由于网速和带宽的不断增大，使得服务端与客户端的频繁通信成为可能。
显式的传递敏感信息(Sending sensitive information in the clear)
使用js传递数据，本身似乎就存在着这个风险，在我找到反对意见之前，我倾向认同这点－－https协议除外。
假设ajax发展是一个单平台的发展。(Assuming AJAX development is single platform development)
作者文中的观点是ajax由于必须兼容多个浏览器，而没法做到只需要编码到标准的js就行，还要考虑到各个浏览器的问题……这个是js的问题，和ajax关系不大吧？
忘掉了可能多人在同时使用同一个应用(Forgetting that multiple people might be using the same application at the same time)
嗯，这其实是一个同步的问题，在b/s系统中这是一个麻烦的问题……当然，也许并不麻烦，做一个标记位就解决了吧？
太多代码让浏览器慢下来(Too much code makes the browser slow)
呃……同意这点，虽然在代码优化之后会有很大改善，但js本身运行速度慢这个缺陷还是会成为一个瓶颈。
不计划要那些禁用或者没有js的用户(Not having a plan for those who do not enable or have JavaScript)
呃……我在页面上用ajax的时候就准备放弃这些用户了，我没google那么闲，作两套系统，一套用ajax，一套纯页面。不过养成一个良好的编码习惯还是有必要，比如在超链接中不要直接设置href= "javascript:... "而使用onmouseup或者onclick来触发事件，偶尔也为别人考虑考虑嘛，而且我也不能保证我的js程序在所有的浏览器上通吃。
不期然的页面闪烁和改变(Blinking and changing parts of the page unexpectedly)
我没经历过以前网页中blink标签的骚扰，所以我对作者的反感有点摸不着头脑，我觉得在适当的提示之后刷新某块页面总比整个页面的刷新看起来舒服。
没法把超链接发给朋友以及收藏(Not using links I can pass to friends or bookmark)
嘿嘿，这就是我上面提及的那点，如果编码习惯够好－－而且时间够多，在超链接中为非js用户和js用户提供两套方案是可行的。
同步导致的批量操作(Asynchronously performing batch operations)
作者的意思是说ajax一次性把原来要分几次作的操作一次做掉，而导致他没法跟踪每个元素变化，没法回溯，呃……也许是有这种需求吧。。不过似乎也是可以解决的吧？
导致页面滚动并让我迷失位置（Scrolling the page and making me lose my place）
作者认为插入文本到一个页面中会导致页面发生滚动，并让其迷失方向，我没看过这么恶心的效果，没法评价，不过我对于一些ajax的导航作的不好表示不满意，我经常会迷失于一些ajax程序中而不知道我刚才上一步到了哪里……
发明了新的UI习惯（Inventing new UI conventions）
呵呵，作者用了一句话来描述这个缺点：“点击一个不明显的东东来产生一个不明显的结果”。这个归纳倒是满准确的，在很多ajax程序中，用户完全是作为一个瞎子，在抖抖索索的摸着这个ajax程序大象，在到处瞎点一气并瞎拖一气之后才掌握这个程序的用法。但是换个角度来说，最开始的web页面不也是一样？没有开始的困难接触，不会有之后的进步，只要有足够的帮助，上手任何东西都应该不会太难－－除非这东西本来就不想让人觉得好用，那就是其它的问题了。
阻止了爬虫（Blocking Spidering）
同意这点，我在犹豫着使用ajax的时候，就在考虑爬虫对js的不感冒，以及爬虫该如何理解我那些以奇怪方式加载的页面，去解析ajax库似乎是一个不可能的事情，爬虫又不是人脑，如果爬虫可以媲美人脑，那就是《骇客帝国4》了。
字符集（Character Sets）
ajax本身对字符集的支持比较缺失，这个这个……设置成utf-8吧，不过作者最后也是这么说的。
使用超链接改变状态（Changing state with links (GET requests)）
作者认为主流的ajax应用程序都是用get方式来工作，而这违反了W3对GET和POST方法的使用建议……我少见多怪，主流的ajax应用程序我没怎么去看，不知道是不是真的都用get，虽然ajax编码用get简单，但不表示ajax不能用post吧？
没有连带改变页面中其它相关部分（Not cascading local changes to other parts of the page）
因为ajax让人很容易控制页面中的特定部分，所以也容易导致过于关注某个点而失去对整体布局的关注。嗯嗯……这是编码的问题，表怪到ajax头上。
问题报告（Problem reporting）
作者认为服务端的程序错误，很容易再现并捕捉，而客户端的错误要重现就比较麻烦，嗯，支持这点，不过还是和ajax关系不大……
投资回报(Return on Investment)
作者认为ajax能够提升应用程序的可用性，但是富客户端程序并不会比纯html版本好多少……忽略这个观点，来人，把作者拖出去，账责五十
[解决办法]
只要符合要求，能够实现要求的就是你所需要的。
如果非要给出个X宗罪，没有一种技术，一种语言是完美的。
就像非得用一个锅盖来衡量所有的锅一样，是不恰当的。
建议局部使用AJAX，多种技术结合才能产生最好的效果。
顺便给俺的作品作一下广告：http://www.qpix.cn
局部(交互部分)使用的AJAX，动态效果还是不错的。
[解决办法]
如果只是简单的无刷新 那当然是鸡肋 要用AJAX就用AJAX+SERVICE
[解决办法]
ajax最大的好处,当然是节省时间了,速度稍快了.
但是最大的坏处你们知道吗?就是对搜索引擎的极度不友好,现在不靠搜索引擎会死人地!
[解决办法]
长见识了
[解决办法]
好处快，坏处快，不要看影子，看人....不需要那么快的时候，太快只能是带来其他方面的缺失，需要那么快的时候，其他的即便缺失也要考虑ajax
[解决办法]
都说到这份上了 还能说什么？
只能接分了！
[解决办法]
什么叫做重量级？把服务器端的大量工作都搬到客户端用JavaScript来做就算是重量级了吗？显然不是。称之为AJAX应用而不是JavaScript应用，就因为还存在网络上的沟通，不是单纯的JavaScript就能完成任务的。
[解决办法]
学习中...
[解决办法]
学习了.
[解决办法]
用多了是不好
[解决办法]
AJAX的七宗罪
引子
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标准？ <span onclick= "location.href= 'detail/ '; "> 点击查看全部 </a> ，这就是破坏了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 写的，其中的观点和我所说的七宗罪中的几宗相似。 --来源：嘟嘟老窝 duduwolf
AJAX的辩解
从听说AJAX开始，我就一直搞不这东西是什么东西，好好的一个XMLHTTP要再裹上AJAX，不明白有什么意义。我想会不会AJAX不是一个实际东西(没有实际的成果)，只是一种设计观念。我自己也用XMLHTTP写过很多东西。以XMLHTTP来看，对别人提出的那些罪宗觉得是他们在无理取闹。
冤之一：对搜索引擎的支持不好
这个好像跟搜索引擎扯不上关系吧。
还有谁说WEB设计就一定要有超连接在里面啊。可能告诉我哪里有制定这样的标准啊？
--来源：chon81
冤之二：编写复杂、容易出错
javascript只是没有直接创建类的方法，javascript是一个完全的面向对象的东西，每种类型的值，甚至函数都可以看做是对象。javascript虽然没有直接创建类的方法，但同样可以用其它方法创建出类，如用function创建的函数可以当做类来new一个对象出来。
至于debug工具不是没有而是比较少，MS的Visual InterDev，Mozilla中的DOM察看器和Javascript Debugger扩展都可以用来调试的。同样也可以用javascript写一些简单的调试程序。
冤之三：冗余代码更多了
会有很多JS代码我承认，但是如果减少了JS代码，就不会增加HTML代码吗？增多的HTML代码分部到不同的页面的每打开也要占用网络。然而大多的HTML都是通过服务器上的脚本产生的，这不是加大了服务器的负担了。把数据的处理放到客户端用JS处理可以分担服务的很多任务。
冤之四：破坏了Web的原有标准
我绝对是一个W3C的支持者，但我不明白用 <span onclick= "location.href= 'detail/ '; "> 而不用 <a> 跟标准有什么冲突的。我记得以前我有看到一个W3C的页面里面，也有这么写的。
冤之五：缺少一个没有标准之争、没有back和history的浏览器
没有back但还是有这个页面的history。可是没有back不觉得对会更好吗，做为用Web开发系统的开发人员来说，常见的一个问题，就是因为back了，引起重复提交。的确有不同浏览器中创建XMLHTTP对象的方法不一样，但使用上是差不多的。开发者可以把这些封装到一个类里面，使用上就从这个类里面创建的一样的。还有这样跟那两个网站有没有什么关系吧，他们爱怎么开发就怎么开发，总不能因为就那两个网站而打死一大片吧。
冤之六：XML只是用来打幌子
这个我是为XML鸣冤的，Jesse James Garrett是不是趋于流行我不知道。但我认为XML的创建就是为了数据格式更明了，开发者之间更容易沟通。所以XML文件是有可能会比较大，难道HTML就不会了吗？本是同根生嘛！(据说下一个版本的XML会加强数据的压缩)在客户端要对XML进行解释，那是肯定的，我觉得这样者使XML的使用上更灵活
[解决办法]
留个脚印，学习学习
[解决办法]
不过我听说像163邮箱之类的都大量应用了ajax呢，做出来的效果好好哦
[解决办法]
不可否认的AJAX可以为用户带来很好的用户体验，但这还是建立在浏览器支持AJAX上，其他方面好处坏处的都有各种说法。但是AJAX在WEB应用上足以致命的：
1). AJAX 并不一定能减轻数据查询，有的地方增加了数据库的负担，处理的不好的话会导致服务器承受更大的负担。传统方式中，对于一个用户而言用户每对服务器进行一次请求需要等待服务器做出响应后才能对服务器进行另一次请求，这样后面的请求能确保是在上一个请求执行完以后处理的。但是AJAX异步请求打破了这种束缚，一个用户就可以快速的连续的执行多次到几十次的请求（如拖动的分页的导航条，从1到10，如果直接拖到10那就有2-9的回发是没有用的，更何况有时用户并不会直接拖到位或因显示速度原因发生来回不断的尝试），相对于传统方式来说，这会对服务器提出更高的要求以及对程序设计者带来更大的挑战。可能许多请求都是无用的或者是无效的，那么这将会浪费大量的服务器资源。
2). 对搜索引擎不友好，不利于搜索引擎对整个网页的搜索(如无法搜索到AJAX的数据，因为可能AJAX的网页没有或只有少量不改变的HTML内容)，最后的结果就是(特别是baidu.com，google.com也许还会利用网页的Description)网页内容搜索不到，因为搜索引擎或称搜索机器人只能搜索网页内静态HTML内容。互联网上绝大部分是企业服务、新闻财经、电子商务、教育培训、展览展示、论坛峰会、交友社区、生活美食、评选投票、法律律师、介绍投资、医药健康、游戏旅游、艺术音乐、摄影图片、时尚娱乐、拍卖下载等等网站，这些网站哪个不是很需要让搜索引擎搜索到网站和网页每一部分内容的。在一个搜索引擎日渐驱动网站访问量的世界里，在你的网页排名上稍微得到一些提高就能给你的业务带来不错的投资回报(ROI)。
3). 因为AJAX只能使用Post回发，所以页面没有链接（或很少链接），搜索引擎不可能产生onClick行为来 Post 获得网页内容的改变。（如分页采取Post，那么搜索引擎只能搜索到第一张页面而无法通过链接方法获得整个站点的所有网页），这将直接导致站点排名的降低。另外就是因为网页没有改变，浏览器没有历史记录；网页不能收藏直接导致网页不能分享。这里还提出一个很重要的问题：没有链接的网站算网站吗？
4). 有的AJAX用户也没有觉得方便了很多，虽然有的地方还是看着舒服点，但实际开发的时间则大大增加(可能要为解决其他问题多写几到几十倍的代码)，Js代码也难于维护，有些得不偿失。
5). AJAX不过是在现在的HTML的平台上的一种折衷方案，折衷的方案是不会长久的，不知道以后 W3C 对AJAX的标准是什么。也就是说，现在做的AJAX是没有标准的。最要命的就是没有标准的东西也就不能确保任何网站文挡都能够长期有效，简化代码、降低建设成本。也就不能能适应更多不同用户和更多网路设备，当浏览器版本更新，或者出现新的网络交互设备时，无法确保所有AJAX应用能够继续正确执行。
6). AJAX兼容性非常不好，这是大家都知道的。由于AJAX需要Javascrip的支持，另外还需要用到xmlhttp对象，所以对于浏览器的兼容性需要考虑。专业化的网站要求兼顾网站访问者浏览的方便、易用性及主流浏览器的兼容性（Internet Explorer，Netscape，Mozilla Firefox，Opera，Safari）这些AJAX是做不到的。难道我们做的网站就应该扔掉不支持AJAX浏览器的用户？
7). 用户的习惯性，很多用户习惯与使用传统的方式来与服务器进行交互，突然出现一种新的方式的时候反而会让他们不知所错。AJAX这种表面看上去不需要刷新浏览器，因此在很多情况下用户执行一个操作后发现浏览器并没什么动静会感到很迷茫，特别是当网络速度慢的时候(如电信和联通)，用户的一个请求需要很长时间才能反应，在等待的这段期间，用户也许会认为WEB有问题关掉浏览器或则再做别的什么事情。另外，用户会习惯于浏览器提供的一些功能，比如前进、后退、刷新、停止，这些功能是用户会经常并习惯用到的，当采用AJAX的时候会导致这些功能大多失效。
所以AJAX不会是以后网站发展的方向，它也不会对WEB带来革命性的改变。AJAX适用于什么？能干什么？能带来什么？在网站上用AJAX那是笑话，除非像Google Map和Flickr这样的专业领域的网站外，普通网站根本没必要用这个技术；在庞大的企业应用市场估计还能有AJAX的一点容身之地。
文章出处: http://www.webxml.com.cn/h/72694F4C2F626537385A493D.aspx
[解决办法]
to: godgreat()接触到计算机，才知道他娘的什么叫学海无涯！()
提到好几次 "为非js用户和js用户提供两套方案 "
那有什么意思呢?为了AJAX就要做 "两套方案 "那成本要提高多少.JS还有个最头痛的问题就是维护非常困难.
[解决办法]
学习
帮顶
