才发现的好东东。jQuery架构的开发者之一Simon Willison在前天新提供了一个简洁明了的用法演示—— 15分钟搞定jQuery（jQuery in 15 minutes）。开发人员提供的教程更应该能体现jQuery的神髓。

在翻译《为什么选择Dojo》这篇文章的过程中发现了有关该文章的讨论链接（http://ajaxian.com/archives/why-choose-dojo）。这些讨论中也涉及了很多常用框架的评价，都可以做为第三方的参考意见，同时Dojo官方的开发人员也加入了这场争论当中。讨论中也涉及到其它主流的框架技术特点比较，具有一定参考意义。从讨论中可以看出Dojo早期的版本确实问题多多，而且因为种种问题似乎正在走向衰落。不过还好有Dojo官方开发人员介入讨论才有新的认识，同时也可以感知新版Dojo0.9版应该是被Dojo官方寄予厚望的产品，也许借助这个版本能重新赢得开发人员的支持。这些辩论非常精彩，觉的有必要翻译过来，于是对部分有价值的发言做了翻译整理，放在此处。可以与《〈为什么选择Dojo〉－兼评测其它主流的JavaScript框架工具包(之一)》对照参看。这个系列仅两部分，本文为截止篇。

＝＝以下是相关讨论的译文＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
原文链接：http://ajaxian.com/archives/why-choose-dojo
翻译：多多小虫(bigqiang)

AsiaPartTime：
有人把微软的Ajax框架与Dojo比较过吗？有人做过把这两个框架结合在一起使用的尝试没有？我希望能碰到这方面的高手。
（译注：翻译完才发现原来主流框架里面漏了微软的ASP.NET AJAX控件工具包（以前叫Atlas），不用说这个框架的服务器端部分会局限在微软的架构上，不能跨平台。）

Timothy Dang：
如果你不在乎那个Dojo框架提供的离线功能，我相信 jQuery 和 Ext 在所有框架中是最优选择，而且他们二者可以非常完美地结合在一起。

M：
我特别在意“社区”那一部分。
我用的最后一个框架是 Mootools。但是那个“社区”总是一副对人爱理不理的傲慢面孔，比如那个Mootools的论坛(the Mootools forums)。我以后的项目再不会用那个 Mootools 。
(译注：不是技术而是一个社区的气氛竟然影响了开发者的选择取向，值得深思。)

gonchuki：
文中没有专门对 Mootools 的评价，仅在涉及JQuery的部分稍微提了一下…
希望 moo 1.2 发布后能得到大量它应得的关注。

r：
我在做一个 OSS 项目，在这期间我从一个框架跳到另一个框架：最初是dojo，然后是 prototype/script，而现在是 jquery+yui。
虽然在博客上发这样的文章是个很好的宣传，但是它仍然不能回答人们为什么象躲避瘟疫一样远离 Dojo 的真正原因。
Dojo 是为软件工程师们写的，他们绞尽脑汁地想在Javascript上封装所有应用。但绝大多数Web开发者想做的仅仅是把“能用”的代码东东放在一起就好。 可是来到Dojo 网站看到了什么，它给了我一个8MB tar文件的下载链接。 那样的情况下我只好去搜索 Prototype，而它提供的链接只是一个小小 JS 文件。
对这一切而言，“Dojo 0.9”在大小上与 Prototype 和另的库文件根本不具可比性。不仅如此，学习 Dojo 代码困难程度也是令人难以置信。可以尝试装上 Prototype 和 Dojo 核心JS文件，然后自己感受一下哪一个会让你开发速度更快捷。
我许多朋友不是从事Web开发的，但由于一些课题必须做一些轻量级的Web开发。对 DOM操作部分，我建议他们用jQuery，因为绝大多数人熟悉XPath，并且他们会很喜欢jQuery链串的那种语法表达方式。我知道 Dojo 0.9 已经有了CSS3选择器，但除此而外就一无所有了（如果我错了请指正）。使用这种模仿的选择器太笨了，不是我一个这样认为。
当然他们也做了些好的技术决策，比如Prototype 的Array()对象操作真是杀手级的应用，但是显而易见这些似乎并不能赢得更多开发人员的关注。

ajaxus.net：
读完后还是不能使我信服，为什么要用Dojo。

