jQuery vs Mootools - Como escolher ?
Autor: Leonardo Machado | Publicado: 2010-12-07T17:53:00-02:00

Original de Aaron Newton of Clientcide

Tradução e Adaptação Fabio Zendhi Nagao

Correções e Readaptação Leonardo Machado

Atualmente, a maioria das pessoas começando a trabalhar com  JavaScript se deparam com a difícil tarefa de escolher uma biblioteca ou  pelo menos qual delas aprender primeiro. Se você estiver trabalhando  para uma empresa, é bem provável que ela já tenha escolhido um framework para você, de modo que esta  escolha talvez seja discutível. Neste caso, se eles escolheram o MooTools e você está acostumado com jQuery,  então talvez este artigo ainda possa ser interessante para você.
Todo dia no twitter  vejo várias mensagens que resumem a discussão  acima para "MooTools ou  jQuery?". O objetivo deste artigo é ajudá-lo a fazer esta escolha.

Sobre o autor
Eu sou um desenvolvedor do MooTools, trabalho com a MooTools framework, "blogo" sobre MooTools, escrevi o principal tutorial online e o livro sobre MooTools.  Obviamente tenho a perspectiva de algum modo enviesada. Saliento também  que não uso muito jQuery. Se você for um desenvolvedor jQuery e  encontrar alguma má interpretação da minha parte, favor entrar em  contato para me ajudar a retificar o problema. Meu objetivo aqui é ser  útil e correto para as pessoas - não vender uma framework sobre outro.
&nbsp;Sobre o tradutor
Provalvemente um dos usuários mais antigos de MooTools do Brasil. Trabalhou na otimização do sistema de animação da framework, criou vários widgets (iCarousel,  fValidator, iMask, iFisheye  - a maioria  deles já melhorada pela comunidade ou migrada para outras  bibliotecas), trabalha profissionalmente com MooTools tanto em client-side como em server-side.
&nbsp;Objetivo
Ajudá-lo a fazer a escolha entre esses dois frameworks envolve explicar como eles são diferentes. Vou começar dizendo que ambos são excelentes opções. Você não  irá fazer uma má escolha aqui. Ambas os frameworks possuem suas forças e fraquezas, mas, em geral, eles são ótimas escolhas. Existem também outros frameworks dignos  de atenção: Dojo, Prototype, YUI, Ext  e outros são todos ótimas opções. A escolha de qualquer uma delas está  mais relacionada com o seu estilo do que com o que você precisa  realizar. Este artigo é focado em MooTools e jQuery, pois, cada vez  mais, são os dois frameworks que vejo as pessoas considerando. Finalmente, não estou tentando convencer ninguém a trocar um framework  pelo outro. Existem coisas interessantes em ambas sobre as quais você  pode aprender. Saiba um pouco mais da motivação que me levou a escrever  este artigo no artigo do meu blog Clientcide.
&nbsp;Índice Os lemas dizem tudo
A curva de aprendizado e a comunidade
Para que JavaScript é bom             Mais que simplesmente o DOM
Herança com JavaScript
Auto referência

MooTools faz o JavaScript mais divertido
jQuery faz o DOM mais divertido
Qualquer coisa que você fizer, posso fazer melhor
MooTools permite que você faça da sua própria maneira
Encadeamento como um Design pattern
Reutilizando código com a jQuery
Reutilizando código com a MooTools             MooTools e herança
Extendendo e implementando classes

A hora da decisão
Discussão




Estatísticas&nbsp;
 
 Núcleo da jQuery Núcleo da MooTools 
 Tamanho 55.9K 64.3K 
 Recursos   
 Licença MIT &amp; GPL MIT 
 Utilitários para DOM sim sim 
 Animações sim sim 
 Manipulação de eventos sim sim 
 Seletores CSS3 sim (um subgrupo) sim (um subgrupo) 
 AJAX sim sim 
 Extensões nativas (excluindo Element) aproximadamente uma dúzia para Array, Object, e String aproximadamente seis dúzias para Array, Object, String, Function, e Number 
 Herança não suportada diretamente através de jQuery oferecida pelo construtor Class 
 Outras considerações   
 plug-ins centenas de plug-ins não oficiais em um diretório no endereço plug-ins.jquery.com aproximadamente quatro dúzias de plug-ins oficiais disponíveis em mootools.net/more. Muitos outros pela web. Nenhum catálogo consolidado. 
 Biblioteca oficial de UI sim não 
 Dados baseados em informações retiradas de jquery.com, mootools.net e wikipedia.org.
