Comparison between jQuery and MooTools (1)

When I went to college, I used jQuery to work on projects. After graduation, I used MooTools to work on projects. We are lucky to have the opportunity to access two excellent JavaScript libraries with different design styles in the short term. Today, I have my own understanding of these two JS frameworks. I hope that you will have a better understanding of the MooTools JS framework. After all, most people engaged in web Front-ends are more familiar with jQuery, which is easy to use.

BKJIA recommended topics: jQuery from entry to entry

I. API design

In terms of API design, both MooTools and other JS frameworks similar to YUI are slightly inferior to jQuery.

What is an API?According to answers from some books,An API is an abstraction of the required knowledge. It hides the complexity of the system.. For example, a car steering wheel or a button on a TV. The quality of an API design can be evaluated from the following aspects: comprehensibility, consistency, foresight, simplicity, and protection.

◆ Comprehensibility

For example, selector ). Just give an example of a selector (jQuery ):

 
 

  
  
$("#jQuery div") 
 
 

The style of selector is the same as that of CSS selector. Therefore, many people who write pages can easily use jQuery to find the desired onion. Later versions of jQuery killed XPath, probably because of understanding problems. Of course, MooTools also supports CSS selectors, except that it does not use a dollar sign $, but two $ S. It looks like learning the prototype framework and returning an array.

 
 

  
  
$$("#MooTools div") 
 
 

If MooTools only takes this step, I think it's okay. It seems like it's just a little cool with jQuery's comprehensibility. Unfortunately, MooTools also has a single $ selector. The parameter can only be the element id, for example:

 
 

  
  
$("MooTools") 
 
 

In this case, we chose an object with the MooTools Element Extension Method. If it does not exist, an error is returned when the Element Method (eg: addClass) is applied.

That is to say, MooTools selects elements. Based on the usage, sometimes the returned elements may be arrays and sometimes element objects. This will inevitably make people familiar with JS and those familiar with CSS have difficulties in understanding and using them. However, this does not blame MooTools. Different design architectures make it possible for MooTools to return element objects instead of element object arrays.

Therefore, MooTools is inferior to jQuery in terms of comprehension.

◆ Consistency

One of the main manifestations of JS framework consistency is chained calling, for example (jQuery ):

 
 

  
  
$("#jQuery").css("color", "red").height(200); 
 
 

MooTools also supports chained calling, such as (MooTools ):

 
 

  
  
$$("#MooTools").setStyle("color", "red").setStyle("height", 200); 
 
 

In the chain call, jQuery and MooTools are basically OK.

However, in terms of consistency in other aspects, MooTools seems to be falling below the storm again. The jQuery framework is really amazing. A $ symbol can go from Guangzhou to Beijing, which is a perfect key.

First selector, for example, $ ("# jQuery") must be the $ symbol. Then, some other related methods, such as the plug-in mechanism $. fn. extend (object), or Ajax request $. ajax ([options]), browser detection, array object methods, and so on are all $ symbols.

However, the $ symbol in MooTools sang appears in the selector, which makes it difficult to understand $ A, $ E, and some public method names. They all go home to sleep for the rest of the time.

The inheritance requires the construction of new Class (). The Ajax Request is new Request ([options]), and the Browser detection starts with Browser. Array, string, and other methods are headers of the current object, such as myString. trim (). There is no consistency. Obviously, the learning cost and difficulty are much higher than that of jQuery.

◆ Foresight

A good API should take into account the user's selective cluelessness and the future of the future.

I don't know if John Resig (the father of jQuery) really thinks a long way. Fortunately, or just because John is a genius, jQuery's design does not seem to conflict with the future.

For example, filter the leading and trailing spaces of a string. JQuery's approach is:

 
 

  
  
$.trim(myString); 
 
 

MooTools practices:

 
 

  
  
myString.trim(); 
 
 

At first glance, it seems that the practices of the MooTools framework are more in line with our understanding → the string object has a trim method that returns the string method that filters spaces before and after. However, with the time dragging, some things start to change.

In ECMAScript 5 (ES5), strings are built-in trim methods. We can perform a small test with the following code:

 
 

  
  
alert((" foo ").trim()); 
 
 

You can click here: ES5 built-in trim method test

For example, in my FireFox 6 browser, foo is displayed, as follows:

Some browsers with historical values are not supported, such as in IE7 mode:

Similarly, the bind method based on Function extensions is available in MooTools, but ES5 is also built in. Fortunately, although the names of the string trim method or the function bind method conflict, the implemented functions are indeed the same. Therefore, it is not a conflict. However, in case of an unfortunate problem one day, a method in MooTools has the same name but different functions as the method in ES5, and then it can only be broken down!

For another example, the selector selects an object and a DOM object. JQuery separates jQuery objects from native dom objects, for example:

 
 

  
  