Cyril：
“YUI 目标人群是专业的PHP开发者”
不相信那篇文章的说法。尽管Yahoo使用PHP，但是YUI不是一个以特殊服务器端为基础的技术。

kangax：
我实在没有认识到widgets有什么好处，Dojo似乎拔高了它作为他们主要功能特点的好处。
我喜欢的是打包系统(packaging system )和命名空间——那些原型所缺乏的东西，不过YUI不需要额外开销就做到了这些。

Jonathan：
我选择dojo是因为它的许可协议，也与我个人经验有关。它很容易与 EXT 或别的框架集成。作为一个开发者，我希望将来的框架能彼此很好的集成在一起。

Hank：
这篇文章应该改名为“为什么不选择Dojo”，这才是必然的结果。太缺乏开发文档的情况下导致这种情况是理所当然的，这是开发一个富集API的最重要的方面。浏览一下他们的API文档根本没有真正提供什么有效的东西，他们不解释说明某些对象是做什么用的，也不提供一个他们如何起作用的示例。甚至在 the Dojo Book 0.9 中仅有一个架构图。

Tom Trenka：（译注：这个似乎是Dojo的官方人员）
回复r: 你下载的 8MB tar文件包，是因为它包含了所有的工具，这些工具可用于创建适用于你自己的简洁构造版本。在所有代码文件中，如果你是想和Prototype做比较，那么所需要的应该是这个工具包里面dojo目录下的dojo.js文件来与Prototype进行大小比较。我们使用CSS3选择器是因为我们痛苦地意识到 XPath还没有得到我们所想看到的开发团体的某种认可。就个人而言我认为CSS3语法已经足够满足所需（尽管可能不能满足你的需要，我想我们能拥有完整的 XPath能力）。我想你可能 仍然在思考0.4.x 子版本“太过笨重”；Dojo Core (0.9) 对我而言相当轻量级。
回复Cyril：我还不能完全确定，但是我感觉Alex那样说的原因在于从YUI开发团队那里直接得到的印象就是如此。
回复kangax：声明使用标记的widgets的能力所带来的大量好处远超过你的想像，关于在许多讨论中认为Dijit完全占优的问题，在我们的Dojo论坛里有说明。回复Hank：的确如此，我们知道这一点，我们正努力改变文档缺乏这一状况。每个软件共享项目都会遇到这个问题：花所有时间去写出整洁漂亮的代码却不想花时间为它写任何文档。不过新的API文档即将发布(http://redesign.dojotoolkit.org 在我们解决这些问题前，这是一个临时页面)，并且，我们一直在构建一些周边的图标，我们必须做这些事，这将使得文档更容易理解。

Darby Flanagan（译注：这个似乎也是Dojo官方人员）
我在Lotusphere 2007年会上介绍过dojo工具包。我可能和你们大多数人一样不是一个资深的开发人员，但是我必须承认把dojo和我们为Lotus Notes/Domino定制的portal应用整合在一起非常容易。
我正在给所有我们IBM Domino Web开发者洗脑，让他逐渐地接受Dojo工具包所带来的好处。
我唯一不满意的就是文档。
但是我们会面对它，直到彻底被冲入下水道……(译注：后面略了全是blabla的空话)

Randy：
回复r：Prototype 现在也有那种链串式的语法结构了。示例如下：
$(’tab’).hide().addClassName(’something’).update(’inner text is neat’);

steve heron：
有能提供一个“high-profile, high-traffic”网站使用dojo的案例吗。他们广泛采用dojo widgets的情况。我正在做这方面 的评估。

Albert:
我以前在各种项目中用过dojo (0.4)，并且最终决定弃用dojo，主要是两个原因所致：
1、文档太糟糕了
2、性能糟糕。使用一个简单的组件需要下载巨量的js文件让页加载速度非常缓慢。
可能新版本功能会好些吧。

Dylan Schiemann：
回复Albert：那正好是Dojo 0.9所要解决的问题，请看 http://ajaxian.com/archives/dojo-09-the-next-generation-is-here
回复steve：太多了，bloglines.com、renkoo.com、aol的web mail beta版、aim页面、apple的店辅。我认为Dojo 0.9的大小和性能已经有了更大的改善，这不应该再做为讨论的重点。

Jesse Kuhnert：
回复Dylan:还有ebay的shopping.com。

Brad Neuberg：
鉴于Dojo文档的问题， 我提供了一个高质量的文档，这是关于Dojo offline功能部分的。关于Dojo Offline功能参考我拥有完整的操作指南。
http://docs.google.com/View?docid=dhkhksk4_8gdp9gr
希望既能帮助新用户，也能给想钻研的开发者提供许多先进用法。

r：
回复tom：感谢回应。问题关键在于我要做什么，对于一个要使用Dojo的新的潜在的开发者而言，要做的第一件事就是不得不下载一个8mb的tar文件，他们会很难容忍这一点。然后需要认真仔细的考虑自己需要什么功能去自己定制。这不是Dojo自身的问题，但是你们在你们站点发布时只发布了一种下载方式。我很喜欢prototype的作法，仅链接一个自身的js文件。对一个技术复杂度跟Dojo一样的项目而言，这种作法非常简单。我想你们能够领会这些意思 (请不要把你们自身置于有20多个不同版本同时下载的那种乱糟糟的情形之下)。
回复randy： 你难道不知道 dojo 已经有链串功能。

rip747：
我在过去曾尝试应用Dojo，它每次都能在加载时让我的浏览器崩溃。
我不用Dojo是因为它太臃肿了。我喜欢用jQuery，因为它非常小，我能通过一些插件去扩展它。
Dojo阵营的这篇文字看起来象一个绝望者，他想将那些被他们抛弃的人重新拉回来，悲哀啊。

Tom Trenka：
回复r: 你提到了0.4子版本的问题，我们会给0.9版只提供一个下载，我完全同意你关于20个版本的想法。
回复rip747: 你有权做出你的个人选择。但是在你还不了解Dojo小组内部的任何情况时请不要妄做评价，比如“看起来象一个绝望者”。

认真的选择一个自己合用的Ajax应用平台比较伤脑筋，因为有太多选择了。随便举几个：Prototype、jQuery、Ext、MochiKit、GWT（Google Web Toolkit）、YUI（Yahoo! UI Library）。初次下手为了评测优劣如果每个JavaScript应用框架都学习一遍成本太高了。还好，Dojo Javascript工具包的官方网站前几天出了篇文章《Why Dojo?》(为什么选择Dojo)。这篇文章由于发表在Dojo官方网站因此其结论可能会受其立场影响，但这并不是最重要的问题，重要的是作者在做结论前对市面上主流的JavaScript应用框架功能特点做了一个完整比较，这些对开发者选择一个合适的框架非常具有参考价值。因此我花了些时间来翻译这篇文章。网络转载本文需要指明出处，传统媒体采用本译文需要先联系本人。

就我个人而言最先接触的是Prototype，做了些简单的Ajax项目后很久没有用了。最近一段时间接触了JQuery，感觉真的很好用。有一种说法说Prototype就像Java，而jQuery就像ruby，可惜我既没碰过Java也对ruby涉猎不深，所以这种感受不强烈。不过不妨碍我喜欢jQuery，除简单小巧易于学习外，我觉的最大的特点应该是jQuery能做到JavaScript代码与html生成页面分离。最近设计的项目全用了这个架构，页面内除了在head标签内嵌入js文件的链接外，看不到一行JavaScript代码，真是酷啊。不过因为没有涉及过其它的框架结构，所以在翻译时会遇到一些问题，如果你发现了请指正。

在翻译的过程中发现了有关《为什么选择Dojo》文章的讨论链接（http://ajaxian.com/archives/why-choose-dojo）。这些讨论中也涉及了很多常用框架的评价，都可以做为第三方的参考意见，同时Dojo官方的开发人员也加入了这场争论当中。这些辩论也非常的精彩，我对部分发言做了翻译整理，会放在《〈为什么选择Dojo〉－兼评测其它主流的JavaScript框架工具包(之二)》中。

＝＝以下是译文＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
译文名：为什么选择Dojo?
原文名：Why Dojo?
原文链接：http://dojotoolkit.org/book/dojo-book-0-9/introduction/why-dojo
作者：alex
翻译：多多小虫(bigqiang)
时间：Fri, 07/06/2007 - 06:39

如今可供选择的JavaScript工具包有很高质量水准的只有几个，另外因质量和完整程度不同的工具包有几百个。在这海量选项中，为什么要选择Dojo呢？

宽度和广度：Dojo是一个“full stack”的应用框架。不是那种把几个不同的源码简单拼凑在一起的组件。Dojo通过提供集成的底层架构和广泛的可选模块允许每个组件构造成一个高质量积木式的可信赖集合。这些组件给普通用户遇到的问题提供了良好的解决方案，他们也很容易调整以满足你的需求。从基于面板的设计到客户端图表、到数据绑定、到久经考验的模块系统，Dojo是一个考虑了众多用户体验的刚性的底层架构。

质量：国际化及易访问的底层架构是通过Dojo“纤维”编织而成。每次击键都会有正确提示。所有组件做为一个粘着的整体契合在一起。每件东西都是可以很容易与CSS一起进行定制。只消稍做调整即可获得一个漂亮整洁的外观变化，以大量的用户体验为基础（这些人不仅有普通用户，还有设计师和开发人员）做了设计和测试，这些都是它的特点。

性能：Dojo被用于每天都有高访问量和高流量的站点上，采用Dojo的构造工具是为什么如此的一个关键原因。Dojo软件包系统很容易管理大规模的UI开发项目以及构建顶部的系统层，可以做出令人吃惊的应用。所有这些无需代码修改。Dojo也把高性能的普通应用实现打包到了它的核心内，并且Dojo0.9版在性能上给予了更多的关注，减少了代码。它是个小巧、紧凑的工具包并且速度飞快。这些特点使Dojo成为扩展和构建的理想平台。

社区：Dojo是一个开源的社区，个人和公司都能走到一起公平竞争，这使得大家在使用这些工具时彼此获益。Dojo工具包的许可协议被设计成尽可能与政治无关保持中立。我们努力工作也是为了确保在遇到棘手的问题时能很容易得以解决。所有开发都是在开放的环境中进行，并且有意识的降低学习门槛。我们不关心你在哪工作或你是否资深，你在社区中的地位由你所参与的工作质量决定。我们正致力于改变那些可能是开源社区贡献者人的观念，并且我们邀请你加入我们，如果你构造一个伟大的产品并且认为你能帮助我们，我们愿意接受你的任何建议。

Dojo 与别的工具包大比拼

这里拿几个经常与Dojo比较的工具包。下面不是完整的比较，而是基于较高层次上的比较，比如功能特点、设计目标等以及这些特点、设计过程、哲学比之于Dojo有何不同。

MochiKit:
MochiKit 是高质量的JavaScript工具包，它书写JavaScript代码类似Python语言风格，并且性能出重。它在封装、命名以及全局名字空间的用法上遵守与Dojo相同的保守主义。它主要由Bob Ippolito 一个人完成，它拥有完善的文档和测试代码，但是不同于 Dojo ，它没有配备一个widget系统或一个广泛的组件集。某些代码在Mochi和Dojo间可以共享（当然是在CLA协议下）。Mochi没有基金支持，并且代码来源无从验证，不过它有很宽松的许可授权限制。

Prototype+Scriptaculous:
他们广泛深入的库函数提供了很多与Dojo核心相同的功能，但关于全局命名空间争议上并不具有Dojo那种保守哲学，他们偏爱短名称用于常用函数甚于其他。他们拥有优秀的开发文档和广泛的社区支持，以及与Ruby On Rails非常好的紧密集成。Scriptaculous 提供了一些控件（自动完成、幻灯片等)，但没有一个 widget 工具箱，而且也不支持轻松构建一个widgets的能力。Prototype+Scriptaculous有很多 add-on 库可利用，但他们没有同库文件一些发布。他们没有打包功能和构造系统功能(除了他们自己的distributables外). Prototype和Scriptaculous没有基金支持，并且代码来源无从验证，不过他们有很宽松的许可限制。
(译注：实在不知道这个打包功能package是个什么功能，姑且这样译吧，后面几处也都一并这样处理。)

