jQuery非常容易學習，有很杰出的特性，但是當你從插件庫里去找更多的功能時，發現官方的庫里面根本就沒有。插件特性非常好，但是也有很不好的地方……很快你就會被無數個可用的插件弄得暈頭轉向，你需要花很多時間去確定哪些插件才和核心庫的質量相匹配。

因此，我必須首先很輕而易舉地證明：jQuery是***以及有更好表現的框架。他們是***的。John Resig（jQuery的作者）在三天里曾七次說：“Microsoft演示了怎樣把jQuery包含進了它的SDK，出席會議的人也非常肯定地談論了這個框架。這些都清楚地讓我看到：jQuery正在做一些正確的事情。”

我去參加這個會議的一部分任務就是盡可能多地參與jQuery的交流和學習（我曾經也很深入地學習過，但是我希望從開發團隊和John那里學習到更多東西），同時也可以看一下我是否能夠找到這個框架受歡迎的原因。

這里需要一些解釋。MooTools團隊從來沒有真正關注過這個框架有多受歡迎。我們只是對寫這個框架感興趣，為我們自己使用和它本身目的去寫，但是我們真的沒有花很多精力去讓其他人去使用這個框架。我們從不認為其它框架是我們的競爭對手——因為我曾經在很多場合都聽說過這樣的話，我們在和瀏覽器進行斗爭，而不是相互斗爭。在我的這篇文章中，我給你們的建議是：多嘗試一些選 擇，然后選擇適合你的需求和你的風格的框架。你真的不能做一個壞的選擇（因此，請停止爭吵！）。jQuery、Prototype、YUI、Dojo、 MooTools——我們都只是用不同的方法在做同樣的事。關于這一點寫得有點多，因為我最近一直在思考這個。

Bill Scott在繼續教我一些事情

當這個事情還在Boston的時候，我偶然遇見了Bill Scott。Bill是Yahoo的YUI團隊的***，是一個很好的演講者（盡管他在Boston的時候只做了一個關于他當前工作的五分鐘的“閃電演 講”）。一段時間以前，他幫助開始了Rico框架的開發，隨后轉到了YUI。接著在一年前，他離開了Yahoo，去了Netflix，帶領團隊做了許多工 作——不只是JavaScript（更多地關注了他們的新API和用戶體驗）。Netflix也在使用jQuery，因此我有機會和他坐下來談論這些事 情。

在這里我要小心一些，并提醒正在閱讀這篇文章的各位讀者，我沒有任何關于 jQuery的壞話要說，我也不想在這篇文章或者其他文章中挑起一場無謂的爭論。jQuery和MooTools（以及Prototype、Dojo、 YUI等等等等）都是不同的而且沒有相互競爭。它們用不同的方式解決問題，而我，就個人而言，碰巧喜歡Moot解決問題的方式以及它嘗試解決問題的方式。 由于我還在學習jQuery，因此很容易我可能就會寫一些不正確的jQuery語句，如果我有什么說得不正確的地方，還請大家諒解。

編程模式

在和Bill的談話中，我說了我的一些關于“編程模式”的思考。我所謂的“編程模式”是這樣的：當我寫我的代碼的時候，我可以選擇做一個架構師，或者一個代碼編寫者。我可以設計，我也可以實施。事實上，我必須都做，但是我必須選擇我更想做的一個，而且，在許 多情況下，不論是我還是其他人，都可能一個人去完成幾乎所有的工作——盡管不是100%。

我究竟在說些什么？讓我這樣跟你講：如果你寫了20行代碼，來描述一個頁面上的用戶交互，以便使頁面看起來很 漂亮或者很易用，那么它是不是值得再多寫5行或者10行代碼來使其可以被重復使用？如果你只是依據經驗直接編程，那么你需要寫一遍又一遍。但是如果你按照 模式來寫，你要寫的代碼會越來越少。

假設有這樣一個用戶體 驗：當喲哦難怪乎點擊“log in”按鈕的時候，顯示一個登陸框。當用戶點擊“log in”的時候，這個登陸框就出現。用戶提交登陸表單，登陸框發出一個ajax請求并顯示一個提示信息。當請求完成時，這個登陸框告訴用戶已經登陸了并在過 一會兒后消失。

