AJAX 的七宗罪

需要对搜索引擎google友好的页面，不宜采用 。
我们的cms是采用静态化页面+ajax相结合方式


最近 开始在'43件事里' 尝试 ajax，感觉很不错!

===============
写下 一生中最重要的43件事
http://it915.net/zeitgeist

ajax在我的理解，它只是一个js的应用，把它做一个名词提出， 没有太大的必要。 另外现在的一些ajax框架， 几乎没什么用处， 将返回变成xml没必要，如果用了这些ajax框架，还得一定要返回xml，那就是更是没有任何意义。
但我不知道各位有没有实际使用js方面的体会， 用js最主要的还是如何高效的开发js。我想， 这才是重中这重。js的框架就不要了吧， java的框架已够多了。

以下是我的对js不足方面的一些看法， 这几条中， 任何一条没有被解决， 都让js不能被很好的用起来。

1. 到目前为止，我没有发现一个好的调试工具，也没有发现一个好的ide。
无论是ms的还是firefox下的调试工具， 都有很多不足。先说ms的， 稍好一点， 但是断点的设置，激活debug都不方便，也没有查看堆栈的功能。firefox的那个，几乎不能用， 连变量的查看窗口都很不方便，而且有些js都无法设断点，更不用说动态改值之类的操作了。
ide的工具呢， ms的那个也能算个可以用的， 但很多的属性都不支持， 另外举一个常用的运用：
var txtObj = document.getElementById('aaa');
txtObj.name = 'aaa';
像这个代码， 第一句可以支持， 第二句就没得提示了，而大多数情况下， 写js，就是为了类似第二句的代码。 这样一来，等于说是大部份情况都没有提示， 写代码一点不方便。

如果， 我java实现一个功能只要1小时， 用js得花去一天， 那我用它的代价是不是太高？！如果有人说， 因为我不是高手，所以对ide充满期望， 但我想说的是， 用ultraedit + System.out.println开发代码的时代早就过去。js开发代码无法像java一样高效。

