Comparison between jquery and mootools Libraries

Document directory

• I. API design
• Ii. Performance
• 3. What are the advantages of mootools?
• Iv. Comparison and summary

Comparison between jquery and mootools Libraries

From http://www.zhangxinxu.com by zhangxinxu
Address: http://www.zhangxinxu.com/wordpress? P = 1963

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.

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 works, API is an abstraction of the required knowledge, which 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(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 amazing.$The symbol can go from Guangzhou to Beijing.
First selector, such$("#jQuery")Yes$Symbol, and other related methods, such as plug-in mechanism$.fn.extend(object)Or Ajax requests.$.ajax([options])Or browser detection, array object methods, etc.$Symbol.

However, mootools sanzhong$Symbol appears in the selector, which is hard to understand$A,$EAnd some public methods are named, and they all go home to sleep for the rest of the time.
Inheritance requirementsnew Class()Construct, Ajax request isnew Request([options])And then the browser detectsBrowser. Array, string, and other methods are headers of the current object, suchmyString.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 non-dynamic choice ( selective cluelessness) And other things that may happen in 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 hastrimReturns the string method that filters spaces before and after the filter. However, with the time dragging, some things start to change.

In ecmascript 5 (es5), the string is built-intrimMethod. 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 browserfoo, As follows:

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

Similarly, it is based on function expansion.bindMethod, which is available in mootools. However, es5 is also built in. However, we are lucky to see thattrimMethod or functionbindMethod, although the name conflict, but the implementation of the function is indeed the same, so 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 wrapper 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); // The 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 and supportsfuncCallback, and the parameter can bemap,valIt can be a function, which hides a lot of surprise.

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 CSS () format similar to jquery: 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, we first tried to simulate extensions of other jquery wrappers, suchwidth/heightMethod, as follows (widthExample ):

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

Looks good, isn't it? However, the previous mootools framework performed on DomwidthThere is a problem with method extension. We all know that,Element iswidthAttribute. As mentioned above, the element methods of the mootools framework are directly "fit" on the Dom. Therefore, for images, use the above extendedwidthThe method is awkward-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 () {// code that uses $ as the jquery alias}) ;}( 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 we perform interactions on some pages, the differences between selector can basically be ignored (:nth-childThe poor performance on the selector must be avoided ).

	Mootools 1.2	Mootools 1.3.1	Jquery 1.5.1	Prototype 1.7	Yui 2.8.2 Selector	Dojo 1.5
Total time of the first test	75	67	37	34	685	49
Total time of the second test	66	56	28	26	668	48
Total time for the third test	67	55	30	30	663	43

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:

ATTR	Mootools 1.3.1	Jquery 1.5.1
Setstyle/CSS	79 MS | 1 found	53 MS | 1 found
Setstyles/cssmulti	200 MS | 1 found	109 MS | 1 found
Setproperty/ATTR	37 MS | 1 found	43 MS | 1 found
Setproperties/attrmulti	1 MS | 1 found	55 MS | 1 found
Addclass	40 MS | 1 found	18 MS | 1 found
Addclassmulti	54 MS | 1 found	25 MS | 1 found
Hasclass	75 MS | 1 found	MS | 1 found
Removeclass	118 MS | 1 found	23 MS | 1 found
Removeclassmulti	109 MS | 1 found	10 MS | 1 found
Final result (the smaller the better)	763	360

As you can see,setProperty/attrAndsetProperties/attrMultiThe performance of the method mootools framework is slightly higher than that of other dom-related operations.

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

3. What are the advantages of mootools?

Based on the comparison of the above two items, the mootools framework is not as good as jquery in terms of APIS, and some Dom-related operation performance is not as good as jquery. What are the reasons for choosing the mootools framework? What are the advantages of the mootools framework?

Before talking about the advantages of mootools, I 'd like to talk about some additional things. A member of the mootools team once said something worth thinking about as follows:

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 E Ach 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.

The mootools Team (I am one of them) has never really noticed how popular this framework is. We are only interested in writing this framework and writing it for our own use and purpose, but we really didn't spend a lot of effort to let others use it. We never think of other frameworks as our competitors-because I have heard of such a thing on many occasions that we are fighting against browsers rather than each other. In my article, I suggest you try more options and then select a framework that suits your needs and your style. You really cannot make a bad choice (so please stop quarreling !). Jquery, prototype, Yui, dojo, and mootools -- we are doing the same thing in different ways.

When I first heard Shi Zhongdong talk about the mootools library, I was wondering: Basically I have never heard of it, and no one is using it. It should be strange, bad framework. However, as I gradually learned about this JS framework, I became more and more fond of jquery, because it is more suitable for projects I am currently working on than jquery, big Data Processing and many complex interactions.

Because of jquery's excellent APIs, even those who do not know much about JavaScript can write self-confidence code. In addition, jquery's focus is on the Dom. This is just to win the favor of some designers and csser who are keen on page effect interaction. If you want to build small and medium-sized dynamic web sites, jquery is correct. Fast, simple, elegant, and beautiful. If I were a designer, I would also use it.

However, if there are large projects with hundreds of millions of pages, some projects with large data volume interaction and processing, multi-person cooperation, and multi-modular projects, jquery will often become weak, various plug-ins are often required. You know, there are hundreds of jquery plug-ins, but most of them are shit. If no cool person controls the project, it will eventually become a shit!

Although mootools can also be used in small and medium-sized projects, its potential must be used in large and JavaScript-intensive website projects. This is the advantage of mootools. Of course, I am talking about evidence. Next I will talk about why large website projects are more suitable for mootools than jquery.

More object and method extensions
Although the mootools framework performs method extension directly on the array and function objects, it may cause repeated or conflicting JavaScript specifications. However, it is undeniable that, the extension of these object Methods saves a lot of effort for our development.

