Nicholas C. Zakas vs John Resig 一場關於YUI3/jQuery的精彩辯論

原文地址：http://ued.taobao.com/blog/2010/11/06/yui3-vs-jquery/

譯者按：我們時常能看到不同JavaScript庫/架構之間的各種比較，但這次 YUI3 架構師和 jQuery 之父的直接對話卻非常難得，也是暗湧澎湃精彩至極，實在忍不住，翻譯出來以饗各位讀者，希望對那些有志於開發“庫/架構”的同仁們有所啟迪。

jQuery之父回答“YUI3如何提升其影響力？”

原文：http://www.quora.com/How-could-YUI3-improve-its-image-compared-to-jQuery-MooTools-etc/

題目：和jQuery和Mootools相比，YUI3如何提升其影響力？
作者：John Resin(jQuery之父)
譯者：拔赤

YUI3 已經超越 YUI2，並向 jQuery 看齊了，那麼 YUI3 如何提升其影響力呢？關於這個問題，有些回答似乎有些跑題，問題是“怎樣提升 YUI 的影響力”（不錯的問題），然而大部分的回答卻在攻擊 jQuery。

我從兩方面來回答這個問題：1，YUI 應當如何改進，以便更多的人來使用，2，YUI 如何提升才能改善和  jQuery 的競爭力。

我不得不承認，和其他 JS 庫相比，YUI 的確很贊，不管是代碼級的工作、大量優秀的文檔、demos、blog 文章、視頻教程等等，真的相當出色。而其他的 JS 庫則對這些方面不太用心，而且我認為這些內容是一個成功開源項目最重要的組成部分，然而 YUI 卻沒有更成功的佔領市場，對此我一直很不解。

在這裡，為了便於各位理解，我暫作幾個假設：1，目前的 YUI3 版本已經“足夠優秀”，2，YUI 文檔和論壇也已經足夠完善，足以吸引更多的使用者來使用 YUI3。

基於此，我做一些簡短的評價：

1，分散的網域名稱應該合并成一個，正像別人指出的那樣，維護太多網站往往會適得其反、吃力不討好。

2，多程式碼程式庫應當合并成一個程式碼程式庫，不錯，人們仍在使用 YUI2，YUI3 的 API 和 YUI2 卻有著天壤之別，而 YUI 將來只會在 YUI3 上取得成功（YUI 團隊固執的維護著 YUI2 不會協助 YUI “更成功”的）

3，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 沙箱外加 非同步載入指令碼的方法很帥，我非常推薦這種方式。我寧願將My Code段都壓進一個緊湊的 “SimpleYUI” 中，通過他按需從 YUI CDN 上載入指令碼。

我特別希望能重構 YUI 官方網站，讓人們更快的找到他們想要的組件，包括那些社區提供的組件。我會重新定製首頁，讓訪問者一眼就能看到 SimpleYUI，再從 YUI 組件庫中挑選一些很酷的組件放在首頁下方，並直接引導使用者能進入到 YUI Gallery（或者不叫 YUI Gallery，YUI Gallery 聽起來更像是專為 YUI 搞的外掛程式庫）。

所以我們可以看到，YUI 項目本身依然存在著諸多結構性問題。

一直以來，YUI 項目都有著一個龐大的全職全薪的Team Dev，這是 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 的發展和提升其在社區的活力有著非同一般的意義。

如果要給出終極改進方案，我想應該是這兩點：

1，簡單就是美，簡化你的代碼、你的網站、你的文檔、和你組織庫檔案的方式。更簡潔的代碼才能被更多人讀懂、並使用他。

2，開源社區是 YUI 可持續發展的關鍵所在，它會帶來更多的反饋和熱情的開發人員，YUI 的影響力也在開源社區中潛移默化的影響這其中的每個人，Yahoo 不應是其唯一的維護者，維護者應當來自於更廣闊的開源社區。

另外，我注意到這裡很多人的回複都很悲觀，不要忘了，jQuery 的流行才剛剛開始，而 jQuery 和 YUI 幾乎是同時面世（他們分別在06年1月和06年2月發布正式版），jQuery 一直保持著其簡潔易用，所以也擁有數量遠超其他JS架構的開發人員群體。實際上，簡單比複雜更具挑戰，這也一直都是YUI 所不能理解，但最應當反思的問題。

Zakas的回應

原文：http://www.nczonline.net/blog/2010/11/03/response-to-john-resigs-comments-about-yui/