我可以用JavaScript來表現這些，就寫在當前這個頁面上或 者在我的全站代碼里面（可能這個登陸框在每個頁面上都有，是吧？）。它可能是這樣一段代碼（我會在某種程度上省略一些代碼）——注意：我這里使用的是MooTools的語法，不過它看起來和現在的大多數框架都差不多，因為我們都相互借鑒好的點子：

window.addEvent('domready', function(){  
     $('loginLink').addEvent('click', function(e){  
         e.stop(); //don't follow the link  
         $('loginPopup').show();  
     });  
     //loginPopup contains loginForm  
     $('loginForm').addEvent('submit', function(e){  
         e.stop(); //don't submit the form  
         $('loginForm').send({  
             onComplete: function(result) {  
                 $('loginPopup').set('html', result); //show the result  
                 (function(){  
                     $('loginPopup').hide();  
                 }.delay(1000)); //wait a sec, then hide the popup  
             }  
         })  
     });  
}); 

美麗的直接了當，是吧？但是我們退后一步，然后問我們自己：這是什么模式呢？我們能再看到它的一部分嗎？當然，一個彈出層包含一個form，然后提交、更新自己，然后做一些其它事情，而且可以再次出現。是吧？

這就是我所說的“編程模式”。在我以前的代碼中，我 可能像上面的那樣寫代碼。如果它是我的網站的一部分，我可能有一個名字空間（namespace）并且給它們一個叫做“showLogin”的方法，然后 在on domready事件中調用mySite.showLogin。或者，更可能是這樣子的，我的網站需要很多這樣的方法。showLogin、 logOut、makeToolTips、autoScroll、setupDraggers等等。然后我會寫一個叫做mySite.init的方法來調 用所有的這些方法。

但是在回頭看看我的老代碼，我可能有一個巨大的domready方法，里面包括了所有的這些布局和交互的指令，一個很大的啟動方法。

如果你從來沒有寫過這樣的代碼，你永遠也不會知道維護這個代碼的樂 趣。它會花費大量的精力去理解在***件事情之后該是什么事情。再回頭看看上面的示例代碼，想像一下，如果我們遇到了類似的事情，但是有這個的3倍、5倍或 者10倍長，然后再想像一下一年以后我們再次碰到類似的事情。僅僅只是拆分這些行為就已經非常令人可怕了。

現在，讓我們按照模式編程。一個彈出層，有一個form，并且自動更新。這就是我們要重復出現的模式。下面是一個MooTools類，實現了同樣的東西：

 var PopupForm = new Class({  
     Implements: [Events, Options],  
     options: {  
         requestOptions: {/*the user can fill in additional ajax options*/},  
         onComplete: $empty //do nothing on complete by default  
     },  
     initialize: function(link, form, popup, options) {  
         this.form = $(form);  
         this.link = $(link);  
         this.popup = $(popup);  
         this.setOptions(options);  
         this.makeRequest();  
         this.attach();  
     },  
     makeRequest: function(){  
         thisthis.request = this.form.retrieve('send', this.options.requestOptions);  
         this.request.addEvent('complete', function(response){  
             popup.set('html', response);  
             this.fireEvent('complete');  
         }.bind(this));  
     },  
     attach: function(){  
         this.link.addEvent('click', this.show.bind(this));  
         this.form.addEvent('submit', function(e){  
             e.stop();  
             this.request.send();  
         }.bind(this));  
     },  
     show: function(){  
         this.popup.show();  
     },  
     hide: function() {  
         this.popup.hide();  
     }  
}); 

現在，不可否認的是我的類已經有兩倍長了，但是它還仍然沒有與我的登陸鏈接關聯起來。要使其生效，我還需要對它進行初始化：

window.addEvent('domready', function(){  
    new PopupForm($('loginLink'), $('loginForm'), $('loginPopup'), {  
        onComplete: function(){  
            (function(){  
                this.hide();  
            }.delay(1000, this)); //wait a sec, then hide the popup  
        }  
    })  
}); 

