看這篇之前，請先看上一篇：[翻譯]jQuery和MooTools的真正區別（上）
Extensibility - Because I Like To Tweak Things
可擴展性——因爲我喜歡調整一些東西
This brings me to the last big benefit that coding this way provides, assuming that you are writing your code in a way that lets you take advantage of it: extensibility. MooTools has a class based hierarchy (inspired by Dean Edwards excellent work), but don’t let the name fool you. It’s called a class but it’s really just an object factory that makes taking advantage of the prototypal inheritance model in JavaScript easier.
這是這種編碼方式給我代理的最後一個大好處，假設你現在寫代碼的方式能夠利用它的可擴展性。MooTools有一種基於類的層次結構（靈感來源於Dean Edwards的傑出工作），不要被這個名字給欺騙了。儘管它叫做類，實際上就只是一個object工廠，只不過讓JavaScript裏面的原型繼承模型變得更容易跟簡單而已。
You don’t need MooTools to do this of course. JavaScript will let you do it yourself. But because this is the way MooTools works from the ground up, it makes it hard to avoid writing your own code this way. Writing your own classes is really easy, and extending a class - even if you didn’t write it - is easy, too.
你當然不需要MooTools來做這些。JavaScript可以讓你自己來實現。但是由於MooTools底層就是這樣做的，因此很難避免讓你去寫這樣的代碼。寫一個你自己的類真的很容易，擴展一個類也很容易——即使你沒有寫過這個類。
Let’s take our FormPopup above. let’s say we want to have the popup appear with an effect. Just to make it interesting, lets say that there is already code out there using it, so we don’t want to alter it, but for the page we’re on, we want the popup to fade in and fade out rather than just appear.
繼續以我們上面提到的彈出表單爲例。我們說我們需要一個彈出顯示效果。爲了讓其變得有趣一點，我們假設已經有這樣的代碼了，因此我們不想去改變它，但是在這個頁面中，我們想要這個彈出層有淡入淡出的效果，而不僅僅是出現。
MooTools lets you take any class (even the ones you didn’t write) and extend them into new classes. You don’t need to duplicate the whole class to add your differences - you only write the part you want to add or change.
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));
- }
- });
Now we have a new class called PopupForm.Fx that will fade the popup in and out. We haven’t changed PopupForm at all. What’s more, if we later find a bug in one of PopupForm’s methods, we can fix it in that one place and it’s fixed for both classes AND all the places we use it.
現在，我們有一個名字叫做“PopupForm.Fx”的新類了，這個類可以讓彈出層淡入淡出。我們完全沒有改變PopupForm類。另外，即使我們在後面發現了PopupForm類的某個方法中有一個bug，我們可以在那個地方修正它，這將會修復這兩個類以及所有我們使用了它的地方。
When I write my code this way, it means that every page, site, and project I work on I add a few more tools to my toolbox when I go to the next project. I’ve released over 70 plugins for MooTools in the last year or two, and this is just the code that I thought other people could use. Form validators, date pickers, and more. I’ve written many more extensions for my own projects that aren’t so generic, but they are no less reusable for my own work.
當我用這個方式寫代碼的時候，這意味着我在我工作的每一個頁面、網站和項目中都添加了一些新的工具到我的工具箱，當到下一個項目時我仍然可以使用。在過去的一兩年裏，我已經爲MooTools發佈了超過70個插件，而這還只是我認爲其他人能夠用到的東西。表單驗證、數據提取以及其他。我還爲我自己的項目寫了很多擴展，儘管它們不是很通用，但是在我的動作中並沒有少重用它們。
Looking Under the Hood
揭開面紗看看
All this brings me back to what I really wanted to talk about, which is my thinking about MooTools and what makes it different from many other frameworks. Watching the jQuery presentations (again, jQuery is just different - not better or worse), I realized that MooTools and jQuery are very different in the solutions they present.
所有的這一切讓我回到了我真正要說的：我是怎樣看待MooTools以及它與其他框架有什麼不一樣。看看jQuery的表現（再次重複：jQuery僅僅只是不同——沒有優劣之分），我認爲MooTools和jQuery最大的不同在表現的解決方案上。
When talking with Bill Scott about his team and their use of jQuery, I asked him about what they do to program to patterns. Bill’s a great guy to ask about this because he spent a lot of last year giving a great talk about user experience patterns and YUI (I highly recommend it). He lead the project for the whole YUI pattern library. Here’s a guy who is all about creating patterns for reusability. I asked him about working with jQuery, which has mechanisms for creating plugins, but not a way to extend those plugins and, frankly, the plugin mechanism seems a little awkward to me (for instance, if you want to call a plugin method, you must do jQuery(domId).pluginName(”methodName”, [arg1, arg2]); - I hope I have that right - this seems incredibly esoteric to me).
當和Bill Scott談論他的團隊和他們對jQuery的使用，我詢問了他們對於按模式編程的所做的工作。Bill是相當適合問這個問題的人選，因爲他去年花了很長時間做了一個關於用戶體驗模式和YUI的演講（我強烈推薦這個）。他領導了整個YUI項目模式庫。他是一個一直致力於爲重用而創建模式的人。我問了他關於在jQuery中創建插件的機制，而不是擴展那些插件，坦率地說，這個插件機制對於我來說有一點尷尬（例如，你爲了調用一個插件的方法，你必須這樣寫：jQuery(domId).pluginName(”methodName”, [arg1, arg2]);——我希望我說的是對的——這對於我來說實在是神祕莫測）
After hearing me talk about the reusability and extensibility patterns built into MooTools, he made an excellent point: He knows enough about JavaScript to have his own methods for making use of JavaScript’s inheritance mechanisms. In other words, he uses jQuery for DOM manipulation and effects and for some of its plugins, but when he writes his own code, he has his own class system (I don’t think he used the word “class” though - but basically some sort of factory to create reusable and extendable objects).
在聽我談完關於MooTools裏面的可重用性和可擴展性模式之後，他做了一個很精妙的總結：他對JavaScript非常瞭解，可以利用JavaScript本身內置的一些機制來完成他自己的一些方法。換句話說，他用jQuery進行Dom操作、實現特效以及用於一些其他插件，但是當他寫自己的代碼的時候，他有了自己的類系統（儘管我不確定他用了“類”這個詞——但是本質上有一些工廠去創建這些可重用和可擴展的object）。
JavaScript Has Its Own Methods For Reuse
JavaScript有它自己的重用方法
This, frankly, was something I hadn’t considered. jQuery is really, really good at obscuring the DOM and its headaches from the user. It’s simple to use and very expressive. Viewed as a part of a broader framework (i.e one in which the user is just making use of JavaScript’s inherent potential as an object oriented language) it makes a lot of sense.
這個，坦率地講，是我沒有考慮到的。jQuery在模糊DOM方面做得非常非常的好，使得用戶不再那麼頭疼。它使用起來非常簡單而且非常善於表現。作爲一個寬泛的框架（即在這個框架中，用戶只是把JavaScript當作一種面嚮對象語言）的一部分來看，它是很明智的。
But then Bill said something else that made me seriously consider the participants in all the talks at the Ajax Experience. He said something to the effect: “But I guess I just never really thought that other people wouldn’t do that.” That other people would use jQuery (or any other Framework, or even just vanilla JavaScript) and NOT make use of JavaScript’s (somewhat hidden) inheritance system.
但是Bill隨後說的話讓我認真地思考了在Ajax體驗過程中的參與者。他是這樣說的：“我從來沒有認真地認爲其他人不會這麼做。”其他人可以使用jQuery（或者其他任何框架，甚至只是“香草味”的JavaScript）而不利用JavaScript的任何本身特性（包括隱藏的特性）。
This is when three things clicked for me. Three really big things that, to me, only reinforce my preference for MooTools.
這裏是三件真正觸動我的事情。這三件真正的大事，對我而言，只會讓我更加偏好MooTools。
Everyone Is a Noob At Something
每個人在某些事情上都是一隻菜鳥
The first big thing was that a lot of people (maybe not all, or a majority, or even a third - who knows) using the frameworks don’t think think this way. MooTools users, jQuery users, YUI users. They just write the code to get the page to do what they want (and to be clear, I wrote a lot of my code this way until earlier this year - now almost everything I write are classes). These people are excited about what they are able to do in the browser and they are excited with how fun/powerful/slick/usable/whatever their sites are. When they need to refactor them, it will be painful, but they are happy non-the-less (again, I am/was one of these people - I’m not talking down).
第一件大事就是：使用框架的許多人（可能不是全部、或者絕大多數甚至只有三分之一——誰知道呢）都不這樣認爲。MooTools的用戶，jQuery的用戶，YUI的用戶，他們只是去寫代碼讓頁面去做他們想做的事情（要說清楚的是：直到今年年初，我用這種方式寫了許多代碼——但是現在我寫的每個東西救護都是一個類）。這些人爲他們能在瀏覽器裏做的那些事情感到激動，爲他們的網站有多麼有趣、強大、流暢、可用等等任何事情而激動。當他們需要重構的時候，這將會非常的痛苦，不過他們還是很高興——至少比沒有東西好（再說一遍：我也是這些人中的一個——我沒有看不起他們的意思）。
I think it’s safe to say that of all the frameworks, jQuery makes this experience easy to get into. It so completely obscures the browser and feels so much like CSS in many ways that it’s like a gateway drug. You do a little, and then you can’t stop. If jQuery has accomplished nothing else, it has introduced a lot of people to JavaScript and got them to stick around. This is no minor accomplishment.
我認爲現在可以安全地說，在那些框架中，jQuery讓這中體驗變得非常容易切入。它是如此完整地模糊了瀏覽器，而在很多方面又是如此地像CSS，就像一劑入門毒藥。你做了一點點，然後你就再也不能停止。如果jQuery沒有完成其他任何東西，只是把JavaScript介紹給那些人然後讓他們堅持使用，這就是個不小的成就。
But We All Learn Eventually
但是我們最終還是要學習
The second big thing that became apparent to me was that sooner or later, people writing this way are going to get really, really good at it, and when they do, they’ll want to be more efficient. They may not take the same road as I’m currently on - the number of frameworks out there illustrate that there are a lot of ways to skin this cat. But they will get past the “hey look, I can make a slick ajax login box” phase and will want to start developing code that’s easier to reuse, maintain, and extend. That’s when they’ll re-read Crockford’s book and ask themselves why they aren’t doing some of the stuff in there.
第二件大事對我來說變得很明顯，無論遲早，人們越來越熟練地用這種方式寫代碼，當他們寫的時候，他們會想變得更有效率。他們可能不會選擇跟我現在一樣的道路——那些框架的數目已經說明那裏有很多方式去給這隻貓上色。但是他們將會度過這樣一個階段：“嗨，你看，我能做一個流暢的Ajax登陸框了！”然後他們會想着去開始開發一些更加容易重用、容易維護和容易擴展的代碼。在那個時候，他們將會重新閱讀“Crockford的書”，然後反問自己爲什麼他們不在那裏做一些工作呢？
Again, regardless of which framework they are using, this is going to happen. Step one: learn javascript syntax basics. Step two: learn to do some fun effects/ajax with a framework. Step four through seven hundred and nineteen: make a bunch of stupid mistakes and learn some stuff the hard way. Step seven hundred and twenty: get really good at JavaScript and look back on your previous work with disdain. This is the way of all programming experience, am I right people? (Hey, afford me one generalizing, sweeping statement about all programming languages, ok?)
再說一遍，不管你在用什麼框架，這都會發生。第1步：學習JavaScript基本語法。第2步：學習利用框架做一些有趣的效果或者ajax應用。第4步（譯者注：貌似是第3步，不過不必較真）到719步：犯一大堆很愚蠢的錯誤並學習一些東西。第720步：真正掌握JavaScript然後很蔑視地回頭看看你以前的工作。這是所有的編程經驗，我是對的嗎？（嘿，感謝我用一句通用的全面的話概括了所有的編程語言吧！）
With Frameworks, What Matters Is Hidden Deep Inside
在框架中，要緊的是它裏面的東西
And this, finally, led me to the third big thing. The thing that reaffirms my choice of MooTools. All the frameworks out there are increasingly becoming very similar to each other at the edges. I.E. they all eventually look something like this:
這個，最終，把我帶向了第三件大事。這個事件讓我確定了我對MooTools的選擇。所有的框架都變得日益相似。即有一天他們最終會看起來像這些東西：
- fetch(element).verb(details).verb(details).verb(details)
The only real difference is terminology. One framework might use $, another might do something like, oh, Y.get, or jQuery(id), followed by different verbs that are synonymous with the next framework. At the edges, they all do the same thing. This is because we all see good patterns in each others’ work and incorporate it - again, we’re all working against the same thing - the browsers - for the same purpose.
唯一的真正區別只是他們的術語不一樣。一個框架可能使用$，另外一個可能做同樣的事情，例如Y.get或者jQuery(id)，未來的框架只是使用了同意的不用詞彙而已。在邊緣，他們都做同樣的事情。這是因爲我們都彼此看到了對方工作中好的模式然後加以吸收——再重申一遍，我們全部在和同一個東西做鬥爭——瀏覽器——爲了同樣的目的。
But where they are different is deep down in the core. The developers of these frameworks don’t spent their days writing code to animate login boxes. Sure, they write that stuff for their own projects, but the framework work itself is down inside. Sooner or later, anyone starting out learning one of these frameworks is going to get to a point where writing code at the edges are going to want to start making use of the mojo down in the core. They are going to re-read Crockford’s book and think, “I am going about this the hard way - I’m repeating myself too much, and that thing I wrote today was almost, but not quite, identical to the thing I wrote yesterday. There has to be a better way.” People like Bill Scott are already doing this, but everyone just getting started are still impressed by seeing something bounce on the screen (as well they should be).
但是在覈心深處，他們是各不相同的。這些框架的開發者不會花大量的時間來寫一個讓登陸框變化的代碼。當然，他們爲各自的項目完成這樣的工作，這些框架本身的工作在內部進行。遲早，任何人開始學習其中的一個框架，就會接觸到邊緣代碼，然後就會想去利用核心的代碼。他們會重新閱讀“Crockford的書”並想：“我在用很困難的方式做這個——我不停地重複太多了，那個東西和我昨天寫的東西幾乎一樣，雖然不完全一樣。那裏肯定有更好的方式。”像Bill Scott這樣的人已經在做這些了，但是每個剛剛開始的人還深深地銘記着從屏幕上看到的那些絢麗的東西（當然，他們應該這樣）。
When they get really good and are ready to take that next step, they will look to the core of their library of choice for guidance. After spending months grinding out code with whatever framework they started with, they’ll look to the experts of that framework for answers, and the experts are writing the core. Every framework has a mechanism for writing plugins and extending them and I will admit that I am only familiar with a few of them in a cursory manner. I cannot pass judgement on any of them save MooTools, so I’ll limit my pronouncements to that. Nearly all of the functionality in MooTools is implemented as extensions to native objects (arrays, strings, etc) and classes. Throughout the library the principals of (shallow) inheritance and reuse are illustrated in an easy to read and easy to use manner. It is because of this that my own code has gotten so much better than it used to be (and I’m a contributor! - don’t hold that against the framework, please).
當他們真的夠好並且已經準備好去實施下一步的時候，他們將會看看他們庫的內核來進行選擇。無論開始使用什麼框架，在幾個月之後，他們寫出了代碼，他們會期待那些框架專家的答案，專家們正在寫內核。每個框架都有開發插件和對其進行擴展的機制，我承認我只是在一定程度上熟悉其中的一部分。我不能對他們給出任何評價除了MooTools，因此我將對那些東西約束我的言論。幾乎所有的MooTools的功能性的東西都是通過擴展本地對象（數組、字符串等）或者類實現的。貫穿整個庫的主要（淺）繼承和重用都通過易讀和易用的方式得到了證明。正是因爲如此，我自己的代碼也比以前要好得多了（我也是一個貢獻者！——不要老是對那些框架有偏見）。
Why MooTools Rocks (At Least, Why I Think It Does)
爲什麼MooTools有震撼力（至少，我爲什麼這麼認爲）
So now, when people ask me why I think MooTools is the better choice, I’ll still tell them that it’s not about what’s better than the next one, and that all the frameworks are good choices, but the reason that I, personally, prefer MooTools is finally something I can put into words. All the frameworks achieve similar goals in different ways, but, for me at least, MooTools helps me solve my design and implementation challenges once, which is definitely good enough reason for me.
現在，當人們問我爲什麼我覺得MooTools是更好的選擇，我仍然會告訴他們：不是什麼這個框架好於其它框架，所有的框架都是好的選擇，對於我個人而言，選擇MooTools的原因僅僅只是因爲我能最終用語言表現出來一些東西。所有的框架都用不同的方式達到了類似的目的，但是，至少對於我而言，MooTools再一次幫助我解決了我的設計和實現挑戰，這就是我足夠明確的理由。
上一篇：[翻譯]jQuery和MooTools的真正區別（上）