$ ("Input"). bind ("focus", function (){
  
  
Alert (this. value); // dom object
  
  
Alert ($ (this). val (); // jQuery package object
  
  
});
 
 

However, in MooTools, some methods are extended on the native DOM. The element objects of MooTools are compatible with the native dom, for example:

 
 

  
  
$ ("Input"). addEvent ("focus", function (){
  
  
Alert (this. value); // dom object
  
  
Alert (this. get ("value"); // extended dom object
  
  
});
 
 

The problem with "fit" is that with the development of browsers and some standards, native dom may support some other methods, which may conflict with the DOM extension methods in the MooTools plug-in. Fortunately, the method naming of MooTools is symmetric and has obvious semantics. This design can effectively avoid conflicts with the native dom method. But it's not that simple ...... Below you can see some problems with the design of DOM element methods in MooTools (of course, it is undeniable that such design is relatively flexible ).

◆Simplicity

One of the reasons why jQuery makes developers reluctant is its simplicity. JQuery's slogan is "write less, do more ."

Taking dom-style APIs as an example, frameworks such as MooTools and YUI adopt the traditional symmetric naming method (prop is short for property attributes ):

 
 

  
  
El. setStyle (prop, val );
  
  
El. getStyle (prop );
  
  
El. setStyles ({propA: valA, propB: valB });
  
  
El. getStyles (propA, propB); // supported by MooTools. A name-value object is returned.
 
 

In jQuery, a CSS takes over all porcelain appliances:

 
 

  
  
El.css (prop); // getStyle
  
  
El.css (prop, val); // setStyle
  
  
El.css ({propA: valA, propB: valB}); // setStyles
  
  
El.css (prop, func); // func is a function that returns the val value.
 
 

Although the parameters are similar, jQuery only requires one name, while MooTools requires N names, and the names must be complete and long. Otherwise, problems may occur ). This is why jQuery is easier to use. In addition, jQuery is one step closer. It also supports func callback, and the parameter can be map, val can be a function, and surprise is a lot hidden.

Obviously, simplicity is better than jQuery.

Here, I want to talk about other related things. The short name design of the jQuery framework is really good, so I want to extend the element methods of MooTools, which is equivalent to jQuery's naming and writing method. The first is to save some code, second, it is easy for new employees familiar with jQuery to get started. Take the dom-style example above. MooTools provides the following extension processing:

 
 

  
  
Element. implement ({
  
  
// Convert the default setStyle and setStyles methods of mootools to the css () format similar to jQuery.
  
  
Css: function (key, value ){
  
  
If ($ type (key) = 'object '){
  
  
For (var p in key) this.css (p, key [p]);
  
  
Return this;
  
  
}
  
  
If (! $ Chk (value )){
  
  
Return this. getStyle (key );
  
  
}
  
  
This. setStyle (key, value );
  
  
Return this;
  
  
}
  
  
});
 
 

Therefore, MooTools also supports CSS methods. For example, you can directly $ ("mootools" ).css ({border: "1px solid # ddd "});. Well, it looks good. Indeed, the above extensions are no problem in various browsers currently. As a result, when we first taste the sweetness, we want to simulate the extension of other jQuery wrapper methods, such as the width/height method, as shown in the following (width example ):

 
 

  
  
Element.implement({  
  
  
    width: function (val) {  
  
  
        if ($chk(val)) {  
  
  
            return this.setStyle("width", val);  
  
  
        } else {  
  
  
            return this.getWidth();  
  
  
        }  
  
  
    }  
  
  
}); 
 
 

Looks good, isn't it? However, there is a problem with the width method extension of dom in the above MooTools framework. We all know that the element has the width attribute. As mentioned above, the element methods of the MooTools framework are directly "fit" on the DOM. Therefore, for images, using the width method expanded above will fart-native attributes conflict with the extension method.

 
 

  
  
Alert ($ ("image"). width (); // error, show $ ("image"). width is not function
 
 

This further proves that jQuery's API design can avoid potential conflicts between the present and the future, making it more insightful.

◆Protection

JQuery has a multi-database coexistence mechanism to effectively protect the $ symbol that other frameworks compete for, effectively avoiding compatibility issues.

 
 

  
  
JQuery. noConflict ();
  
  
(Function ($ ){
  
  
$ (Function (){
  
  
// Use $ as the jQuery alias code
  
  
});
  
  
}) (JQuery );
  
  
// Other code of the database that uses $ as the alias
 
 

This mechanism does not seem to exist in MooTools.

Conclusion: In terms of API design, jQuery is better than MooTools in almost all aspects, which is also the main reason for jQuery's popularity.

Ii. Performance

◆ Selector Performance

The official page of the MooTools framework provides the selector performance test page: speed/validity selectors test for frameworks.

Click the "start tests" button in the upper right corner. After a while, you can see the test results of each selector in each framework. The following table shows the result records after I contacted the test three times. We can see that the overall performance of the jQuery selector is slightly lower than that of prototype, which is better than that of MooTools. However, when interacting with some pages, the differences between selector can basically be ignored (YUI must be wary of poor performance on the nth-child selector ).

◆ Dom Operation Performance

I originally wanted to find the performance comparison data between MooTools and jQuery framework in dom operations on the Internet. I found that there was no such data, and there was no such data. In this difficult and difficult time, I think of the words of the great leader Chairman Mao: "self-reliance, hard work ". The small universe in the heart suddenly broke out, and the knife was in disorder. After some tossing, I made a test page that I wanted.

Click here to compare the performance of some dom operations of MooTools and jQuery.

The test result is as follows:

As you can see, except that the performance of the setProperty/attr and setProperties/attrMulti Methods MooTools frameworks is slightly higher, some dom-related operations fail jQuery.

Summary:Performance. The performance of the MooTools framework, whether it is a selector or some other methods, is inferior to that of jQuery.