#p#

有所取舍，但追求***利益

除了代碼變成了以前的兩倍長以外，我還需要其他的9行代碼去完成這個事情。15行代碼和42行代碼，看起來并不是個好的交易，但是我最近在我的所有代碼里面都是這樣寫的。通過變換到這種思考方式，我從寫很多很多代碼段中解放出來，也節約了很多我以前根本沒有考慮到的時間。

◆代碼現在更加清晰易讀了。我有一些很小的方法，它們只做一件事情，但是我知道它們在做什么以及為什么做。我的類的名字描述了它們要做的事情，而且它們也很小，也只做一件事情。如果我需要一個做兩件事情的類，我會寫兩個類和一個小的控制類來調用它們。

◆代碼可以重復使用——如果這個模式再度出現，我不需要再重復寫這些代碼。我曾經被它們出現的頻率嚇倒。我從來沒有想過要重用一周以內的代碼，但是我現在又開始重新使用他們了。

◆應用程序在哪——我現在正在做的web頁面上，我的代碼一般都很少。我不給頁面單獨寫多少代碼——我所做的只是針對每個給定的頁面元素實例化一些類。這些小的“腳印”（頁面執行時間？）意味這越少的代碼對頁面越好。

◆什么時候需要重構——可能我現在使用的框架已經有新的版本了，或者發現了一個新的瀏覽器bug，或者一個先的瀏覽器沖擊了市場（例如Chrome），或者 我在自己的代碼里面發現了一個bug（這是這幾個原因里面最常見的），我需要立即修正它們。如果我為每個頁面都寫了有代碼，那么我將需要一一修正。從另外 一個方面來說，如果我的頁面只是實例化了我的幾個類，我只需要修改我的類就行了。因為我控制著類的接口，所以我可以完全重寫我的類，而不需要接觸那些實例 化它們的代碼。

◆***，我徹底地改變了我的關于開發用戶體驗的思維方式。我更喜歡開發一個體驗，然后重用它，而不是從頭開始做一個新的。這可以創造一個連貫的體驗，對我而言，意味著更好的用戶體驗。

可擴展性——因為我喜歡調整一些東西

這是這種編碼方式給我代理的***一個大好處，假設你現在寫代碼的方式能夠利用它的可擴展性。 MooTools有一種基于類的層次結構（靈感來源于Dean Edwards的杰出工作），不要被這個名字給欺騙了。盡管它叫做類，實際上就只是一個object工廠，只不過讓JavaScript里面的原型繼承模 型變得更容易跟簡單而已。

你當然不需要MooTools來做這些。JavaScript可以讓你自己來實現。但是由于MooTools底層就是這樣做的，因此很難避免讓你去寫這樣的代碼。寫一個你自己的類真的很容易，擴展一個類也很容易——即使你沒有寫過這個類。

繼續以我們上面提到的彈出表單為例。我們說我們需要一個彈出顯示效果。為了讓其變得有趣一點，我們假設已經有這樣的代碼了，因此我們不想去改變它，但是在這個頁面中，我們想要這個彈出層有淡入淡出的效果，而不僅僅是出現。

MooTools允許你使用任何類（甚至你沒有寫過的類）并擴展成為一個新類。你不需要復制整個類以便添加你的不同代碼——你只需要寫那些你需要添加或者改變的部分就行了。

var PopupForm.Fx = new Class({  
    Extends: PopupForm,  
    show: function(){  
        this.popup.setStyles({  
            opacity: 0,  
            display: 'none'  
        }).tween('opacity', 1);  
    },  
    hide: function(){  
        this.popup.tween('opacity', 0).chain(function(){  
            this.popup.hide();  
        }.bind(this));  
    }  
});  

現在，我 們有一個名字叫做“PopupForm.Fx”的新類了，這個類可以讓彈出層淡入淡出。我們完全沒有改變PopupForm類。另外，即使我們在后面發現 了PopupForm類的某個方法中有一個bug，我們可以在那個地方修正它，這將會修復這兩個類以及所有我們使用了它的地方。