題目：回應 John Resig 關於 YUI 的評論
作者：Nicholas C. Zakas (YUI3 架構師)
譯者：拔赤

就在今早，有人在 Quora [注1]上提了一個問題：“YUI3 如何提升其影響力？”，這個問題很有意思，下面的回複也很有意思。我最感興趣的一個回複來自於 jQuery 的作者 John Resig，他的解讀非常獨到，給出了建立 jQuery 龐大且充滿活力的開源社區的路線圖。只是其中很多觀點我不敢苟同。

在討論之前，應當說明的是，我在 YAHOO 工作，我一直都在為 YUI 貢獻代碼，儘管我不是 YUI Team Dev成員，因此我的觀點不代表 YAHOO 公司和 YUITeam Dev，僅僅是我個人針對 John Resig 回複來分享我的看法。再補充一點，我對 John 本人、jQuery 團隊和 jQuery 社區開發人員們十分敬重，所以，請不要將我的觀點斷章取義，做別有用心的理解。

首先，我承認，分散的網站的確是 YUI 的一個問題，不止一個人曾經糾結於到底應該訪問 YDN 呢還是訪問 YUILibrary.com？這是 YUI 首先要解決的問題。同樣，John 對於簡化 YUI 文檔首頁上的引導資訊的建議也相當不錯，是個好主意。

John 的下一段落介紹了 YUI 如何與 jQuery 正面競爭，我在 twitter 上有過一個簡評：“我不認為他們之間存在你死我活的競爭關係”，我不想將 YUI 搞成另外一個 jQuery，這兩個庫各自都有優點，且重合度極小。jQuery 更適合小網站使用，畢竟它很簡單、福士、人人都可以快速上手，因此 jQuery 有著龐大的設計師群體，但我不願意拿 jQuery 來搭建 Yahoo 首頁。對於可擴充的 web 應用，YUI 的確更勝一籌。我不相信僅憑一個單一的產品就能滿足所有使用者多樣化的需求。jQuery 在其專註的方面的確富有想象力，而我寧願將 YUI 的關注點放在解決複雜 web 應用方面的問題。

我對 John 的評論有如下觀點不敢苟同：

“一直以來，YUI 項目都有著一個龐大的全職全薪的Team Dev，這是 YUI 專屬的優勢，這讓其他 JavaScript 庫項目非常垂涎。我想說，這實在是不賴，正是因為此，才讓 YUI 整體受益匪淺。不過它也帶來一些很嚴重的後果，YUI 的命運掌控在 YAHOO 的手中。這不是我們希望看到的，因為 YUI 自身獨立、開源的特性，YUI 應當從 YAHOO 剝離出來獨闖江湖。”

這種觀點我聽的耳朵都起繭子了，這些觀點是我始終不理解和不認同的，開源社區似乎始終流傳著這種觀點，認為只有“純粹自治”，而非依賴於某個公司的項目才是真正的“開源”。讓我摘錄我之前的一段聊天記錄：

某某：我非常喜歡 YUI，只是那個讓人討厭的 “Y” 讓我很不爽
我說：到底是什麼讓你很不爽？是那些拿著雅虎俸祿的全職工程師？還是你看不慣他們在擁有全球最高訪問量之一的 YAHOO 網站上做 YUI 的各種測試？

我認為，正是得益於雅虎的庇佑，YUI 才如此價值連城。YUI Team Dev和 YAHOO 的其他研發團隊並肩戰鬥，正是這種經曆造就了如今的堅不可摧的 YUI 產品。就在不久前，我剛剛和 YUI 團隊的工程師們一起，將 YUI3 實驗性的應用到 YAHOO 首頁。有多少 JS 庫敢說自己能有機會在全球 top5 的網站上進行測試？又有多少 JS 庫敢說自己能持續從全球流量最大的網站獲得測試資料，這些網站每天的訪問量達億次以上？

將 YUI 從 Yahoo 剝離出來，才真正剝奪了它的戰略優勢。當 YUI 專註於這些高端項目和某些私人項目的時候，就沒辦法同時顧及到那些開源社區了。而在 Yahoo 內部，我們可以與 YUI 團隊協作無間、齊力斷金，所有 YUI 的使用者也都從中獲益良多。所有雅虎工程師的辛勤勞作在這裡匯聚，日積月累的向 YUI 注入能量。