YUI:
YUI是Yahoo内部开发的产品，应用广泛，拥有高质量的文档和示例。以速度做为设计标准，目标人群是专业的PHP开发者。YUI以满足Yahoo规模级别的需求为考量来设计。工具包是有用的CSS常化和设计样式表，他所包含的可用控件列表不断增长。无打包系统可用，常用功能“roll up”文件被发布，并且文档说明了装载文件的顺序。无CSS查询或标记驱动的 widget 构造系统可用。 YUI拥有一个活跃的社区和自由的许可协议，但是在项目中不允许外部提交，Yahoo还没有澄清过代码渊源以及其他与工具包有关的知识产权问题。没有从源头控制任意数据种类的访问。YUI在Yahoo的所有CDN上都可边际缓存（edge-cached）。

JQuery:
主要关注DOM结构的操作的最小需求系统。JQuery 特点是其混合了XPath/CSS的查询语言（Dojo使用了标准的CSS 3查询），并且在这些查询结果的基础上提供了一个操作和选项的富集。JQuery 封装 了Ajax、效果(effects)以及别的应用进入一个微核心内(这一点除了MooTools似乎无人可比)。它同样没有 widget或打包系统，有以jQuery以基础的第三方组件库可供应用。JQuery 社区高度活跃，彼此互助，并且接受外部的贡献和开发的补丁。优秀的开发文档很容易得到。JQuery 具有MIT和GPL双重许可的所有版权，版权归John Resig所有。还不清楚这个知识产权以什么条款从别的贡献者那里指定归John所有。有几个框架(特别是Drupal系统)集成了JQuery。

