jQuery和MooTools的真正区别
引言
自己一直在用MooTools框架， 偶然看见这篇文章，作者是MooTools Team的成员之一，讲解了jQuery和MooTools的一点点区别，主要是我觉得他写JavaScript代码和他的思维方式很值得学习。另外，对 JavaScript的编程思想和对框架的选择都有很多很好的建议，对于犹豫在各种框架上的人有很好的指导作用，另外对于想深入对框架进行研究或者想自己 开发框架的人也有很好的建议。文章虽然很长，但是我觉得不错，然后就翻译了。水平有限，文笔粗陋，其中有少数地方自己都觉得翻译得有些牵强，欢迎批评指 正。
译者：Fdream
译者博客：Fdream's Blog
标题：
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.
* 最后，我彻底地改变了我的关于开发用户体验的思维方式。我更喜欢开发一个体验，然后重用它，而不是从头开始做一个新的。这可以创造一个连贯的体验，对我而言，意味着更好的用户体验。