For example, the extension of the string method. In jquery, there seems to be only one string-related operation method.trim.
However, in mootools, there are 14 built-in string extension methods, for example, string content detectioncontainsMethod To clear unnecessary blank strings in the entire stringcleanMethod to escape sensitive characters in a regular expressionescapeRegExpMethod or integertoInt()As well as conversion string methods related to RGB color and hexadecimal color. There are a lot of string-related processing when large data volumes are interacted. The string extension methods provided by the mootools framework cannot be described as N-plus convenience.

It is not just a string. mootools extends values, functions, and array objects. In particular, in addition to its native methods, mootools also extends nearly 20 methods to it. This makes it almost invincible when dealing with arrays. In short, the mootools framework expands new methods on various types of JavaScript objects, so that we can more easily and easily cope with various complex applications and numerous data processing. This is obviously different from jquery's design philosophy focusing on Dom.

Hash concept for data processing tools
Hash, commonly known as hash, is a good tool in jquery, but not in mootools. Hash is a re-implemented object ({}), which is specially used for data access. The difference from the original object ({}) is that it will not store values, process the content in the prototype of the object when values or iterations are performed. In mootools, the hash object and the array object (which is basically composed of JSON) can be used together, and can be easily handled without the complicated data of TM. This reminds me of the food selection interaction on the detail page of our small secretary's restaurant. If there is no hash, I really don't know how to do it. Or, if it's not the mootools framework, but jquery. The complicated interaction implementation here is a dream.

Object-Oriented Design
Mootools is an object-oriented design framework. Emphasis on inheritance, modularization and reusability. Althoughnew Class({})Some of them are hard to understand and use. However, it is really useful to be able to "survive. Here is an example of a translucent mask layer. We construct a class named overlay, and its related code is as follows:

var Overlay = new Class({    Implements: [Options, Events],    getOptions: function() {        return {            name:'',            duration: 200,            colour: '#000',            opacity: 0.35,            zIndex: 99,            container: document.body,            onClick: $empty        };    },    initialize: function(options) {        //......        return this.position();    },    position: function() {        //......    },    show: function() {         //......    },    hide: function(dispose) {        //......    },    dispose: function() {        //......    }});

Therefore, when we need a translucent mask layer:

var myOverlay = new Overlay();

In the overlay classposition,hide,showAnd other methods are externally visible. We use the following methods:

myOverlay.hide()

Hide the mask layer. Of course, we can define a new class, which inherits or uses the overlay class, for example, the pop-up effect that we commonly use. Although the forced object-oriented design of mootools somewhat fades away some of the beautiful features of JavaScript language itself. However, when the project is huge and JavaScript code is huge, this object-oriented design concept is quite useful. The larger the project, the more code we save.

Cookie read/write
The mootools framework provides a cookie-based read/write method and supports specifying the domain and path. In the jquery framework, to implement cookie read/write, we need to use a dedicated cookie plug-in. The additional plug-in obviously won't be enough for jquery. HTML5 localstorage local storage the actual application this article's IE browser cookie reading and writing is to use the cookie method that comes with the mootools framework. Very easy to use.

Manned SWF File
Built-in mootools frameworkSwiffClass, which can load Flash files on the page without requiring Google'sswfobjectMethod.

 

The above watch flash effect code is as follows:

var obj = new Swiff('http://www.zhangxinxu.com/study/flash/as3_clock_2.swf', {    width: 300,    height: 300,    container: $("swfBox"),    params: {        wmode: 'opaque',        bgcolor: '#eeeeee'    }});

More comprehensive animation Effects
The animation effect of the mootools framework is actually better than that of jquery, but the disadvantage is that its APIs are inferior to jquery.
The mootools framework animation is better than jquery, and one of them is that the mootools animation has a built-in bersel Motion Curve keyword. For example:'linear','quad:in','back:in','bounce:out','elastic:out','sine:in:out'And so on (for the FX. transitions Methodexpo), While jquery achieves a similar easing effect, you also need to useeasePlug-ins.

Form serialization submission
Mootools itself carries the data serialization method of HTML form control elements, such:

$ ('Myform'). toquerystring (); // return "email = bob@bob.com & zipcode = 90210"

The form Element carries the Ajax submission method, as shown in the following example:

$ ('Loginform '). addevent ('submit ', function (e) {e. stop (); // do not submit form $ ('loginform '). send ({oncomplete: function (result) {$ ('logingroup '). set ('html', result); // display result (function () {$ ('logingroup '). hide ();}. delay (1000); // hide in one second }});});

To implement similar functions, the jquery framework also requires specialized form serialization plug-ins. I rely on this plug-in the East, a plug-in the West, and the plug-in quality is uneven, too much will die.

Iv. Comparison and summary

First of all, jquery and mootools are both excellent lightweight JavaScript frameworks.

Jquery is very popular with its outstanding APIs, excellent plug-ins, and Dom attention. However, in the face of large-scale projects, plug-ins are often needed for missing features. If the team does not have any cool personnel, the abuse of plug-ins will make the quality of the project code gradually turn into shit. In general, jquery is more suitable for dynamic small and medium sites.

Although the mootools plug-in is far behind jquery in terms of API, Dom, and ease of getting started, its APIs and object-oriented design ideas seem to be more valuable in practical big projects.

Therefore, if I want to toss my personal website, jquery should be used. However, if it is a big website project of the company, I will unswervingly choose mootools, because it is more suitable.

I have a relatively low JS level, and it is basically a comparison of some appearances.

 

Original article, reproduced please indicate from Zhang xinxu-xin space-xin Sheng live [http://www.zhangxinxu.com]
Address: http://www.zhangxinxu.com/wordpress? P = 1963