EXT:
类似于Dojo的Dijit系统，EXT是一个组件库，它展示了大量一致的、好看的着重于像素完美布局以及兼容各种浏览器的类似桌面UI的widget。最初开发用于YUI上，后来是JQuery。EXT 现在有它自己的底层库，不再需要依靠第三方。EXT社区也非常活跃，有优秀的文档且容易获取，它的许可授权是依据以LGPL的条款和各种可用的商业授权许可表单为基础的。在这些条款下，无论外部贡献被接受与否其知识产权归属都不明确，并且匿名子版本的访问许可也将受限于在某方面商业上支持该项目的那些人。

GWT:
直接集成了服务器商开发和客户端的开发，GWT接受这样的观点，JavaScript是一个应该被解决的bug，并且使用高级的编译器技术允许开发者用Java写代码，并且产生动态的基于Google UI风格的JavaScript代码。默认的widget集严格来讲是Dijit提供的一个子集，不过GWT在优化所产生的代码上花了很多的心思。add-on 库一直在增长，大大增强了默认的组件功能。与YUI和EXT不同，GWT是一个真正开源运行的项目，允许外部贡献提交。在一个开源的环境进行开发时知识产权管理问题非常复杂(CLAs、code review等。有大量象Apache 或 Dojo的项目)。GWT应用仅能用Java写，并且多是部署在Java容器环境内。它有优秀的文档并且，并且社区也在逐渐成长壮大。

