译者按：我们时常能看到不同JavaScript库/框架之间的各种比较，但这次 YUI3 架构师和 jQuery 之父的直接对话却非常难得，也是暗涌澎湃精彩至极，实在忍不住，翻译出来以飨各位读者，希望对那些有志于开发“库/框架”的同仁们有所启迪。
- 题目：和jQuery和Mootools相比，YUI3如何提升其影响力？
- 作者：John Resin(jQuery之父)
- 译者：拔赤
- 原文：http://www.quora.com/How-could-YUI3-improve-its-image-compared-to-jQuery-MooTools-etc/
YUI3 已经超越 YUI2，并向 jQuery 看齐了，那么 YUI3 如何提升其影响力呢？关于这个问题，有些回答似乎有些跑题，问题是“怎样提升 YUI 的影响力”（不错的问题），然而大部分的回答却在攻击 jQuery。
我从两方面来回答这个问题：1，YUI 应当如何改进，以便更多的人来使用，2，YUI 如何提升才能改善和 jQuery 的竞争力。
我不得不承认，和其他 JS 库相比，YUI 的确很赞，不管是代码级的工作、大量优秀的文档、demos、blog 文章、视频教程等等，真的相当出色。而其他的 JS 库则对这些方面不太用心，而且我认为这些内容是一个成功开源项目最重要的组成部分，然而 YUI 却没有更成功的占领市场，对此我一直很不解。
在这里，为了便于各位理解，我暂作几个假设：1，目前的 YUI3 版本已经“足够优秀”，2，YUI 文档和论坛也已经足够完善，足以吸引更多的用户来使用 YUI3。
基于此，我做一些简短的评价：
- 分散的域名应该合并成一个，正像别人指出的那样，维护太多站点往往会适得其反、吃力不讨好。
- 多代码库应当合并成一个代码库，不错，人们仍在使用 YUI2，YUI3 的 API 和 YUI2 却有着天壤之别，而 YUI 将来只会在 YUI3 上取得成功（YUI 团队固执的维护着 YUI2 不会帮助 YUI “更成功”的）
- YUI 的引入方式太多，应当缩减至一种。人们应当从 YUI().use 开始接触 YUI（假设这些人真想深入使用 YUI）。首页只保留一个要点即可：应当这样来引入 YUI，<script src="http://yuilibrary.com/yui-min.js"></script>，这样就清晰了很多。
简单讲，YUI 项目应当保留一个整体的方向性，重点太分散，则会事与愿违。
如今，如果 YUI 直接和 jQuery 进行竞争，YUI 和它的子项目的运作方式都需要做出调整。因为现在的 YUI 项目运作方式与 YAHOO 的工作方法是背道而驰的。鉴于目前的管理方式的极差的操作性，YUI 项目着实是一个不幸的牺牲品。
本来，我们应该使用 SimpleYUI 来启动我们的 YUI 程序。看看 jQuery 吧，它的 API 简洁实用，人们多冲着这些迷人的功能来构建大多数的站点。因此当我们访问 yuilibrary.com 的时候，本应期待只有一种方法来使用 YUI，就是 simpleYUI（这个名字应当换换，换一个更简洁自然的叫法）。
YUI 主站上其实不应该提供 zip 文件，我甚至觉得根本不应当通过定制的方式来下载 YUI 文件。jQuery 官网只提供一份单独的 jQuery 文件，所有用户，包括手机用户都在使用这一个文件。这实在太简单了，文档也很简单，blog 文章同样简单，每个人都可以非常方便无障碍的参与 jQuery 的讨论。
YUI().use 沙箱外加 异步加载脚本的方法很帅，我非常推荐这种方式。我宁愿将我的代码段都压进一个紧凑的 "SimpleYUI" 中，通过他按需从 YUI CDN 上加载脚本。
我特别希望能重构 YUI 官方网站，让人们更快的找到他们想要的组件，包括那些社区提供的组件。我会重新定制首页，让访问者一眼就能看到 SimpleYUI，再从 YUI 组件库中挑选一些很酷的组件放在首页下方，并直接引导用户能进入到 YUI Gallery（或者不叫 YUI Gallery，YUI Gallery 听起来更像是专为 YUI 搞的插件库）。
所以我们可以看到，YUI 项目本身依然存在着诸多结构性问题。
一直以来，YUI 项目都有着一个庞大的全职全薪的开发团队，这是 YUI 独有的优势，这让其他 JavaScript 库项目非常垂涎。我想说，这实在是不赖，正是因为此，才让 YUI 整体受益匪浅。不过它也带来一些很严重的后果，YUI 的命运掌控在 YAHOO 的手中。这不是我们希望看到的，因为YUI自身独立、开源的特性，YUI 应当从 YAHOO 剥离出来独闯江湖。
据我所知，还没有非雅虎的 YUI 社区，很多非雅虎的开发者为 YUI 贡献了很多不错的代码，但他们都没有提交权限，这是一个严重的问题。反观 jQuery 的成功，则很大程度上得益于开发者的反馈和帮助，我们从社区中得到了大量的滋养。现在，让我们来看看我们的代码库和代码贡献模式吧。
将代码迁移到 github 上是漂亮的第一步（因为没有版本控制，项目早晚会死），然而，人们贡献代码的方式十分零散而分散，显然Git作为开放灵活的开源版本控制工具是我们不二的选择（相比于 YAHOO 内部循规蹈矩的版本发布）。而在 yuilibrary.com 上，几乎不可能实际上发起一个类似 pull request 操作，因为他有自己的一套提交代码机制，而且非常容易起冲突。我们需要 Git 能侵入开发者 coding 的各个习惯，拥抱 Git，你才能游刃有余的使用他。
时至今日，YUI 社区最大的问题就是“YUI已经成型”，或者说仅仅是 YAHOO 在为 YUI 贡献代码，而一个真正开源的项目应当具有完整的社区生态系统，只有 Yahoo 停止支持 YUI，社区开发者才能开心放心的搭建 YUI 开发环境，为 YUI 贡献代码，如果这个坎过不去，瓶颈就无法消除，我们应当快刀斩乱麻，从底层结构上修复 YUI 问题的根源。
我们需要建立一个持有 YUI 100%版权的非营利组织，并让非官方的开发者来负责项目的运作，这对 YUI 的发展和提升其在社区的活力有着非同一般的意义。
如果要给出终极改进方案，我想应该是这两点：
- 简单就是美，简化你的代码、你的站点、你的文档、和你组织库文件的方式。更简洁的代码才能被更多人读懂、并使用他。
- 开源社区是 YUI 可持续发展的关键所在，它会带来更多的反馈和热情的开发者，YUI 的影响力也在开源社区中潜移默化的影响这其中的每个人，Yahoo 不应是其唯一的维护者，维护者应当来自于更广阔的开源社区。
另外，我注意到这里很多人的回复都很悲观，不要忘了，jQuery 的流行才刚刚开始，而 jQuery 和 YUI 几乎是同时面世（他们分别在06年1月和06年2月发布正式版），jQuery 一直保持着其简洁易用，所以也拥有数量远超其他JS框架的开发者群体。实际上，简单比复杂更具挑战，这也一直都是YUI 所不能理解，但最应当反思的问题。