折騰過 KISSY 類庫，簡單說幾點：1. 開發 KISSY 之前，淘寶使用的是 YUI2 類庫。但從 2009 年開始，YUI2 在逐步退出歷史舞臺，YUI 團隊的大部分精力都投入到 YUI3 的開發中去了。從當時的情況來看，YUI2 前途堪憂，YUI3 則還不夠成熟，並且 YUI3 的定位（大而全的框架型類庫）不適合淘寶的前臺業務場景（以瀏覽型為主的展現頁面）。2. 我自己是力推 jQuery 的。但由於歷史原因，阿里系對 jQuery 的成見很深，認為其介面太靈活，不利於團隊協作，以及其外掛質量良莠不齊，社群不如 YUI 健壯。2008 年在淘寶前端內部爭辯過 jQuery，可惜我沒堅持，沒推廣成功。3. 但當時不少新人都喜歡 jQuery 的 API 風格，jQuery 社群也發展得越來越好。我自己也是個鐵桿 jQuery API fans. 因為前兩點原因，2009 年在開發 KISSY Editor 時，底層雖然是基於 YUI2 的，但我逐步已經做了很多替換封裝，實現了一個簡易的雜糅了 YUI2 和 jQuery API 風格的底層類庫，這就是 KISSY 的原型。4. 接下來是技術驅動的一段時期，2010 年基於 KISSY core 寫了 Switchable、Suggest 等在淘寶被大量使用的 UI 元件，一下來就推廣開來了。（中間 YUI2 和 KISSY 並存了很長時間）5. KISSY 進一步發展，得益於核心開發成員承玉的加盟。2011 年後，KISSY 從 KISS 的定位，逐步演化成了立足於淘寶、力爭大而全、同時可定製的一個類庫。承玉做的非常不錯，還有龍藏的 Flash 元件等，以及仿 YUI3 Gallery 的元件貢獻模式，這些讓 KISSY 成為了適合淘寶業務的最佳類庫。上面說了這麼多，總結下與樓主的問題相關的幾點：1. 選擇什麼類庫，抑或自己開發，跟團隊的技能傾向有關。如果雅虎和阿里沒關係，或許阿里就不會這麼雅虎味，或許也就不會對 jQuery 有成見，或許現在壓根兒就沒 KISSY 什麼事。2. 類庫的選擇離不開業務場景。如果淘寶不是瀏覽型為主的網站，而是個個頁面都像 GMail 一樣複雜，那也許淘寶選擇的類庫會是 ExtJS 或 Google Closure 或 YUI3 等等。其實淘寶的後臺專案中，還真有不少是用 ExtJS 的。3. 對於商業公司來說，類庫的重點不是基礎模組，而是業務模組。這裡的業務模組包括淘寶的登入註冊等模組，也包括 Switchable、Suggest 等泛業務模組（比如淘寶首頁的搜尋提示，看似是通用的，其實是跟淘寶的業務型別分不開的。YUI2 也有一個 Autocomplete 元件，但其龐大的體積根本不適應淘寶）。4. 類庫的選擇，還跟整個業界的環境和團隊決策者的眼光相關。比如從去年開始，前端社群越來越意識到了開放共榮的重要性，意識到了規範的重要性。CommonJS、AMD 等等，以及 NodeJS 的興起，這一切變化，也在悄然改變著大家的抉擇。這是我開發 SeaJS 的原因。如今，我們有了更好的、更偷懶、同時更靈活的選擇和組合解決方案。任何路都沒什麼錯，關鍵是，要知道自己在哪。
折騰過 KISSY 類庫，簡單說幾點：1. 開發 KISSY 之前，淘寶使用的是 YUI2 類庫。但從 2009 年開始，YUI2 在逐步退出歷史舞臺，YUI 團隊的大部分精力都投入到 YUI3 的開發中去了。從當時的情況來看，YUI2 前途堪憂，YUI3 則還不夠成熟，並且 YUI3 的定位（大而全的框架型類庫）不適合淘寶的前臺業務場景（以瀏覽型為主的展現頁面）。2. 我自己是力推 jQuery 的。但由於歷史原因，阿里系對 jQuery 的成見很深，認為其介面太靈活，不利於團隊協作，以及其外掛質量良莠不齊，社群不如 YUI 健壯。2008 年在淘寶前端內部爭辯過 jQuery，可惜我沒堅持，沒推廣成功。3. 但當時不少新人都喜歡 jQuery 的 API 風格，jQuery 社群也發展得越來越好。我自己也是個鐵桿 jQuery API fans. 因為前兩點原因，2009 年在開發 KISSY Editor 時，底層雖然是基於 YUI2 的，但我逐步已經做了很多替換封裝，實現了一個簡易的雜糅了 YUI2 和 jQuery API 風格的底層類庫，這就是 KISSY 的原型。4. 接下來是技術驅動的一段時期，2010 年基於 KISSY core 寫了 Switchable、Suggest 等在淘寶被大量使用的 UI 元件，一下來就推廣開來了。（中間 YUI2 和 KISSY 並存了很長時間）5. KISSY 進一步發展，得益於核心開發成員承玉的加盟。2011 年後，KISSY 從 KISS 的定位，逐步演化成了立足於淘寶、力爭大而全、同時可定製的一個類庫。承玉做的非常不錯，還有龍藏的 Flash 元件等，以及仿 YUI3 Gallery 的元件貢獻模式，這些讓 KISSY 成為了適合淘寶業務的最佳類庫。上面說了這麼多，總結下與樓主的問題相關的幾點：1. 選擇什麼類庫，抑或自己開發，跟團隊的技能傾向有關。如果雅虎和阿里沒關係，或許阿里就不會這麼雅虎味，或許也就不會對 jQuery 有成見，或許現在壓根兒就沒 KISSY 什麼事。2. 類庫的選擇離不開業務場景。如果淘寶不是瀏覽型為主的網站，而是個個頁面都像 GMail 一樣複雜，那也許淘寶選擇的類庫會是 ExtJS 或 Google Closure 或 YUI3 等等。其實淘寶的後臺專案中，還真有不少是用 ExtJS 的。3. 對於商業公司來說，類庫的重點不是基礎模組，而是業務模組。這裡的業務模組包括淘寶的登入註冊等模組，也包括 Switchable、Suggest 等泛業務模組（比如淘寶首頁的搜尋提示，看似是通用的，其實是跟淘寶的業務型別分不開的。YUI2 也有一個 Autocomplete 元件，但其龐大的體積根本不適應淘寶）。4. 類庫的選擇，還跟整個業界的環境和團隊決策者的眼光相關。比如從去年開始，前端社群越來越意識到了開放共榮的重要性，意識到了規範的重要性。CommonJS、AMD 等等，以及 NodeJS 的興起，這一切變化，也在悄然改變著大家的抉擇。這是我開發 SeaJS 的原因。如今，我們有了更好的、更偷懶、同時更靈活的選擇和組合解決方案。任何路都沒什麼錯，關鍵是，要知道自己在哪。