有些人說 Yahoo 不應當“操縱” YUI 的命運，這種論調我就更不能認同了。同樣，是 Yahoo 讓 YUI 閃光。任何一個開源項目都有一個核心的Team Dev，他們的工作除了維護項目源碼之外，還負責培養開發人員、並為他們提供學習路線圖。雅虎為YUI的開發人員們支付薪水，這並不能改變項目的本質。我們可以看看在類似機制下亦然如此成功的 Mozilla，Mozilla 核心研發團隊控制著 Firefox 的版本發布，Mozilla 給他們支付薪水，並不意味著他們的產品就應該有多糟糕。他們的產品 Firefox 是世界第二大瀏覽器，而正是這些甘於奉獻的工程師對這個產品充滿熱情，他們的確渴望創造一個最好的產品。當你的本職工作就是在支援這個項目的時候，這是很容易做到的。誰說大公司無法支援開源項目？開源社區生態系統的形成，最終是由溝通、協作和不斷超越的精神決定的，而不是所謂的“非盈利”。

再回過頭來看 YUI，YUI Team Dev一直都在非常用心的開發第三方組件庫，不錯，這避免不了成長中的煩惱。時至今日 YUI 已經成果斐然，當然，在雅虎的之外，YUI 還未像 jQuery 那樣廣受關注，但 YUI 一直都在努力。去年的 YUI 年會 [注2]上，Matt Snider（曾供職於Mint.com）介紹了由他主導開發的一個相當完備的基於YUI2的組件庫。我覺得這實在是棒極了，因為他的行為傳達了一個訊號，任何人只要有自己的想法，都可以向 YUI Team Dev靠攏，而且可以得到 YUI 團隊的絕對支援，並把你的組件打包入 YUI。Matt 為他的組件庫付出了很多工作，希望 YUI 可以尋覓到更多像他那樣的開發人員，願意花時間為 YUI 貢獻高品質的代碼。同樣，YUI Gallery 也一個相當不錯的東西：他為開發人員開啟一扇大門，開發人員可以輕鬆的將他們的組件發布到 Gallery 列表中，並可以將它們推送到 YAHOO 的 CDN 上[注3]。至今，Gallery 已經有227個組件，讓非雅虎系的開發人員都受益良多。

那麼，YUI 是否可以改進社區的形式和貢獻代碼的模式呢？當然可以。YUI 是不是必須切斷和 Yahoo 的聯絡，才能開始這些改進？不用，YUI3 是一個高品質的產品，在不斷壯大的開源社區中有著強勁的生命力，如果硬要指責 YUI 團隊的不稱職的話，也只是他們忽視了市場營銷的重要性，和缺乏行之有效推廣手段，而這兩方面正是  jQuery 的強項，這也是 YUI 需要向 jQuery 學習的地方。

總之，YUI 不是 jQuery，任何試圖將 YUI jQuery 化的企圖都是不對的。那是不是意味著他們二者就是方枘圓鑿、不容水火？絕對不是，jQuery 擁有著全球最大的開發人員群體，沒有哪個開源項目敢說自己不想要一個 jQuery 那樣的開發人員群體。YUI 也是其中之一，只是 YUI 沒必要一定要變成像 jQuery 那樣讓全球開發人員趨之若鶩，更沒必要一腳把雅虎踹開，jQuery 僅僅是一個案例，它給了我們如何經營開源社區的一個參照樣本，就像我常對我同事說的，問題不只有一種解決方案，真正的挑戰性來自於選擇適當的策略(而非照抄)來解決特定情境下的問題。如果真的沿著 jQuery 走過的腳印一步一步走下去，對 YUI 來說，這將是一個嚴重的決策性錯誤，畢竟，他們二者殊途不同歸，各有各的優勢，各自都有特定的開發人員群體。YUI將會堅持走自己的道路，儘管這離不開孕育滋養它的紫色土壤。但我相信，YUI 一定能做到。

注1：Quora.com 是一款基於問答機制的 SNS，有著活躍的使用者群，它和之前的問答網站的最大區別就是 Auora 是基於實名制。
注2：YUIConf 是 YUI 開發人員大會簡稱，一年一次，今年將在11月8日舉辦，可通過 YUIblog 獲得更多資訊。
注3：我相信 zakas 的初衷是好的，但就我個人的經驗來看，將組件發布到Gallery中的確很簡單，但推送到 Yahoo CDN 上就有點費勁了，手續實在有點小麻煩