&nbsp;Os lemas dizem tudo
Se você for para o site da jQuery, aqui está o que ele diz no topo da página sobre do que se trata a jQuery:
"jQuery is a fast andconcise JavaScript Library that   simplifies HTML document traversing,event handling, animating, and Ajax   interactions for rapid webdevelopment. jQuery is designed to change the   way that you writeJavaScript."que podemos traduzir:
jQuery é uma bibliotecaJavaScript rápida e concisa  que  simplifica a manipulação do documentoHTML, eventos, animações e   interação AJAX para o desenvolvimento webágil. jQuery é desenhado para   mudar a forma que você escreve JavaScript.... e se você for para a MooTools, isto é o que você vai encontrar:
MooTools is a compact,modular, Object-Oriented JavaScript   framework designed for theintermediate to advanced JavaScript developer.   It allows you to writepowerful, flexible, and cross-browser code with   its elegant, welldocumented, and coherent API.que podemos traduzir:
MooTools é um framework JavaScript compacto, modular,   orientado a objetos e desenhado para os desenvolvedores JavaScript de   nível intermediário para avançado. Ele permite a você escrever códigos   poderosos, flexíveis e cross-browser com a sua elegante, bem documentada   e coerente API.Acho que isto realmente diz tudo. Se você me perguntar (e estou   assumindo que você perguntou), a questão não é sobre qual framework é   melhor ou pior.  É sobre "Qual dessas coisas você deseja fazer?". Esses  dois frameworks  simplesmente não estão tentando fazer a mesma coisa.  Eles se sobrepõem  em funcionalidades  oferecidas, mas não estão  tentando fazer as mesmas coisas.
A auto-definição do jQuery fala sobre HTML, eventos, animações, AJAX e  desenvolvimento web. O MooTools fala sobre orientação a objetos e  escrever códigos poderosos e flexíveis. jQuery aspira "mudar a forma que  você escreve JavaScript" enquanto o MooTools é desenhado para os  desenvolvedores JavaScript de nível intermediário para avançado.
Faz parte dessa consideração a noção de um framework e um toolkit.   MooTools é um framework que tenta implementar JavaScript "da forma que   ele deveria ser" (de acordo  com os autores da MooTools). O objetivo é  implementar uma API que nos  faça sentir o JavaScript e melhore tudo,  não apenas o DOM. jQuery é um  toolkit que oferece uma coleção de  métodos fáceis de utilizar em um sistema auto-contido, desenhado para  fazer o DOM mais agradável. Acontece apenas que o DOM é onde a maioria  das pessoas focam seus esforços quando estão escrevendo JavaScript;  então, em vários casos, jQuery é tudo que você precisa.
A maioria do código que você escreve quando utiliza MooTools continua  parecendo JavaScript. Se você não está interessado em JavaScript como  uma linguagem, então aprender MooTools lhe fará se sentir como um  condenado. Se você estiver interessado em JavaScript e o que o faz  interessante, poderoso e expressivo; então, pessoalmente, acho que  MooTools é uma melhor escolha.
&nbsp;A curva de aprendizado e a comunidade
Primeiramente, jQuery é, de longe, mais fácil de aprender. Ele possui  um estilo quase coloquial que praticamente não parece como programação.  Se tudo que você quer é pegar alguma coisa funcionando rapidamente sem  aprender JavaScript, o jQuery é provavelmente a melhor escolha. Não é  que o MooTools não consiga ajudá-lo a realizar as mesmas coisas, mas vou  admitir que pode ser um pouco mais difícil para novatos em JavaScript  trabalhar com ele. Existe também o fato de que há um bocado de recursos  disponíveis por aí para ajudar você a aprender jQuery - pelo menos mais  que sobre a MooTools.
Se você comparar a comunidade do jQuery (veja Discussion na página da jQuery) e a comunidade do MooTools (irc,  mailing list e o fórum não oficial) você rapidamente perceberá duas coisas:
A comunidade do jQuery é de longe maior (atribuo isso principalmente à facilidade de aprender jQuery, mas também porque...)
Eles promovem a biblioteca mais ativamente.
Se você medir o jQuery e o MooTools sob métricas como: pessoas  utilizando, buscas realizadas no Google, número de livros vendidos,  etc... você verá que jQuery está à frente por uma grande margem de  folga.
Para explicar o porquê que você deve considerar o MooTools, precisarei primeiro falar um pouco sobre o que ambos os frameworks fazem. Em última análise, o framework  que você escolher depende do que você pretende realizar e como você  gosta de programar (talvez até mesmo se você gosta de programar, pelo  menos em JavaScript).
&nbsp;Para quê JavaScript é bom
Parte de fazer esta escolha é perguntar o que você quer fazer com  JavaScript. Vamos considerar o JavaScript simples, crú. Nenhum  framework; apenas JavaScript "velho e  puro". JavaScript lhe oferece  objetos nativos como Strings, Numbers,  Functions, Arrays,  Dates, Regular Expressions entre outros. JavaScript oferece também um modelo de herança - o de alguma forma esotérico modelo chamado herança prototipada  (do qual vou falar um pouco mais adiante). Esses blocos de montar e o  conceito de herança são o pão e a manteiga de qualquer linguagem de  programação e eles não têm absolutamente nada a ver com os navegadores, a  web, CSS ou HTML. Você pode escrever qualquer coisa que queira em  JavaScript. Tic-tac-toe, xadrez, editores de foto, um servidor web,  qualquer coisa. Acontece apenas que 99% de todo código JavaScript pelo  mundo afora roda em navegadores e é por isso que pensamos nele como "A  linguagem de programação para navegadores".
Entender a diferença entre que o navegador, o DOM, é onde vamos  utilizar JavaScript a maioria do tempo e que na verdade JavaScript é uma  linguagem de programação muito robusta e expressiva irá ajudá-lo a  compreender a diferença entre MooTools e jQuery.
&nbsp;&nbsp;Mais que simplesmente o DOM
Se você pensa nas tarefas que desejamos realizar em JavaScript  estritamente como "pegar as coisas em uma página e trabalhar coisas com  elas" então jQuery é provavelmente a melhor escolha. Ele se excede no  oferecimento de um sistema muito expressivo para descrever o  comportamento na página de uma forma que muitas vezes não parece com  programação. Você ainda pode utilizar o JavaScript puro para fazer o que  você precisa fazer, mas se você estiver focado no DOM (mudar  propriedades CSS, animar coisas, procurar conteúdo através de AJAX, etc)  a maioria dessas coisas serão cobertas pelo jQuery e não vão parecer  puro e velho código JavaScript. jQuery oferece ainda alguns métodos que  não estão relacionados com o DOM; por exemplo: ele oferece um mecanismo  para iterar Arrays - $.each(array, fn) - ou, outro exemplo, ele oferece um método para  remover espaços do começo e do final de uma String - $.trim(str).  Mas não existem muitos métodos utilitários deste tipo disponíveis, o  que é bom porque, na maioria dos casos, se você está apenas pegando  coisas do DOM, iterando-as, alterando-as de alguma forma (incluindo  HTML, alterando estilos, adicionando escuta de eventos onclick, onmouseover , etc) você não precisará de muitas outras coisas.
Mas se você pensar no JavaScript sob seu escopo completo, verá que o  jQuery não se foca em outras coisas além do DOM. Esta é uma das razões  pelas quais ele é tão fácil de aprender, mas isso também limita as  formas que ele pode ajudar você a escrever JavaScript. Ele não quer ser  nada além de um sistema de programação sólido para o DOM. Ele não se  preocupa com herança, nem com utilidades básicas de todos os tipos  nativos da linguagem JavaScript, mas ele não precisa. Se você precisar  mexer com Strings, Dates, Regular Expressions, Arrays e Functions, você pode.  Não é tarefa do jQuery ajudar você a fazer isso. O JavaScript puro,  como uma linguagem  está lá aos seus pés. jQuery transforma o DOM no seu  playground, mas o resto do JavaScript não pertence ao seu escopo.
É neste ponto que MooTools é completamente diferente. Ao invés de se  focar exclusivamente no DOM (apesar de, como veremos em instantes, ele  oferecer toda as funcionalidades que o jQuery oferece, mas faz isso de  uma forma muito diferente), MooTools assume como seu escopo a linguagem  inteira. Se jQuery faz do DOM o seu playground, o objetivo da MooTools é  transformar JavaScript no seu playground, e esta é uma das razões pelas quais ele é mais difícil de aprender.
&nbsp;Herança com JavaScript
A linguagem de programação JavaScript tem algumas coisas muito impressionantes. Para iniciantes, ela é uma linguagem funcional,  o que significa que ela trata funções como objetos que podem ser  manipulados como variáveis, assim como qualquer outro objeto - String e  Number por exemplo. Ela foi desenvolvida com esse conceito em mente e  muitos dos métodos e padrões funcionam melhor nela quando você programa  desta forma. É a diferença entre:
 for (var i = 0; i &lt; myArray.length; i++) { /* do stuff */ }e
 myArray.forEach(function(item, index) { /* do stuff */ });JavaScript possui um modelo de herança  que não é único mas é, pelo menos, mais raro em  linguagens de  programação. Ao invés de classes que são definidas e podem ser  derivadas, ela utiliza métodos da herança prototipada.  Isso significa que os objetos herdam diretamente de outros objetos. Se  você procurar uma referência em um objeto que herda de outro objeto, a  linguagem vai procurar por essa propriedade no objeto filho e, se ela  não o encontrar, vai procurar no seu pai. É assim que um método funciona  em um Array []. Quando você escreve:
 [1,2,3].forEach(function(item) { alert(item) }); //this alerts 1 then 2 then 3o método forEach não é uma propriedade do array definido ([1,2,3]),  é uma propriedade do protótipo Array de todos os possíveis array.  Quando você faz uma referência a esse método,  a linguagem procura por  ele no seu array e, como não encontra, ela procura no protótipo Array.  Isso significa que o método forEach não está alocado na  memória para cada array; ele está na memória apenas para o protótipo  Array da qual descendem todos os arrays. Isso é inacreditavelmente  eficiente e ultimamente muito poderoso.
