轉自：fdream.net/blog
自己一直在用MooTools框架，偶然看見這篇文章，作者是MooTools Team的成員之一，講解了jQuery和MooTools的一點點區別，主要是我覺得他寫JavaScript代碼和他的思維方式很值得學習。另外，對JavaScript的編程思想和對框架的選擇都有很多很好的建議，對於猶豫在各種框架上的人有很好的指導作用，另外對於想深入對框架進行研究或者想自己開發框架的人也有很好的建議。文章雖然很長，但是我覺得不錯，然後就翻譯了。水平有限，文筆粗陋，其中有少數地方自己都覺得翻譯得有些牽強，歡迎批評指正。
由於文章太長，我這裏就分了上下兩篇，下文在這裏：[翻譯]jQuery和MooTools的真正區別（下）
標題：
jQuery, MooTools, which is the most popular and well represented framework and What Really Makes One Framework Different From Another
jQuery和MooTools，哪一個框架更受歡迎有更好的表現以及它們之間的真正區別是什麼
I've been experimenting with several javascript libraries as well… the problem is finding the right mix of features… Ext.js is very extensive, but very large and complex: steep learning curve.
我一直在嘗試一些不同的JavaScript庫，試圖找到一些合適的特性組合：Ext.js非常好擴展，但是太大太複雜，學習難度很大。
jQuery is very easy to learn, has some great features, but soon you start looking in the plugins database for much needed functionality that's missing in the official library. The plugin feature is great, but there's a downside as well… soon you get drowned by the number of available plugins, spending a lot time checking out which ones match the quality of the core library. It's a good thing some plugins get listed on the main site, but still, it takes a great deal of effort to find that right mix. I've been working with Microsoft Ajax library as well, but don't like their control extension framework (which is quite complex).
jQuery非常容易學習，有很傑出的特性，但是當你從插件庫裏去找更多的功能時，發現官方的庫裏面根本就沒有。插件特性非常好，但是也有很不好的地方……很快你就會被無數個可用的插件弄得暈頭轉向，你需要花很多時間去確定哪些插件才和核心庫的質量相匹配。如果主頁上列出了這些插件還好，但是，還是要花費很大的力氣去找到合適的特性組合。我也同時在使用Microsoft Ajax庫，但是不喜歡他們的控件擴展框架（它們實在是太複雜了）。
So, I must first attest that hands down, jQuery was the most popular and well represented framework there. They ruled the roost. John Resig (creator of jQuery) spoke 7 times in 3 days, Microsoft demonstrated how jQuery is included in its SDK, and the crowd attending was definitely there to talk about the framework. More than anything, this made it clear to me that jQuery is doing something right.
因此，我必須首先很輕而易舉地證明：jQuery是最受歡迎以及有更好表現的框架。他們是最好的。John Resig（jQuery的作者）在三天裏曾七次說：“Microsoft演示了怎樣把jQuery包含進了它的SDK，出席會議的人也非常肯定地談論了這個框架。這些都清楚地讓我看到：jQuery正在做一些正確的事情。”
Part of the task I set for myself in attending the conference was to attend as many of these jQuery sessions as I could both to learn as much of jQuery as I could (I have, in the past, dug into it, but I wanted to soak up as much as I could from the development team and John) and also to see if I could pick up on what accounts for the popularity of the framework.
我去參加這個會議的一部分任務就是儘可能多地參與jQuery的交流和學習（我曾經也很深入地學習過，但是我希望從開發團隊和John那裏學習到更多東西），同時也可以看一下我是否能夠找到這個框架受歡迎的原因。
This requires a bit of explanation. The MooTools team (of which I am a part) has never really focused on how popular the framework is. We are interested in writing it for our own use and for its own sake, but we don't really spend much energy trying to convince other people to use it. We don't consider ourselves adversaries to other frameworks - as I've heard it put on numerous recent occassions, we're at war with the browsers, not each other. In my own posts on the topic, my suggestion to people is to try a couple of options and choose the framework that suits your needs and your styles. You really can't make a bad choice (so please stop arguing about it!). jQuery, Prototype. YUI, Dojo, MooTools - we're all doing the same things just using different methods. More on this in a little bit, because I've started to think about this more lately.
這裏需要一些解釋。MooTools團隊（我也是其中之一）從來沒有真正關注過這個框架有多受歡迎。我們只是對寫這個框架感興趣，爲我們自己使用和它本身目的去寫，但是我們真的沒有花很多精力去讓其他人去使用這個框架。我們從不認爲其它框架是我們的競爭對手——因爲我曾經在很多場合都聽說過這樣的話，我們在和瀏覽器進行鬥爭，而不是相互鬥爭。在我的這篇文章中，我給你們的建議是：多嘗試一些選擇，然後選擇適合你的需求和你的風格的框架。你真的不能做一個壞的選擇（因此，請停止爭吵！）。jQuery、Prototype、YUI、Dojo、MooTools——我們都只是用不同的方法在做同樣的事。關於這一點寫得有點多，因爲我最近一直在思考這個。
Bill Scott Continues to Teach Me Things
Bill Scott在繼續教我一些事情
While at the event in Boston, I ran into Bill Scott. Bill worked at Yahoo on the YUI team as their lead evangelist and is a great speaker (though he wasn’t speaking in Boston other than a 5 minute “flash” talk about his current work). Bill helped to start the Rico framework a while back (I hope I don’t mischaracterize this - I don’t really know his history there), and then switched to YUI. Then he left Yahoo about a year ago and moved to Netflix and is leading the team there doing a lot of stuff - not just JavaScript (focused more on their new API and the user experience as a whole). Netflix is using jQuery and I had a chance to sit down and talk to him about that.
當這個事情還在Boston的時候，我偶然遇見了Bill Scott。Bill是Yahoo的YUI團隊的領導者，是一個很好的演講者（儘管他在Boston的時候只做了一個關於他當前工作的五分鐘的“閃電演講”）。一段時間以前，他幫助開始了Rico框架的開發，隨後轉到了YUI。接着在一年前，他離開了Yahoo，去了Netflix，帶領團隊做了許多工作——不只是JavaScript（更多地關注了他們的新API和用戶體驗）。Netflix也在使用jQuery，因此我有機會和他坐下來談論這些事情。
I want to be careful here, and remind anyone reading this that I don’t have anything bad to say about jQuery, and I don’t want to start a flame war on this post or others. jQuery and MooTools (and Prototype and Dojo and YUI, yada, yada, yada) are different and not competing with each other. They solve problems in different ways and I, personally, happen to like the way MooTools solves the problems it tries to solve. It’s way too easy for me to make an incorrect statement about jQuery as I’m still learning it, so please forgive me if I misspeak (er- mistype?) here.
在這裏我要小心一些，並提醒正在閱讀這篇文章的各位讀者，我沒有任何關於jQuery的壞話要說，我也不想在這篇文章或者其他文章中挑起一場無謂的爭論。jQuery和MooTools（以及Prototype、Dojo、YUI等等等等）都是不同的而且沒有相互競爭。它們用不同的方式解決問題，而我，就個人而言，碰巧喜歡Moot解決問題的方式以及它嘗試解決問題的方式。由於我還在學習jQuery，因此很容易我可能就會寫一些不正確的jQuery語句，如果我有什麼說得不正確的地方，還請大家諒解。
Programming to the Pattern
編程模式
So in talking to Bill, I spoke about some of my recent thinking about what I’ve been calling “Programming to the Pattern.” It goes something like this: when I write my code, I can choose to be an architect, or a construction worker. I can design, or I can implement. In reality, I must do both, but I can choose which one I want to do more and, in many ways, it’s possible for me to do almost entirely one or the other - though not 100%.
在和Bill的談話中，我說了我的一些關於“編程模式”的思考。我所謂的“編程模式”是這樣的：當我寫我的代碼的時候，我可以選擇做一個架構師，或者一個代碼編寫者。我可以設計，我也可以實施。事實上，我必須都做，但是我必須選擇我更想做的一個，而且，在許多情況下，不論是我還是其他人，都可能一個人去完成幾乎所有的工作——儘管不是100%。
What the hell am I talking about? Let me put it to you this way: if you write 20 lines of code to describe a user interaction on a page to make it snazzy or easier to use, is it worth writing another 5 or 10 lines to make that code reusable? If you program the experience directly, you’ll always write it again and again. But if you program the pattern, you’ll write less and less.
我究竟在說些什麼？讓我這樣跟你講：如果你寫了20行代碼，來描述一個頁面上的用戶交互，以便使頁面看起來很漂亮或者很易用，那麼它是不是值得再多寫5行或者10行代碼來使其可以被重複使用？如果你只是依據經驗直接編程，那麼你需要寫一遍又一遍。但是如果你按照模式來寫，你要寫的代碼會越來越少。
Consider a user experience where, say, one has a log-in box that shows up when the user clicks “log in.” The user clicks “log in” and the box appears. The user fills out the form and the box displays a spinning indicator while it sends an ajax request. When the response comes back it tells (in the box) the user that they are now logged in and then a moment later it winks out.
假設有這樣一個用戶體驗：當喲哦難怪乎點擊“log in”按鈕的時候，顯示一個登陸框。當用戶點擊“log in”的時候，這個登陸框就出現。用戶提交登陸表單，登陸框發出一個ajax請求並顯示一個提示信息。當請求完成時，這個登陸框告訴用戶已經登陸了並在過一會兒後消失。
I could express this as javascript right on the page or maybe in my site-wide code (presumably the log-in box is on every page, right?). It would look something like this (I’m going to abbreviate this somewhat) - note I’m using MooTools syntax here, but it looks about the same as it would in most frameworks these days, as we all borrow good ideas from each other:
我可以用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
}
})
});
});
Pretty straight forward, right? But what if we take a step back and ask ourselves, what’s this pattern here? Could we ever see a part of it again? Certainly, a popup that contains a form that submits, updates itself and then does something could crop up again. Right?
美麗的直接了當，是吧？但是我們退後一步，然後問我們自己：這是什麼模式呢？我們能再看到它的一部分嗎？當然，一個彈出層包含一個form，然後提交、更新自己，然後做一些其它事情，而且可以再次出現。是吧？
This is what I mean by “Programming the Pattern”. In my old code, I would have maybe written the code above. If it were part of my site, I might have a namespace and named this a method called “showLogin”, then called mySite.showLogin on domready. Or, maybe even more likely, my site would end up with a bunch of methods like this. showLogin, logOut, makeToolTips, autoScroll, setupDraggers, etc. Then I’d have a method called mySite.init that called all these.
這就是我所說的“編程模式”。在我以前的代碼中，我可能像上面的那樣寫代碼。如果它是我的網站的一部分，我可能有一個名字空間（namespace）並且給它們一個叫做“showLogin”的方法，然後在on domready事件中調用mySite.showLogin。或者，更可能是這樣子的，我的網站需要很多這樣的方法。showLogin、logOut、makeToolTips、autoScroll、setupDraggers等等。然後我會寫一個叫做mySite.init的方法來調用所有的這些方法。
But even moving back to my older code I would have just had a giant domready method with all these layout/interaction instructions all in one big startup method.
但是在回頭看看我的老代碼，我可能有一個巨大的domready方法，裏面包括了所有的這些佈局和交互的指令，一個很大的啓動方法。
If you’ve ever had code like this, you’ll know that it’s never, ever fun to maintain. It takes a lot of effort to just understand what you were going after in the first place. Go look at that code example again and imagine encountering something like it that’s 3 or 5 or 10 times longer and imagine encountering it again a year later. Just unraveling the intended behavior can be daunting.
如果你從來沒有寫過這樣的代碼，你永遠也不會知道維護這個代碼的樂趣。它會花費大量的精力去理解在第一件事情之後該是什麼事情。再回頭看看上面的示例代碼，想像一下，如果我們遇到了類似的事情，但是有這個的3倍、5倍或者10倍長，然後再想像一下一年以後我們再次碰到類似的事情。僅僅只是拆分這些行爲就已經非常令人可怕了。
Now, let’s program the pattern. A popup, with a form, that updates itself. That’s a pattern that could totally crop up again. Here’s the same thing as a MooTools class:
現在，讓我們按照模式編程。一個彈出層，有一個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(){
this.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();
}
});
Now, my class is admittedly nearly twice as long, and it still isn’t attached to my login link. To make that work, I have to initialize it:
現在，不可否認的是我的類已經有兩倍長了，但是它還仍然沒有與我的登陸鏈接關聯起來。要使其生效，我還需要對它進行初始化：
參考代碼：
window.addEvent('domready', function(){
new PopupForm($('loginLink'), $('loginForm'), $('loginPopup'), {
onComplete: function(){
(function(){
this.hide();
}.delay(1000, this)); //wait a sec, then hide the popup
}
})
});
Trade-offs, But Big Benefits
有所取捨，但追求最大利益
So in addition to being twice as long, I had to bang out another 9 lines before I was finished. 15 lines vs 42 doesn’t look like a good trade off, but lately this is how I write nearly all my code. Changing to this way of thinking has saved me from writing many, many more lines of code and saved me a lot of time in ways I hadn’t originally considered.
除了代碼變成了以前的兩倍長以外，我還需要其他的9行代碼去完成這個事情。15行代碼和42行代碼，看起來並不是個好的交易，但是我最近在我的所有代碼裏面都是這樣寫的。通過變換到這種思考方式，我從寫很多很多代碼段中解放出來，也節約了很多我以前根本沒有考慮到的時間。
* My code is now far more legible. I have small methods that just do one thing and I know what it’s doing and why. My classes are named things that describe what they do, and the classes themselves are small things that just do one thing. If I need a class that does two things, I write two classe and a small controller class that calls them.
* 我的代碼現在更加清晰易讀了。我有一些很小的方法，它們只做一件事情，但是我知道它們在做什麼以及爲什麼做。我的類的名字描述了它們要做的事情，而且它們也很小，也只做一件事情。如果我需要一個做兩件事情的類，我會寫兩個類和一個小的控制類來調用它們。
* My code is reusable - if the pattern ever comes up again, I don’t have to write it again. I’ve amazed myself in how often this has happened. Stuff I never, ever thought I’d reuse ends up coming back to me in a week and there I am using it again.
* 我的代碼可以重複使用——如果這個模式再度出現，我不需要再重複寫這些代碼。我曾經被它們出現的頻率嚇倒。我從來沒有想過要重用一週以內的代碼，但是我現在又開始重新使用他們了。
* The points where my application - the web page I’m working on at the moment - touches my generic code are very small. I don’t write much code about the pages themselves - all I do is instantiate classes for a given page element. This small footprint means that there’s less code that’s only good for that page.
* 我的應用程序在哪——我現在正在做的web頁面上，我的代碼一般都很少。我不給頁面單獨寫多少代碼——我所做的只是針對每個給定的頁面元素實例化一些類。這些小的“腳印”（頁面執行時間？）意味這越少的代碼對頁面越好。
* When it’s time to refactor - perhaps there’s a new version of the framework I’m using, or a new browser bug is found, or a new browser hits the market (oh, hi chrome), or I find a bug in my own code (which is the most frequent of all these reasons), I have to go fix it. If I’m writing all my code for each page I have to go refactor it everywhere. If, on the other hand, my pages just instantiate my classes, I only have to refactor my classes. Since I control the interface to my classes, I can completely rewrite the class without having to touch the code that instantiates them.
* 什麼時候需要重構——可能我現在使用的框架已經有新的版本了，或者發現了一個新的瀏覽器bug，或者一個先的瀏覽器衝擊了市場（例如Chrome），或者我在自己的代碼裏面發現了一個bug（這是這幾個原因裏面最常見的），我需要立即修正它們。如果我爲每個頁面都寫了有代碼，那麼我將需要一一修正。從另外一個方面來說，如果我的頁面只是實例化了我的幾個類，我只需要修改我的類就行了。因爲我控制着類的接口，所以我可以完全重寫我的類，而不需要接觸那些實例化它們的代碼。
* Finally, I end up changing the way I think about the user experience I develop. I’m much more likely to develop an experience and reuse it than create a new one from scratch. This creates an experience consistency that, to me, means a better user experience.
* 最後，我徹底地改變了我的關於開發用戶體驗的思維方式。我更喜歡開發一個體驗，然後重用它，而不是從頭開始做一個新的。這可以創造一個連貫的體驗，對我而言，意味着更好的用戶體驗。
如果還想看下文，請點擊這裏：[翻譯]jQuery和MooTools的真正區別（下）