當我用這個方式寫代碼的時候，這意味著我在我工作的每一個頁面、網站和項目 中都添加了一些新的工具到我的工具箱，當到下一個項目時我仍然可以使用。在過去的一兩年里，我已經為MooTools發布了超過70個插件，而這還只是我 認為其他人能夠用到的東西。表單驗證、數據提取以及其他。我還為我自己的項目寫了很多擴展，盡管它們不是很通用，但是在我的動作中并沒有少重用它們。
揭開面紗看看

所有的這一切讓我回到了我真正要說的：我是怎樣看待MooTools以及它與其他框架有什么不一樣。看看jQuery的表現（再次重復：jQuery僅僅只是不同——沒有優劣之分），我認為MooTools和jQuery***的不同在表現的解決方案上。

當和Bill Scott談論他的團隊和他們對jQuery的使用，我詢問了他們對于按模式編程的所做的工作。Bill是相當適合問這個問題的人選，因為他去年花了很長 時間做了一個關于用戶體驗模式和YUI的演講（我強烈推薦這個）。他領導了整個YUI項目模式庫。他是一個一直致力于為重用而創建模式的人。我問了他關于 在jQuery中創建插件的機制，而不是擴展那些插件，坦率地說，這個插件機制對于我來說有一點尷尬（例如，你為了調用一個插件的方法，你必須這樣 寫：jQuery(domId).pluginName(”methodName”, [arg1, arg2]);——我希望我說的是對的——這對于我來說實在是神秘莫測）

在 聽我談完關于MooTools里面的可重用性和可擴展性模式之后，他做了一個很精妙的總結：他對JavaScript非常了解，可以利用 JavaScript本身內置的一些機制來完成他自己的一些方法。換句話說，他用jQuery進行Dom操作、實現特效以及用于一些其他插件，但是當他寫 自己的代碼的時候，他有了自己的類系統（盡管我不確定他用了“類”這個詞——但是本質上有一些工廠去創建這些可重用和可擴展的object）。
JavaScript有它自己的重用方法

這個，坦率地講，是我沒有考慮到的。jQuery在模糊DOM方面做得非常非常的好，使得用戶不再那么頭疼。它使用起來非常簡單而且非常善于表現。作為一個寬泛的框架（即在這個框架中，用戶只是把JavaScript當作一種面向對象語言）的一部分來看，它是很明智的。

但是Bill隨后說的話讓我認真 地思考了在Ajax體驗過程中的參與者。他是這樣說的：“我從來沒有認真地認為其他人不會這么做。”其他人可以使用jQuery（或者其他任何框架，甚至 只是“香草味”的JavaScript）而不利用JavaScript的任何本身特性（包括隱藏的特性）。

這里是三件真正觸動我的事情。這三件真正的大事，對我而言，只會讓我更加偏好MooTools。

#p#

每個人在某些事情上都是一只菜鳥

***件大 事就是：使用框架的許多人（可能不是全部、或者絕大多數甚至只有三分之一——誰知道呢）都不這樣認為。MooTools的用戶，jQuery的用 戶，YUI的用戶，他們只是去寫代碼讓頁面去做他們想做的事情（要說清楚的是：直到今年年初，我用這種方式寫了許多代碼——但是現在我寫的每個東西救護都 是一個類）。這些人為他們能在瀏覽器里做的那些事情感到激動，為他們的網站有多么有趣、強大、流暢、可用等等任何事情而激動。當他們需要重構的時候，這將 會非常的痛苦，不過他們還是很高興——至少比沒有東西好。

我認為現在可以安全地 說，在那些框架中，jQuery讓這中體驗變得非常容易切入。它是如此完整地模糊了瀏覽器，而在很多方面又是如此地像CSS，就像一劑入門毒藥。你做了一 點點，然后你就再也不能停止。如果jQuery沒有完成其他任何東西，只是把JavaScript介紹給那些人然后讓他們堅持使用，這就是個不小的成就。

但是我們最終還是要學習