2. 一个js写完， 无法有一个类似java中的junit类，去测试js代码。(补充， firefox中的一个extendsion也许可以做类似的工作， 但还只是我的猜想）。
那么，如果以后要对一个js函数做改动， 为了测试是否会影响其它函数， 只能用手工的方式一个个再测一次，

这样做，是否意味着又回到几年前开发java的方式？开发效率再一次降低。

3. 代码无法很好重用。现阶段只能从js调java， 即，js用get或post方式去调java.
程序员花了半天时间在js实现一个功能， 却无法被java代码调用， 也许又得用java重写一次。
据我了解，现阶段java调js，在的firefox工程中有了一个实现，但还有一些转换要自已去处理， 最主要的是速度还很慢，至少得加上一个类似cjlib， 第一次运行后生成java字节号的功能，才可能用一用。
如果我的代码都是java实现的， 根本不会存在这个调用的问题。

写过的代码，却无法重用，为同一个功能写两次代码，是件痛苦而又低效的事。

4. js的类库不多， 好的类库就几乎为0。 这和java的超多第三方开源代码是没得比的， 基本上， 就apache的上那些， 就够我们写代码爽上很久了， 用别人的代码， 快而无错的完成一个功能， 是多么快乐的事啊。

所有功能都得自已重写，低效。

所以， 如果是因为业务原因， 界面复杂，想用使用js。
那么要想用js（好听点叫ajax），请看看你们公司是否有以下条件， 如果有， 可以用一下：

1. 有不少js高手， 具备：
a, 不借助提示，可以记住绝大部份js函数
b, js代码很少出错。
2. 公司有一定基础，有很多js类库存在。

如果没有，在现阶段， 最好少用， 或不用吧。

因为我是从其它地方， 直接link到这个贴子，没注意到这里又新开了个区， 是专门Rich Internet Application， 而且dlee已为这个讲了很多贴。因为我自已所在的项目很忙， 很少有时间来看这里， 没有注意到。

勿勿发表的见解可能还有不成熟， 见谅。

May 11, 2005  Ajax: 99% Bad

What is Ajax?
Ajax was coined by Mr Garrett of Adaptive Path in his essay Ajax: A New Approach to Web Applications. This was on February 18, 2005, and even though it's only been under three months, the term has spread quickly.

Before defining Ajax in detail, Mr Garret described two examples: "Google Suggest and Google Maps are two examples of a new approach to web applications that we at Adaptive Path have been calling Ajax. The name is shorthand for Asynchronous JavaScript + XML, and it represents a fundamental shift in what’s possible on the Web."

So as not to be left without specifics, Mr Garrett goes on to describe the components of Ajax in detail: "standards-based presentation using XHTML and CSS; dynamic display and interaction using the Document Object Model; data interchange and manipulation using XML and XSLT; asynchronous data retrieval using XMLHttpRequest; and JavaScript binding everything together." It's certainly a mouthful, which is why having a nice, friendly name like Ajax is so helpful. So what's the problem?

99% Bad?In part, I'm being facetious. The title of this post is an allusion to Jakob Nielsen's famous post from October 29, 2000 called Flash: 99% Bad. In the article, Mr Nielsen says: "Although multimedia has its role on the Web, current Flash technology tends to discourage usability for three reasons: it makes bad design more likely, it breaks with the Web's fundamental interaction style, and it consumes resources that would be better spent enhancing a site's core value."

I love Flash, so when I originally read his article, I thought he was off-base. That said, I did see where his resentment came from. Flash was a great tool, but in the wrong hands it was making a mess of otherwise reasonable websites. Interestingly, the three complaints Mr Nielsen had about Flash are directly applicable to Ajax. Because the data is delivered without a reloading of the page, the URL is not descriptive of the contents on the page. This was one of the biggest complaints about all-Flash websites.

Popularizing the use of Ajax also has the problems of popularizing Flash. Although Flash is well-suited for behavioral and programmatic animations, many unscrupulous designers would simply use it to present a canned introduction to the site, along with the perennially despised "Skip Intro" link. Likewise, JavaScript presents the unscrupulous designer with a similar metaphorical rope with which to hang himself.

Take, for example, the design of the Designing User Experience (DUX) 2005 website. It's a nice looking site, as one would expect from a conference of user experience design, yet clicking on the links reveals a deeper problem. The content is replaced using JavaScript, and thus the URL of the page remains fixed even as the content changes. This prevents someone from bookmarking or sending a link to a certain piece of content to someone else. The people of Zago Design have ingeniously replicated the same poor design from their own website here for the DUX conference.

All these issues are not inherent to using JavaScript, nor are they inherent to using a full Ajax approach. Indeed, the DUX 2005 website is not written using XMLHttpRequest at all, even though it does rely on XHTML+CSS, DOM, and JavaScript. Why then do I claim the Ajax is 99% bad?

The Rabbit HoleIn addition to the reason that popularizing Ajax is giving unscrupulous designers rope to hang themselves, there is one other fundamental point that erks me.

First, the two examples that Mr Garrett points to do not qualify as Ajax. Google Suggest doesn't use XML/XSLT for data interchange and manipulation. It uses JavaScript arrays. Why did Mr Gibbs choose JavaScript arrays over XML/XSLT? Because it's a better approach. Does Google Suggest use XHTML? No. Why not? None of the Google sites save Blogger rely on XHTML code. So for someone to point to Google Suggest as the canonical example of their newly coined term, when in fact it doesn't match two of the five criteria is not only incorrect, it's a misrepresentation.

Adaptive Path is looking to sell a service. Telling people "this is how we build things, which is almost like how Google does it, but they use a slightly different approach 20% of the time" is much more complex than saying "Google does Ajax, and so do we." Unfortunately, this is, at worst, a lie and, at best a stretch.

1% GoodWhat's really going on here? Well, despite my complaints, I do want to give Adaptive Path credit. They have started a dialog around these architectural issues, and that is a great thing. It's gotten a lot of people eager to try some of these techniques out.

37 Signals put it best when they said: "As with anything, it’s not the technology that matters, it’s the proper application and the execution of that technology that counts. And most of all it’s how well we hide the technology."

I believe this is part of the reason for Google's success. Instead of writing a paper on the five technologies you need to make a cool website, they hired Chris Wetherell and Aaron Boodman and got to work.

Part of me wishes the Adaptive Path article had simply stated: Google has been writing madd JavaScript, and we think that's cool.

Posted by johnnie at May 11, 2005 12:04 AM

这只不过是SPRING DUDU 没事写的一篇文章而已，他自己不也用AJAX给首钢做项目吗？

to sun_wind：
这篇文章写的还是蛮客观的，比那个“七宗罪”要强很多。不过我对 99% 这个数字有不同的意见，说的太过了。其实 Ajax 应该算是三七开，七分是功，三分是过。
这篇文章认为 Google Suggest 采用的技术并不是真正的 Ajax，原因是其中没有使用 XML/XSLT，进而指出 Garrett 完全是在说谎。我并不这样看，我也并不这样狭隘地理解 Ajax，认为一定要把 Garrett 罗列的所有技术用足用全才叫做 Ajax。我把 Ajax 看作是客户端基于 JavaScript 的一系列技术的组合。可能这里的很多朋友都和我一样也是笼统地把这些基于 JavaScript 的技术都称之为 Ajax，我认为这并不是一个很大的问题。其实熟悉 JavaScript 的朋友即使完全不使用 XML/XSLT 而使用 JavaScript 数组、完全不使用 XMLHTTP 而用 IFrame，也完全有能力顺利完成自己的工作，结果都是用户得到了更好的交互体验。可能有些人认为我一定会誓死捍卫 XMLHTTP，我肯定会支持完全使用 XMLHTTP。这样的想法是错误的，我即使完全不使用 XMLHTTP，一样可以出色地完成工作。我关注的不是具体的技术，而是我要达到的目标。
Ajax 起到的作用和设计模式有点像，主要还是起到了一个统一术语的作用。如果没有这个术语，我跟别人说我使用 XMLHTTP 和 JavaScript 做开发，不用服务器端的 MVC 和 JSP 。他可能会非常不理解，进而问我一大串诸如 XMLHTTP 是什么之类的我不感兴趣回答的问题。现在我告诉他我们实现表示层的方式就是 Ajax，他一下子就明白了。

另外作者所指出的 Ajax、Flash 无法与超链接很好地结合的问题确实普遍存在。无论是使用 XMLHTTP 还是使用 IFrame（可以与浏览器的历史功能相结合）都无法解决这个问题。因此如果让用户得到超链接非常重要，那么还是采用传统的交互方式更合适。Ajax、Flash 这些客户端的解决方案目前还无法解决这个问题，甚至连 Echo 这样完全的服务器端的解决方案也同样存在这个问题。在 Echo2  中，URL 是永远不变的，和内容并没有什么直接的关联，这个问题在 Echo2 中甚至比在 Ajax/Flash 中更加严重。

to z_jordon：
从文风来说，那个 duduwolf 肯定不是 spring嘟嘟，spring嘟嘟可比他成熟和老练多了。我和 spring嘟嘟很熟，他的 blog 也不在那里。spring嘟嘟对于 JavaScript 和 Ajax 是非常熟悉的，不会写出这样漏洞百出的文章。

无论我们采用什么技术来做表示层开发，都始终需要有一个“纲”来指导（不是“以阶级斗争为纲”），这个“纲”就是更好的交互设计。除了完成基本的功能以外（这个是对于软件最基本的要求，否则如果验收通不过，你们连钱都收不回来了），让最终用户使用起来感觉非常方便，喜欢使用你们的软件。这种最终用户良好的口碑是可以为你们带来更多的生意的，所以不要想当然地以为这些东西不重要。Jakob Nielsen 大师所指出的 Flash 存在的问题其实是滥用 Flash 的结果，99% 这个数字是大师恨铁不成钢的感情发泄，完全可以理解。同样也会存在滥用  Ajax 的情况，Ajax 如果使用不当，得到更差的交互设计是完全有可能的。所以我们首先还是应该做一些交互设计的工作，然后再去考虑具体采用什么技术来实现。关于交互设计，可以看看《面向使用的软件设计》和《About Face 2.0》中文版。

在 “Ajax: 99% Bad”这篇文章中以偏概全所攻击的 Ajax 的一个主要的问题，即无法提供真正表示页面内容的超链接，Ajax 社区早有对策。有两种解决方法：
a9.com（http://a9.com）采用的方法是切换到一个新的页面，页面的 URL 包括了反映页面内容的信息。
Google Maps（http://maps.google.com）采用的方法不是切换到一个新的页面（更加彻底的 Ajax 交互方式），而是在页面上面提供一个 Link to this page 的超链接。

另外对于 Ajax 被滥用的问题，Ajax 社区也早就在研究，以前我所贴出的 Ajax Patterns 就是针对这个问题的解决方案。任何神奇的技术都有可能被滥用，我并不认为这些 Patterns 就是某人所认为的劣质技术的 Workaround。

http://www.softwareas.com/ajax-patterns
这篇文章是一篇信息量非常大的文章，所有对 Ajax 感兴趣的朋友都应该读一下这篇文章。这篇文章通篇都是围绕如何提高 Web 应用的可用性而展开的，也就是我上面所说的那个纲。如果不能带来更好的可用性和交互设计，让最终用户感到满意，我们为什么还要采用 Ajax？是不是纯粹的自添麻烦？还是为了显示谁谁是无所不知的牛x 程序员？事实上很多公司写很多的 JavaScript 最初都是因为来自于用户对于可用性的各种苛刻要求（不要想当然地以为用户都很仁慈，可以满足于拙劣的交互。事实上提出这些要求完全是用户的合法权利），而他们发现不借助于 JavaScript 很难解决这些问题。这个事实再一次打破了某人认为赚钱要紧，可用性和交互设计不重要的观点。这个就是与钱相关的问题，即使你再想不通，也千万别跟钱过不去啊。

非常不好意思