可扩展性——因为我喜欢调整一些东西
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再一次帮助我解决了我的设计和实现挑战，这就是我足够明确的理由。