第二件大事 對我來說變得很明顯，無論遲早，人們越來越熟練地用這種方式寫代碼，當他們寫的時候，他們會想變得更有效率。他們可能不會選擇跟我現在一樣的道路——那些 框架的數目已經說明那里有很多方式去給這只貓上色。但是他們將會度過這樣一個階段：“嗨，你看，我能做一個流暢的Ajax登陸框了！”然后他們會想著去開 始開發一些更加容易重用、容易維護和容易擴展的代碼。在那個時候，他們將會重新閱讀“Crockford的書”，然后反問自己為什么他們不在那里做一些工作呢？

再說一遍，不管你在用什么框架，這都會發生。第1步：學習JavaScript基本語法。第2步：學習利用 框架做一些有趣的效果或者ajax應用。第4步（譯者注：貌似是第3步，不過不必較真）到719步：犯一大堆很愚蠢的錯誤并學習一些東西。第720步：真正掌握JavaScript然后很蔑視地回頭看看你以前的工作。

在框架中，要緊的是它里面的東西

這個，最終，把我帶向了第三件大事。這個事件讓我確定了我對MooTools的選擇。所有的框架都變得日益相似。即有一天他們最終會看起來像這些東西：

fetch(element).verb(details).verb(details).verb(details)  

唯一的真正區別只是他們的術語不一樣。一個框架可能使用$，另外一個可能做同樣的事情，例如Y.get或者jQuery(id)，未來的框架只是使用了同意 的不用詞匯而已。在邊緣，他們都做同樣的事情。這是因為我們都彼此看到了對方工作中好的模式然后加以吸收——再重申一遍，我們全部在和同一個東西做斗爭 ——瀏覽器——為了同樣的目的。

但是在核心深處，他們是各不相同的。這些框架的開發者不會花大量的時間來寫一個讓登陸框變化的代碼。當然，他們為各自的項目完成這樣的工作，這些框架本身的工作在內部進行。 遲早，任何人開始學習其中的一個框架，就會接觸到邊緣代碼，然后就會想去利用核心的代碼。他們會重新閱讀“Crockford的書”并想：“我在用很困難 的方式做這個——我不停地重復太多了，那個東西和我昨天寫的東西幾乎一樣，雖然不完全一樣。那里肯定有更好的方式。”像Bill Scott這樣的人已經在做這些了，但是每個剛剛開始的人還深深地銘記著從屏幕上看到的那些絢麗的東西（當然，他們應該這樣）。

當他們真的夠好并且已經準備好去實施下一步的時候，他們將會看看他們庫的內核來進行選擇。無論開始使用什么框架，在幾個月 之后，他們寫出了代碼，他們會期待那些框架專家的答案，專家們正在寫內核。每個框架都有開發插件和對其進行擴展的機制，我承認我只是在一定程度上熟悉其中 的一部分。我不能對他們給出任何評價除了MooTools，因此我將對那些東西約束我的言論。幾乎所有的MooTools的功能性的東西都是通過擴展本地對象（數組、字符串等）或者類實現的。貫穿整個庫的主要（淺）繼承和重用都通過易讀和易用的方式得到了證明。正是因為如此，我自己的代碼也比以前要好得多了。

為什么MooTools有震撼力

現在，當人們問我為什么我覺得MooTools是更好的選擇，我仍然會告訴他們：不是什么這個框架好于其它框架，所有的框架都是好的選擇，對于我個人而言， 選擇MooTools的原因僅僅只是因為我能最終用語言表現出來一些東西。所有的框架都用不同的方式達到了類似的目的，但是，至少對于我而言，MooTools再一次幫助我解決了我的設計和實現挑戰，這就是我足夠明確的理由。

原文作者：MooTools Team

原文地址： http://techmemo.org/2008/10/06/jquery-mootools-which-is-the-most-popular-and-well-represented-framework-and-what-really-makes-one-framework-different-from-another.html

【編輯推薦】

1. Django創始人：從技術工藝上考量jQuery
2. jQuery讓開發者戀戀不舍的秘密
3. jQuery開發者：你真的需要一個插件嗎？