作为比较也列出Dojo：
允许外部贡献提交并且使用CLAs许可(同GWT 和 Apache) 以确保没有知识产权问题。
非常宽松自由的授权许可，提供匿名SVN访问功能给每一个人。Committer privs are earned
提供了一个富客户端的组件集 ，并不强求与任何服务器端语言（协议、无API）紧密绑定。
力求在网线传输大小和常规功能调用间提供一种平衡。Dojo的基础类库大小与Prototype接近。
在不触犯涉及别人的代码以及保留全局命名空间上我们非常保守。
支持在AOL的CDN上进行边际缓存(edge-cached)。
提供了一个打包系统，它可以让你知道在一个未确定的问题中加载的东西是以什么顺序进行的。
允许通过标记增量加强功能，并提供一个非常容易使用的widgett系统，用于构建你自己的可重用组件，它可以通过标记很容易将其实例化。

update(2007-10-7):
1、感谢http://cloudreams.spaces.live.com/的指正。关于EXT的Subversion翻译问题，再次查看了原文，觉的他理解应该是更准确些，我当时可能因这个词首字母是小写的而没有留意，感谢cloudreams。我想“并且匿名子版本的访问许可也将受限于在某方面商业上支持该项目的那些人”这应该译为“并且Subversion匿名访问许可也将受限于在某方面商业上支持该项目的那些人”
2、在重新review本文发现在译到Prototype部分时出现了package，当时不太知道怎么回事。根据一段时间的积累，所谓的Package是这样一种功能：由于一些框架功能太多代码体积庞大，为了更好的减少体积仅把功能相适应的部分加载到对应的页面，某些框架对体系内的代码做了功能拆分，基本上有一个最小功能核，然后有图形部分、特效部分等，把一个庞大体积的框架功能代码分散在多个体积较小的文件当中。为便于开发者选择合适的功能代码，提供了这种打包“package”工具，可以根据你开发中所需要的功能，把相应的代码文件打包在一起。