&nbsp;Auto referência
JavaScript possui uma palavra reservada this. É difícil definir de forma sucinta o que this é, mas, por definição, this  é o objeto ao qual o método pertence. Ele permite aos objetos se  referirem a eles mesmos dentro dos seus métodos de forma que não haveria  outros meios de se fazer. Isto se torna importante quando você cria  objetos filhos e tem várias instâncias desse objeto; de qual outra forma  um método de um objeto poderia referenciar a si mesmo? Quando a cópia  do método existe no pai, não no filho, a palavra this permite que essas instâncias se refiram ao seu próprio estado (veja aqui uma descrição muito mais completa sobre a palavra reservada this e outra da Mozilla).
A palavra this permite que objetos que descendam de outros  objetos se auto-referenciem, mas existem casos onde você deseja  referenciar alguma outra coisa através de this.  Isto chama-se binding,  onde você especifica um this diferente para um método. O método each de  um Array permite que você especifique um objeto como segundo parâmetro.  Segue abaixo um exemplo onde você pode querer passar um this diferente  do padrão:
 var ninja = {
&nbsp; &nbsp; weapons: ['katana', 'throwing stars', 'exploding palm technique'],
&nbsp; &nbsp; log: function(message) {
&nbsp; &nbsp; &nbsp; &nbsp; console.log(message);
&nbsp; &nbsp; },
&nbsp; &nbsp; logInventory: function() {
&nbsp; &nbsp; &nbsp; &nbsp; this.weapons.each(function(weapon) {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; //we want "this" to point to ninja...
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; this.log('this ninja can kill with its ' + weapon);
&nbsp; &nbsp; &nbsp; &nbsp; }, this); //so we pass "this" (which is ninja) to Array.each &nbsp;
&nbsp; &nbsp; }
};
ninja.logInventory(); //this ninja can kill with its katana
//this ninja can kill with its throwing stars
//this ninja can kill with its exploding palm techniqueNo exemplo acima, nós amarramos ninja (que é o this dentro de logInventory)  para o método que passamos para o array de forma que podemos nos  referir à propriedade  log do ninja. Se nós não fizéssemos isso, this seria window (dentro de um navegador).
Estes são apenas alguns exemplos do poder e da expressividade que o JavaScript tem a oferecer - herança, auto-referecia, binding  e eficientes propriedades prototipadas. A má notícia é que o JavaScript  puro não oferece este poderio de forma acessível, e é aqui que MooTools  entra. Ele torna esses tipos padrões fáceis e um tanto agradáveis de  utilizar. Você acaba construindo mais códigos abstratos e, a longo  prazo, isto é uma coisa boa - uma coisa poderosa. Aprender como esses  padrões são valiosos, e como utilizá-los de forma correta, exige  esforço, mas o lado bom é que o código que você cria é tanto altamente  reutilizável como fácil de manter. Vou falar sobre esses temas em alguns  minutos.
&nbsp;MooTools faz o JavaScript mais divertido
Porque MooTools se foca em fazer a API do JavaScript mais estável e  coerente, ele é menos focada em oferecer uma interface que "muda a forma  que você escreve JavaScript" e mais em fazer da linguagem como um todo  muito menos frustrante. MooTools tenta ser uma extensão da linguagem  JavaScript. MooTools tenta fazer o JavaScript da forma que ela deveria  ser. Uma parte significante do núcleo da biblioteca é gasta  aumentando-se Function, String, Array, Number, Element e outros  protótipos. Uma outra grande inclusão é uma função chamada Class.
Agora, para muitas pessoas, Class aparenta estar tentando recriar um modelo de herança mais clássico como o encontrado em Java ou C++, mas este não é o caso.  O que a Class  faz é oferecer, para você e para mim, uma forma mais fácil de utilizar e  obter os benefícios do modelo de herança prototipada do JavaScript.  Vale lembrar que estes conceitos não são particulares do MooTools  (outros frameworks oferecem funcionalidades semelhantes), mas  ambos os conceitos não estão presentes no jQuery. O jQuery não oferece  um sistema de herança, nem qualquer melhoria para os objetos nativos  (Function, String, etc). Esta não é uma deficiência do jQuery, uma vez  que os seus autores poderiam facilmente oferecer estas melhorias.  Entretanto, eles desenharam a toolkit com um objetivo diferente  em mente. Onde o MooTools objetiva fazer o JavaScript mais divertido,  jQuery objetiva fazer o DOM mais divertido e os seus desenvolvedores  escolheram limitar seu escopo a essa tarefa.
&nbsp;jQuery faz o DOM mais divertido
E é por isso que jQuery é mais acessível. Ele não exige que você  aprenda JavaScript profundamente. Ele não joga você na profundidade com  herança prototipada, binding, this e protótipos nativos.  Quando você  começa com o jQuery no tutorial oficial, isto é o primeiro exemplo de código jQuery que você vai encontrar:
 window.onload = function() {
&nbsp; &nbsp; alert("welcome");
}e aqui está o terceiro:
 $(document).ready(function() {
&nbsp; &nbsp; $("a").click(function(event) {
&nbsp; &nbsp; &nbsp; &nbsp; alert("Thanks for visiting!");
&nbsp; &nbsp; });
});Se você ler o livro do MooTools ou o MooTools tutorial  (ambos de minha autoria) eles começam de um lugar completamente  diferente. Enquanto você pode avançar e rapidamente aprender sobre  efeitos e DOM, se você quer aprender MooTools, você terá que começar com  coisas como Class, e vou admitir: se você for novo em  programação, ou simplesmente quer fazer alguma coisa funcionar no seu  site sem ter que aprender tudo sobre JavaScript, as chances são de que  jQuery pareça muito mais agradável para você.
Por outro lado, se você quer aprender JavaScript, MooTools é uma  grande forma de fazer isso. Ele implementa um monte de coisas que  JavaScript irá ter (muitos dos métodos Nativos são apenas especificações  do JavaScript 1.8  e além). Se você for familiarizado com programação, especialmente  programação orientado a objetos e programação funcional, MooTools possui  um monte de padrões de desenvolvimento que são muito excitantes e  expressivos.
&nbsp;Qualquer coisa que você fizer, posso fazer melhor
Se você olhar as coisas que jQuery é capaz de fazer, geralmente  existe uma contrapartida equivalente no MooTools. Se você olhar as  coisas que o MooTools consegue fazer, geralmente não existe forma de  realizar usando jQuery porque seu código é voltado apenas ao DOM.  MooTools oferece uma gigantesca funcionalidade a mais que o jQuery, mas  não há nada no jQuery que o impeça de fazer essas coisas. Por exemplo,  jQuery não vem com nenhum tipo de sistema de herança, mas tudo bem. Você  pode, se quiser, utilizar o MooTools Class conjuntamente com jQuery (ou  escrever a sua própria). Existe até um plug-in de herança para jQuery (eu não utilizei, mas assumo que ele ofereça o mesmo tipo de tipo funcionalidade).
Se nós olharmos para o exemplo do jQuery acima:
 $(document).ready(function() {
&nbsp; &nbsp; $("a").click(function(event) {
&nbsp; &nbsp; &nbsp; &nbsp; alert("Thanks for visiting!");
&nbsp; &nbsp; });
});e quiséssemos traduzir para MooTools, teríamos:
 window.addEvent('domready', function() {
&nbsp; &nbsp; $('a').addEvent('click', function(event) {
&nbsp; &nbsp; &nbsp; &nbsp; alert('Thanks for visiting!');
&nbsp; &nbsp; });
});Existem muitas semelhanças, não?
Aqui um exemplo mais complexo do jQuery:
 $(document).ready(function() {
&nbsp; &nbsp; $("#orderedlist li:last").hover(function() {
&nbsp; &nbsp; &nbsp; &nbsp; $(this).addClass("green");
&nbsp; &nbsp; },
&nbsp; &nbsp; function() {
&nbsp; &nbsp; &nbsp; &nbsp; $(this).removeClass("green");
&nbsp; &nbsp; });
});e no MooTools:
 window.addEvent('domready',function() {
&nbsp; &nbsp; $('#orderedlist li:last').addEvents({
&nbsp; &nbsp; &nbsp; &nbsp; mouseenter: function() {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; this.addClass('green');
&nbsp; &nbsp; &nbsp; &nbsp; },
&nbsp; &nbsp; &nbsp; &nbsp; mouseleave: function() {
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; this.removeClass('green');
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; });
});Novamente, muito semelhantes. Posso argumentar que a versão do  MooTools é mais explícita, mas também, devido a este motivo, é mais  longa. Está claro lendo o código do MooTools que estamos adicionando  dois eventos - um para onmouseenter e outro para onmouseleave; enquanto a  versão jQuery é mais concisa, seu método hover  recebe duas funções - a primeira para onmouseenter e a segunda para   onmouseleave. Pessoalmente, gosto do fato de o MooTools ser mais   legível, mas essa é uma observação  muito subjetiva.
Vou dizer que às vezes o código do jQuery se torna muito exotérico  para o meu gosto. Para mim, os métodos nem sempre fazem sentido apenas  com uma breve olhada eu acho difícil de entendê-los. Entretanto, isto é  de alguma forma injusto, uma vez que sou intimamente familiar com  códigos MooTools, então acho fácil de ler MooTools. Mas uma das coisas  que admiro no MooTools é como praticamente todos os nomes de métodos e  classes realmente informam sobre a sua função. Métodos são quase sempre  verbos e deixam poucas dúvidas sobre o que eles fazem. Toda linguagem de  programação requer que você vá à documentação para procurar sobre a  sintaxe quando você codifica - entretanto só estou dizendo que acho a  API do MooTools mais coerente e consistente.
&nbsp;MooTools permite você fazer da sua própria maneira
Mas e se você gosta da sintaxe do jQuery? Uma forma de ilustrar o  poder do MooTools é mostrar como é fácil alterá-lo ao seu gosto. Se nós  quisermos implementar o método hover do jQuery no MooTools, poderíamos  facilmente fazer:
 Element.implement{{
&nbsp; &nbsp; hover : function(enter,leave){
&nbsp; &nbsp; &nbsp; &nbsp; this.addEvents({ mouseenter : enter, mouseleave : leave });
&nbsp; &nbsp; }
});
//and then you could use it exactly like the jQuery version:
$('#orderlist li:last').hover(function(){
&nbsp; &nbsp; &nbsp; &nbsp; this.addClass('green');
&nbsp; &nbsp; },
&nbsp; &nbsp; function(){
&nbsp; &nbsp; &nbsp; &nbsp; this.removeClass('green');
});
De fato, existem plug-ins do MooTools que fazem exatamente isso; oferecem a você a sintaxe do jQuery no MooTools.  O foco do MooTools em extensibilidade significa que você pode  implementar qualquer coisa que você queira. Isto é uma das coisas que o  jQuery não consegue fazer. O MooTools pode imitar o jQuery se quiser,  mas o jQuery não pode imitar o MooTools. Se você quiser escrever  classes, ou extender protótipos nativos, ou fazer alguma outra coisa que  o MooTools consegue fazer, você terá que fazer isso sozinho.
&nbsp;Encadeamento como um Design pattern
Vamos fazer outra dessa. Aqui um pouco de jQuery (do tutorial da jQuery):
 $(document).ready(function() {
&nbsp; &nbsp; $('#faq').find('dd').hide().end().find('dt').click(function() {
&nbsp; &nbsp; &nbsp; &nbsp; $(this).next().slideToggle();
&nbsp; &nbsp; });
});Este é um exemplo de sintaxe que eu não gosto. Olhando para o código  acima, sou fortemente pressionado para ter certeza do que ele está  fazendo. Mais notavelmente, estou curioso sobre o que end faz e como  find, que o segue, está relacionado com o que end  faz. Agora, olhando  para a documentação da jQuery, fica claro o que  .end faz (ele reseta  para o valor original do seletor, neste caso #faq). Mas isso me parece  muito estranho. Quando trabalho com jQuery, geralmente me encontro  incerto sobre o que um método irá me retornar. Claramente isso não  incomoda mais ninguém, pois o jQuery possui um monte de pessoas o  utilizando felizes da vida, então vou novamente assumir isto como uma  preferência pessoal.
Vamos ver a lógica acima com o MooTools:
 window.addEvent('domready', function() {
&nbsp; &nbsp; var faq = $('faq');
&nbsp; &nbsp; faq.getElements('dd').hide();
&nbsp; &nbsp; faq.getElements('dt').addEvent('click', function() {
&nbsp; &nbsp; &nbsp; &nbsp; this.getNext().slide('toggle');
&nbsp; &nbsp; });
});Novamente, o código do MooTools é um pouco mais longo, mas é também  mais explícito. Note também que o padrão de desenvolvimento aqui é  guardar a referência de #faq em uma variável, onde jQuery usa seu método  end para retorná-la. Vou mostrar que é  possível escrever códigos  altamente encadeados em MooTools. Por exemplo:
 item.getElements('input[type=checkbox]')
.filter(function(box) {
&nbsp; &nbsp; return box.checked != checked;
})
.set('checked', checked)
.getParent()[(checked) ? 'addClass' : 'removeClass']('checked')
.fireEvent((checked) ? 'check' : 'uncheck');Mas, realmente, escrever códigos como este em qualquer um dos   frameworks, tenho que argumentar, é uma má pratica. É muito melhor   encapsular sua lógica em trechos re-utilizáveis.
&nbsp;Reutilizando código com a jQuery
É muito tentador quando você está trabalhando em um projeto codificar  desta maneira. Simplesmente adicione na página um pouco de lógica que  seleciona os elementos do DOM e "configura-os": sumindo com alguns,  alterando outros, adicionando eventos onclick e  onmouseover em outros.  Desenvolver códigos dessa forma é muito  eficiente, muito rápido. O  problema de escrever toda sua lógica na  declaração ondomready  é que você termina com um monte de código que faz a mesma coisa em  lugares diferentes. Se olharmos o padrão FAQ acima, poderíamos  facilmente aplicar a mesma lógica em qualquer lugar de uma outra página  com qualquer lista de termos e definições. Mas, afinal de contas, vamos  repetir a mesma lógica cada vez que precisarmos desse padrão?
Uma forma simples de criar códigos reutilizáveis é agrupar a lógica  em uma função e passar os argumentos. Aqui está como isso pode ser feito  no jQuery:
 function faq(container, terms, definitions) {
&nbsp; &nbsp; $(container).find(terms).hide().end().find(definitions).click(function() {
&nbsp; &nbsp; &nbsp; &nbsp; $(this).next().slideToggle();
&nbsp; &nbsp; });
};
$(document).ready(function() {
&nbsp; &nbsp; faq('#faq', 'dd', 'dt');
});Esta é uma forma muito melhor por dois grandes e importantes motivos:
Se amanhã tivéssemos que mudar como essas listas trabalham (talvez  quiséssemos adicionar uma lógica de monitoramento de clicks para  podermos medi-los nos nossos logs ou talvez quiséssemos procurar as  definições através de AJAX), nós poderíamos simplesmente mudar nosso  método faq principal e todos os lugares em que o utilizamos são  automaticamente atualizados. Ou se existir uma nova versão do jQuery que  muda a forma como as coisas trabalham, nós podemos atualizar apenas  nosso método ao invés de dúzias de cópias por todos os lugares. Chamo  isso de "keeping a  small footprint" nos meus aplicativos. Mantendo em  menor número possível  os pontos em que o  aplicativo é influenciado  pelo código mais genérico, consigo deixar mais  fácil o conserto de  bugs, atualização de frameworks, inclusão de novos  recursos ou  alterar  funcionalidades.
O segundo motivo é que isso gera menos código. Utilizando o mesmo  método várias vezes, não repito o trabalho e isso é importante em  qualquer ambiente de trabalho. Isso também faz com que o código que meus  visitantes precisam pegar seja menor.
Na verdade, jQuery possui um sistema um pouco mais refinado de   escrever widgets reutilizáveis como esse. Ao invés de encorajá-lo a   colocá-lo em funções como no  exemplo acima (o que é realmente bastante  primitivo), ela encoraja a  escrita de jQuery plug-ins. Aqui está como poderia ficar:
 jQuery.fn.faq = function(options) {
var settings = jQuery.extend({
&nbsp; &nbsp; &nbsp; &nbsp; terms: 'dt',
&nbsp; &nbsp; &nbsp; &nbsp; definitions: 'dd'
&nbsp; &nbsp; }, options); 
&nbsp; &nbsp; //"this" is the current context; in this case, the elements we want to turn into faq layouts
&nbsp; &nbsp; $(this).find(settings.terms).hide().end().find(settings.definitions).click(function() {
&nbsp; &nbsp; &nbsp; &nbsp; $(this).next().slideToggle();
&nbsp; &nbsp; });
&nbsp; &nbsp; return this;
};que você utilizaria através de:
 $('#faq').faq();Mas, olhando no exemplo acima, não há muita diferença entre definir   nossa função faq dessa maneira ou declará-la como uma função stand alone. Bom, ela não está no  global namespace,  mas poderíamos tão fácil e simplesmente colocá-la em um namespace nosso  próprio. Anexando-o à jQuery nós podemos encadeá-lo com qualquer outro  método jQuery. Outro benefício é que o this nessa função é o mesmo do  contexto da jQuery, seja lá qual for ele no momento do encadeamento.  Utilizando este padrão para plug-ins, somos capazes de construir nosso  plug-in de forma que ele se pareça como parte do jQuery, mas na verdade  nosso plug-in é basicamente uma simples função que pega algum contexto  do jQuery, faz algo com ele e então retorna o contexto para o próximo  item na cadeia. Não existe nenhuma grande complexibilidade aqui, o que  faz com que seja fácil para qualquer pessoa escrever um plug-in para o  jQuery - eles são apenas funções simples.
Note que é possível escrever plug-ins mais complexos no jQuery como  métodos e estados. Esse tipo de padrão é suportado com o sistema de  plug-in jQuery UI e que não utiliza o mesmo mecanismo do plug-in básico  (como o do nosso exemplo). Ao invés disso, você anexa um objeto com  métodos e propriedades no objeto jQuery (por exemplo $.ui.tabs).  Existe um atalho para chamar este objeto ($(selector).tabs())  de forma que você pode continuar encadeando da mesma forma que o  plug-in faq. Mas devido ao motivo de ele não retornar a referência para o  objeto tabs criado para o item no seu seletor, você é forçado a chamar  este seletor novamente para invocar seus métodos. Ao invés de chamar myTabInstance.add(url, label, index) você precisa executar o seletor novamente e chamar sua função pelo nome (como uma "string"): $(selector).tabs('add', url, label, index);.  Isso significa que você está executando o seletor duas vezes (a não ser  que você guarde-o em uma variável em algum lugar), e que você nunca tem  um pointeiro para o método add para que você possa fazer coisas como bind ou delay.  Esse artigo é focado nos núcleos do MooTools e do jQuery e enquanto o  sistema jQuery's UI não  oferece essa funcionalidade, não é algo que  venha com o jQuery por padrão.
&nbsp;Reutilizando código com a MooTools
No MooTools, quando você quer definir um padrão, é mais provável você usar tanto a função Class ou implementar um método no objeto nativo (na String, por exemplo).
Ao invés de oferecer uma linguagem completamente diferente do estilo  nativo do JavaScript, o MooTools tenta caminhar pela via do meio  definindo sua própria sintaxe personalizada e extendendo os padrões do  JavaScript. Uma das formas que ele faz isso é estendendo os protótipos  dos objetos nativos na linguagem e no DOM. Isso significa que se você  precisar de um método  trim para uma string, a MooTools encoraja você a  adicionar esse método  na String (note que String.trim já está na   MooTools, você não precisa incluí-la sozinho):
 String.implement({
&nbsp; &nbsp; trim: function() {
&nbsp; &nbsp; &nbsp; &nbsp; return this.replace(/^\s+|\s+$/g, '');
&nbsp; &nbsp; }
});Isso significa que você pode simplesmente executar " sem mais espaços no começo ou final! ".trim() e receber "sem mais espaços no começo ou final!". Alguém pode  dizer que implementar propriedades nos objetos nativos é inapropriado. Este é o motivo pelo qual o MooTools e o Prototype.js não se dão muito  bem entre eles - qualquer framework  que manipular os protótipos nativos não irá se dar bem com outro que  fizer o mesmo. Se eu definir String.prototype.foo() e outra biblioteca  fizer o mesmo na mesma execução, a que fizer isso por último vencerá. De  certa forma, isso é semelhante ao problema que encontramos com o namespace global window.  Esta é a forma que o JavaScript funciona. Esta é a forma pela qual o JavaScript 1.8 adicionou tantos novos  recursos. Ele os adicionou nos protótipos.
Os desenvolvedores do MooTools criaram um robusto framework,  o qual permite a você estendê-lo com suas próprias funcionalidades.  Fizeram isso pensando que as pessoas  que o incluírem na sua página vão  usá-lo, não outro framework. Na verdade, é um tanto rude exigir que um usuário faça o download de dois frameworks. A única  razão para incluir dois frameworks  é querer utilizar plug-ins de ambos, e na cabeça dos autores do  MooTools (inclusive na minha), se você quer um plug-in que não está  disponível na framework de sua escolha, é mais apropriado você  gastar um tempo codificando ele para o seu ambiente do que exigir que os  usuários peguem outro framework.
Uma vez que você aprenda como o JavaScript funciona e veja o poder de  estender objetos nativos, um novo nível de programação se abrirá  completamente. Você poderá escrever plug-ins que alteraram Elements,  Dates ou Functions. Enquanto alguns argumentam que incluir métodos aos  nativos dessa forma seja uma espécie de poluição, eu tenho que  argumentar que é dessa forma que o JavaScript foi criada para ser  utilizada. É um recurso padrão da linguagem. Anexar métodos para aos  nativos permite que o seu código seja conciso e compartimentado. O  jQuery faz isso também, mas limita suas melhorias ao protótipo do objeto  jQuery.
Enquanto você pode encadear múltiplas chamadas a métodos no objeto  jQuery, em qualquer outro tipo de objeto você tem que utilizar  genéricos. Por exemplo, no jQuery, se você quer remover os espaços do  começo e do final de uma string (trim) e iterar em linhas, você terá de  escrever:
 $.each( $.trim( $('span.something').html() ).split("\n"), function(i, line){alert(line);});Mas como o MooTools modifica os protótipos, você pode:
 $('span.something').get('html').trim().split("\n").each(function(line){alert(line);});Apenas observando isso, vemos claramente o quão poderoso é alterar os  protótipos. Encadeamento nos elementos DOM não é o único lugar onde o  encadeamento é útil. O MooTools permite que você encadeie métodos em  qualquer objeto, inclusive rodar um método em vários elementos de uma só  vez.
A chave aqui é que no coração do MooTools framework mora a  noção que ela está lá para lhe ajudar a programar do jeito que você  quiser. Se existe alguma funcionalidade que não está no seu núcleo, você  pode estendê-lo da sua maneira. O trabalho do núcleo não é oferecer  cada bit de funcionalidade que vocês podem sequer querer um dia, mas  oferecer as ferramentas que permitem vocês escreverem as coisas da  maneira que vocês quiserem. Uma grande parte disso é deixar fácil  estender protótipos nativos e utilizar as vantagens da herança  prototipada. Você pode fazer essas coisas com JavaScript puro, mas o  MooTools faz essa tarefa mais fácil e agradável.
&nbsp;MooTools e herança
Apesar do seu nome, a função Class do MooTools não é uma,  nem cria classes. Ela possui padrões de desenvolvimento que podem  lembrar as classes de linguagens de  programação mais tradicionais, mas,  na verdade, Class é intimamente relacionada a objetos e herança prototipada.
Para criar um protótipo, você envia um objeto para a função Class dessa maneira:
 var Human = new Class({
&nbsp; &nbsp; initialize: function(name, age) {
&nbsp; &nbsp; &nbsp; &nbsp; this.name = name;
&nbsp; &nbsp; &nbsp; &nbsp; this.age = age;
&nbsp; &nbsp; },
&nbsp; &nbsp; isAlive: true,
&nbsp; &nbsp; energy: 1,
&nbsp; &nbsp; eat: function() {
&nbsp; &nbsp; &nbsp; &nbsp; this.energy = this.energy + 1; //same as this.energy++
&nbsp; &nbsp; }
});Você passa um objeto à Class (acima, nós passamos um objeto com membros como isAlive e eat) e esse objeto se torna o protótipo de todos os objetos do tipo Human. Para criar um Human, você faz assim:
 var bob = new Human("bob", 20); //bob's name is "bob" and he's 20 years old.Agora possuímos um descendente de Human, bob. bob possui as propriedades definidas no protótipo Human,   mas é importante notar que, no início, essas propriedades existem  em  bob apenas através da herança prototipada. Quando nós solicitamos   bob.eat, bob não possui realmente um método eat. A linguagem JavaScript   procura por um método  eat, não encontra e então ela sobe na cadeia de  heranças até encontrá-lo  no objeto Human, onde definimos Human.eat através da função Class.   Isso ocorre também para  a propriedade energy. À primeira vista, isso  parece potencialmente ruim;  afinal de contas, não queremos que todos os  humanos que criemos ganhem o valor de  bob.energy a cada vez que  bob  come. O importante aqui é entender que na primeira vez que  atribuirmos  um valor para bob.energy, estaremos atribuindo o valor para  uma  propriedade que é realmente de bob e  assim a linguagem não irá mais  procurar a propriedade nos objetos acima  na cadeia de herança.  Portanto, na primeira vez que bob come, ele recebe  sua própria  definição de energy (que é 2).
 bob.eat(); //bob.energy == 2Note que as propriedades name e age são próprias de bob; elas foram atribuídas a ele no momento que o criamos através da função initialize que passamos para Class.
Esse padrão pode parecer estranho para você, mas o importante aqui é  que podemos definir funcionalidades para um padrão e criar instâncias  desse padrão toda vez que precisarmos dele. Cada instância mantém seu  próprio estado. Então se criamos outras instâncias, elas serão todas  umas independentes das outras, mas herdarão do mesmo protótipo:
 var Alice = new Human();
//alice.energy == 1
//bob.energy == 2As coisas começam a ficar realmente interessantes quando aumentamos esse comportamento.
&nbsp;Estendendo e implementando classes
Vamos rever nosso plug-in faq da jQuery. O que aconteceria se  quiséssemos incluir mais funcionalidades a esse plug-in? E se  quiséssemos fazer uma versão AJAX que procura as respostas para as  questões no servidor? Vamos imaginar que esse plug-in faq foi escrito  por outra pessoa e que gostaríamos de incluir mais coisas nele  sem  alterá-lo de forma alguma (não queremos fazer um fork dele).
Nossas únicas chances reais são: ou duplicar a lógica do plug-in faq   completamente (lembre-se, é apenas uma função), essencialmente criando   um fork, ou podemos chamá-la e depois incluir um pouco mais de  funcionalidades nela. Dadas as escolhas, a segunda parece nos salvar da  maioria dos problemas. O código ficaria mais ou menos assim:
 jQuery.fn.ajaxFaq = function(options) {
&nbsp; &nbsp; var settings = jQuery.extend({
&nbsp; &nbsp; &nbsp; &nbsp; //some ajax specific options like the url to request terms from
&nbsp; &nbsp; &nbsp; &nbsp; url: ...definitions: 'dd'
&nbsp; &nbsp; },
&nbsp; &nbsp; options);
&nbsp; &nbsp; //"this" is the current context; in this case, the elements we want to turn into faq layouts
&nbsp; &nbsp; $(this).find(settings.definitions).click(function() {
&nbsp; &nbsp; &nbsp; &nbsp; $(this).load(.....); //the logic to load the content from the term
&nbsp; &nbsp; });
&nbsp; &nbsp; this.faq(); //call our original faq plug-in
});Isso tem alguns contras. O primeiro de todos, nossa faq irá repetir  os seletores para as respostas, o que pode ser custoso; não há nenhuma  forma de guardar a resposta retornada e passá-la adiante para uma  segunda vez que precisemos dela. Segundo, nós não podemos incluir nossa  lógica AJAX no meio da lógica do plug-in faq a fim de  mostrar a  resposta. O plug-in original chamou, slideToggle que expande a  resposta usando um efeito. Isso é problemático porque esse efeito irá  ocorrer antes de o  nosso AJAX terminar de carregar. Não há nenhuma  solução aqui a não ser duplicar o plug-in faq por inteiro.
Agora vamos considerar nosso protótipo Human. Ele tem propriedades como isAlive e energy e um método chamado eat. O que acontece se quiséssemos fazer uma nova  versão de Human que tivesse mais propriedades? Com o MooTools, nós estendemos:
 var Ninja = new Class({
&nbsp; &nbsp; Extends: Human,
&nbsp; &nbsp; initialize: function(name, age, side) {
&nbsp; &nbsp; &nbsp; &nbsp; this.side = side;
&nbsp; &nbsp; &nbsp; &nbsp; this.parent(name, age);
&nbsp; &nbsp; },
&nbsp; &nbsp; energy: 100,
&nbsp; &nbsp; attack: function(target) {
&nbsp; &nbsp; &nbsp; &nbsp; this.energy = this.energy - 5;
&nbsp; &nbsp; &nbsp; &nbsp; target.isAlive = false;
&nbsp; &nbsp; }
});Você pode ver que incluímos um bocado de funcionalidades aqui em um  sub-protótipo. Esse sub-protótipo possui todas as propriedades que são  únicas para os ninjas. Ninjas  começam com um valor inicial energy de  100. Eles escolhem um side. Eles  também possuem um método attack que os  permitem matar outros Human, mas isso custa  energy.
 var bob = new Human('Bob', 25);
var blackNinja = new Ninja('Nin Tendo', 'unknown', 'evil');
//blackNinja.isAlive = true
//blackNinja.name = 'Nin Tendo'
blackNinja.attack(bob);
//bob never had a chanceDeixando isso um pouco de lado, existem algumas coisas interessantes a se considerar. Note que ao definirmos Ninja através de Class, enviamos novamente uma função  initialize. Isso sobrescreve o método initialize de Human, mas ainda podemos acessar o método initialize de Human através da chamada this.parent com os  argumentos que o método initialize de Human  espera. Além do mais, podemos controlar quando nossa lógica acontece;  antes ou depois da chamada ao seu pai. Podemos  atribuir novos valores  para as propriedades (como energy. por exemplo) e podemos  definir nova funcionalidade. Imagine se pudéssemos fazer isso com nosso  plug-in faq  da jQuery. Poderíamos carregar nosso AJAX e então disparar a  animação (slideToggle).
A MooTools possui outro padrão chamado Mixin. Ao contrário do  relacionamento pai para filho que é definido estendendo um protótipo em  um sub-protótipo, você pode definir protótipos que são misturados em  outras classes para alterá-las com suas propriedades. Veja um exemplo:
 var Warrior = new Class({
&nbsp; &nbsp; energy: 100,
&nbsp; &nbsp; kills: 0,
&nbsp; &nbsp; attack: function(target) {
&nbsp; &nbsp; target.isAlive = false;
&nbsp; &nbsp; this.energy = this.energy - 5;
&nbsp; &nbsp; this.kills++;
}
});Neste exemplo, nós separamos as características que fazem um Ninja diferente de um Human  e as colocamos em um protótipo próprio. Isso nos permite reutilizar  este  código independentemente de Ninja. Poderíamos então embutir nosso  Ninja com as características de um Warrior:
 var Ninja = new Class({
&nbsp; &nbsp; Extends: Human,
&nbsp; &nbsp; Implements: Warrior, //can be an array if you want to implement more than one
initialize: function(name, age, side) {
&nbsp; &nbsp; &nbsp; &nbsp; this.side = side;
&nbsp; &nbsp; &nbsp; &nbsp; this.parent(name, age);
&nbsp; &nbsp; }
});Ninja ainda funcionará como anteriormente, mas o protótipo Warrior continua a nossa disposição para ser reutilizado:
 var Samurai = new Class({
&nbsp; &nbsp; Extends: Human,
&nbsp; &nbsp; Implements: Warrior,
&nbsp; &nbsp; side: 'good'
});Agora temos um protótipo Samurai e um Ninja. Mas olhe como foi necessário escrever pouco para definir tanto Ninja como Samurai. Ambos são semelhantes sob o  ponto de vista que são Human com qualidades de Warrior, mas são diferentes sob os aspecto do Samurai ser sempre bom, enquanto um Ninja pode pertencer a  ambos os lados. Gastando o tempo escrevendo Human e Warrior,  somos capazes de escrever três diferentes protótipos sem nenhuma  repetição de código e ainda mantemos um nível de controle cirúrgico  sobre quando os métodos são chamados e como estão relacionados entre si.  Cada instância que criamos possui seu próprio estado e seu código é bem  legível.
Agora que você teve uma visão geral de como os protótipos funcionam   na MooTools, vamos olhar para nosso faq que escrevemos com o jQuery,   escrevê-lo como  deveríamos no MooTools e estendê-lo para adicionar  AJAX, da mesma forma  que fizemos com o jQuery.
 var FAQ = new Class({
&nbsp; //Options is another class provided by MooTools
&nbsp; Implements: Options,
&nbsp; //these are the default options
&nbsp; options: {
&nbsp; &nbsp; terms: 'dt',
&nbsp; &nbsp; definitions: 'dd'
&nbsp; },
&nbsp; initialize: function(container, options) {
&nbsp; &nbsp; //we store a reference to our container
&nbsp; &nbsp; this.container = $(container);
&nbsp; &nbsp; //setOptions is a method provided by the Options mixin
&nbsp; &nbsp; //it merges the options passed in with the defaults
&nbsp; &nbsp; this.setOptions(options);
&nbsp; &nbsp; //we store the terms and definitions
&nbsp; &nbsp; this.terms = this.container.getElements(this.options.terms);
&nbsp; &nbsp; this.definitions = this.container.getElements(this.options.definitions);
&nbsp; &nbsp; //we call our attach method
&nbsp; &nbsp; //by breaking this into its own method
&nbsp; &nbsp; //it makes our class easier to extend
&nbsp; &nbsp; this.attach();
&nbsp; },
&nbsp; attach: function(){
&nbsp; &nbsp; //loop through the terms
&nbsp; &nbsp; this.terms.each(function(term, index) {
&nbsp; &nbsp; &nbsp; //add a click event to each one
&nbsp; &nbsp; &nbsp; term.addEvent('click', function(){
&nbsp; &nbsp; &nbsp; &nbsp; //that calls our toggle method for
&nbsp; &nbsp; &nbsp; &nbsp; //the current index
&nbsp; &nbsp; &nbsp; &nbsp; this.toggle(index);
&nbsp; &nbsp; &nbsp; }, this);
&nbsp; &nbsp; }, this);
&nbsp; },
&nbsp; toggle: function(index){
&nbsp; &nbsp; //toggle open the definition for the given index
&nbsp; &nbsp; this.definitions[index].slide('toggle');
&nbsp; }
});Uau! É um bocado de código. Mesmo se removermos todos os comentários,   ainda teremos duas dúzias de linhas de código. Já mostrei  anteriormente  que podemos construir esse plug-in com aproximadamente a  mesma  quantidade de código que na versão do jQuery. Então porquê essa é  tão  mais comprida? Bem, fizemos dela muito mais flexível. Para usar  este  protótipo, podemos apenas chamar o construtor, dessa maneira:
 var myFAQ = new FAQ(myContainer);
//and now we can call methods on it if we want:
myFAQ.toggle(2); //toggle the 3rd elementPodemos acessar métodos e propriedades dessa instância. Mas e sobre   nossa funcionalidade AJAX? O problema com nossa extensão AJAX na versão   do jQuery é que não podíamos atrasar a animação até o término do   carregamento do conteúdo. Não temos este problema com nossa versão no   MooTools.
 var FAQ.Ajax({
&nbsp; //this class inherits the properties of FAQ
&nbsp; Extends: FAQ,
&nbsp; //it also gets a new option in addition to the other defaults
&nbsp; //this one for url, that we're going to append the index of the
&nbsp; //term to; in reality we might make this more robust, but for
&nbsp; //this example it serves the purpose
&nbsp; options: {
&nbsp; &nbsp; url: null;
&nbsp; },
&nbsp; //we're going to cache the results, so if a section is opened
&nbsp; //twice, we won't hit the server for the data
&nbsp; indexesLoaded: [],
&nbsp; toggle: function(index){
&nbsp; &nbsp; //if we've already loaded the definition
&nbsp; &nbsp; if (this.indexesLoaded[index]) {
&nbsp; &nbsp; &nbsp; //just call the previous version of toggle
&nbsp; &nbsp; &nbsp; this.parent(index);
&nbsp; &nbsp; } else {
&nbsp; &nbsp; &nbsp; //otherwise, request the data from the server
&nbsp; &nbsp; &nbsp; new Request.HTML({
&nbsp; &nbsp; &nbsp; &nbsp; update: this.definitions[index],
&nbsp; &nbsp; &nbsp; &nbsp; url: this.options.url + index,
&nbsp; &nbsp; &nbsp; &nbsp; //and when the data is loaded, expand the definition
&nbsp; &nbsp; &nbsp; &nbsp; onComplete: function(){
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; this.indexesLoaded[index] = true;
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; this.definitions[index].slide('toggle');
&nbsp; &nbsp; &nbsp; &nbsp; }
&nbsp; &nbsp; &nbsp; }).send();
&nbsp; &nbsp; }
&nbsp; }
});Agora temos uma versão do nosso protótipo FAQ que permite procurar   respostas no servidor. Note que somos capazes de integrar a nova lógica   de uma forma que não anima a resposta até depois do conteúdo voltar do   servidor (o que não conseguíamos fazer na versão com o jQuery). Note   também que nós apenas tivemos descrever a nova funcionalidade (AJAX) e   escrever um pouco mais. Essa extensibilidade permite a criação de   famílias de plug-ins que ofereçam diferentes formas de funcionalidade.   Ela permite também que você utilize o plug-in de outra pessoa e altere,   se precisar, apenas alguns bits que você gostaria que fossem diferentes   (sem precisar fazer um fork). Isso ajuda a explicar o porquê, para  cada  funcionalidade (seletores de data, interface de abas, etc), você   encontra apenas alguns plug-ins para a MooTools. A maioria dos plug-ins   que você pega, ou resolve seu problema, ou você simplesmente pode   melhorá-los com as coisas que você precisa.
Como mostrei anteriormente, é possível escrever widgets complexos no   jQuery também. Entretanto, ao fazer isso longe dos assuntos  relacionados  ao DOM, a maioria do código que você cria é JavaScript  puro e nao jQuery. A  modelagem do jQuery não oferece nenhum sistema  para extensão de  protótipos, nem ajuda a fazer Mixins que podem ser  facilmente  re-utilizados. Finalmente, os plug-ins do jQuery são sempre  atribuidos à  elementos do DOM. Se você quiser escrever uma classe que,  por exemplo  guarda as URLs processadas, não há nenhum sistema que lhe  ajude nessa  tarefa a não ser que você mesmo o faça.
&nbsp;A hora da decisão
O jQuery se foca em expressividade, codificação "rápida e fácil" e   DOM. MooTools se foca em extensibilidade, herança, legibilidade, reuso e   sustentabilidade. Se você analisar essas coisas na forma de vias   opostas, o lado do jQuery leva para algo que é fácil de utilizar e traz   resultados rápidos, mas (na minha experiência) pode se transformar em   códigos difíceis de se sustentar e reutilizar (mas isso depende apenas   de você, lembro que não é um problema que o jQuery se propõe a   resolver), enquanto o lado do MooTools leva a um processo de aprendizado   mais demorado e exige que você escreva mais antes de obter os   resultados, mas no final das contas é mais reutilizável e sustentável.
Além do mais, nem o núcleo da MooTools, nem o núcleo da jQuery   possuem todos os recursos que você possa imaginar. Ambos os frameworks   mantêm seus núcleos bem enxutos deixando como tarefa para seus usuários   escrever plug-ins e extensões. O trabalho deles não é oferecer todos os   recursos que você pode querer, mas oferecer as ferramentas para que  você  possa criar qualquer coisa que você imagine. Este é o poder do   JavaScript, e dos frameworks JavaScript em geral, e nesta tarefa, ambos  os frameworks se excedem. O MooTools alça um vôo mais alto e oferece   ferramentas para você escrever qualquer coisa que imaginar dentro e além   dos domínios do DOM, mas paga como preço possuir uma curva de   aprendizado mais lenta. Essas ferramentas são um conjunto maior do que   as oferecidas pelo jQuery, mas o foco do jQuery em criar uma API rápida e   fácil, não impede que você utilize os métodos de herança nativos do   JavaScript ou utilize o "sistema de classes" do MooTools se você quiser.
Este é o motivo pela qual digo que ambos os frameworks são escolhas   excelentes. Meu esforço era destacar as diferenças de filosofia entre   essas duas bases de código, suas vantagens e desvantagens. Duvido que eu   tenha conseguido manter minha imparcialidade com relação ao MooTools,  mas  espero que este artigo tenha sido útil. Independente do framework   que você escolher agora, você já sabe bastante sobre os dois. Se você   tiver o luxo do tempo, recomendo que você crie um site com cada um   deles. Então escreva sua própria análise deles e talvez suas conclusões   destaquem alguma coisa que esqueci.