The real difference between jquery and mootools

ArticleDirectory

• Introduction
• Bill Scott continues to teach me things
• Bill Scott is continuing to teach me some things.
• Programming to the Pattern
• Programming Mode
• Trade-offs, but big benefits
• Some trade-offs, but the pursuit of the Best Interests

Introduction

I have been using the mootools framework. I accidentally saw this article. I was a member of the mootools team and explained the differences between jquery and mootools. I think he wrote JavaScript.CodeAnd his way of thinking is worth learning. In addition, there are a lot of good suggestions on JavaScript programming ideas and framework selection, which can be helpful to those who hesitate to provide guidance on various frameworks, in addition, there are good suggestions for those who want to conduct in-depth research on the framework or develop the framework themselves. Although the article is very long, I think it is good and then translate it. The level is limited, and the text is rough. Some of them feel that the translation is too far-fetched.

Translator: fdream

Translator's blog: fdream's blog

Original article: jquery, mootools, which is the most popular and well represented framework and what really makes one framework different from another

Title:

Jquery, mootools, which is the most popular and well represented framework and what really makes one framework different from anotherjquery and mootools, which framework is more popular, better performance, and the real difference between them?

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.

I have been trying different JavaScript libraries and trying to find some suitable feature combinations: Ext. JS is very scalable, but it is too complicated and difficult to learn.

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 is very easy to learn and has outstanding features. But when you look for more functions from the plug-in library, you find that there is no official library. Plug-in features are very good, but there are also some bad places ...... Soon you will be confused by countless available plug-ins. you need to spend a lot of time determining which plug-ins match the quality of the core library. If these plug-ins are listed on the homepage, however, it takes a lot of effort to find a suitable combination of features. I am also using the Microsoft Ajax library, but do not like their control extension frameworks (they are too complicated ).

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 supported 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.

Therefore, I must first easily prove that jquery is the most popular and better-performing framework. They are the best. John resig (author of jquery) said seven times in three days: "Microsoft demonstrates how to include jquery into its SDK, the attendees certainly spoke about this framework. All of these clearly show me that jquery is doing something right ."

Part of the task I set for myself in attending the conference was to attend as parameter of these jquery sessions as I cocould both to learn as much of jquery as I cocould (I have, in the past, dug into it, but I wanted to soak up as much as I coshould from the development team and John) and also to see if I cocould pick up on what accounts for the popularity of the framework.

Part of my task to attend this meeting is to participate in jquery communication and learning as much as possible (I have also learned a lot in depth, but I want to learn more from the development team and John.) I can also see if I can find out why this framework is popular.

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.

Here we need some explanations. 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. I have written a lot about this because I have been thinking about it recently.

Bill Scott continues to teach me thingsbill Scott is continuing to teach me something

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 whole ). netflix is using jquery and I had a chance to sit down and talk to him about that.

When it was still in Boston, I happened to meet Bill Scott. Bill is the leader of Yahoo's Yui team and a good speaker (although he only gave a five-minute "lightning show" about his current job in Boston "). Some time ago, he started Rico framework development and then switched to Yui. Then, a year ago, he left Yahoo, went to Netflix, and led the team to do a lot of work-not just JavaScript (more focused on their new APIs and user experience ). Netflix is also using jquery, so I have the opportunity to sit down with him and talk about these things.

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) 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.

Here, I should be careful and remind all readers who are reading this article that I have no bad words about jquery, I also don't want to provoke a meaningless debate in this article or other articles. Jquery and mootools (as well as prototype, dojo, Yui, etc.) are different and not competing with each other. They solve the problem in different ways, and I personally happen to like the Moot solution and how it tries to solve the problem. Because I am still learning jquery, it is easy for me to write some incorrect jquery statements. If I have anything wrong, please forgive me.

Programming to the pattern programming mode

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 impact ect, 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 other ways, it's possible for me to do almost entirely one or the other-though not 100%.

In my conversation with Bill, I talked about some of my thoughts on "programming patterns. My so-called "programming mode" is like this: when I write my code, I can choose to be an architect or code writer. I can design or implement it. In fact, I have to do everything, but I have to choose one that I want to do, and in many cases, whether it's me or others, almost all jobs can be done by one person, although not 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 snags 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.

What am I talking about? Let me tell you this: if you write 20 lines of code to describe the user interaction on a page to make the page look pretty or easy to use, is it worth writing five or ten more lines of code to make it reusable? If you program directly based on experience, you need to write it over and over again. However, if you write in the mode, fewer and fewer code will be written.

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.

Assume that there is a user verification: When you click "log in", a login box is displayed. When you click "log in", this logon box appears. The user submits the login form. The login box sends an Ajax request and displays a prompt. When the request is complete, this login box tells the user that the user has logged on and disappears after a while.

I cocould 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 wowould 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 wowould in most frameworks these days, as we all borrow good ideas from each other:

I can use JavaScript to show this and write it on the current page or in my full-site code (maybe this login box is available on every page, right ?). It may be such a piece of code (I will omit some code to some extent)-Note: I am using the mootools syntax here, but it looks similar to most of the current frameworks, because we all learn from each other's good ideas:

 
Window. addevent ('domainready', function () {$ ('loginlink '). addevent ('click', function (e) {e. stop (); // don't follow the link $ ('logingroup '). show () ;}); // loginpopup contains loginform $ ('loginform '). addevent ('submit ', function (e) {e. stop (); // don't submit the form $ ('loginform '). send ({oncomplete: function (result) {$ ('logingroup '). set ('html', result); // show the result (function () {$ ('logingroup '). 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? Cocould we ever see a part of it again? Certainly, a popup that contains a form that submits, updates itself and then does something cocould crop up again. Right?

Beautiful and straightforward, right? But let's move back and ask ourselves: what is this model? Can we see another part of it? Of course, a pop-up layer contains a form, and then submits and updates itself. Then, it does some other things and can appear again. Right?

This is what I mean by "programming the pattern ". in my old code, I wowould 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 wocould 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.

This is what I call "programming mode ". In my previous code, I may write code as above. If it is part of my website, I may have a namespace and give them a method called "showlogin", and then call mysite. showlogin in the on domready event. Or, it is more likely that my website needs many such methods. Showlogin, logout, maketooltips, autoscroll, setupdraggers, and so on. Then I will write a method called mysite. init to call all these methods.

But even moving back to my older code I wocould have just had a giant domready method with all these layout/interaction instructions all in one big startup method.

But looking back at my old code, I may have a huge domready method, which includes all the layout and interaction commands and a large startup method.

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.

If you have never written such code, you will never know the fun of maintaining the code. It will spend a lot of energy to understand what should be done after the first thing. Let's look back at the sample code above. Imagine if we encounter something similar, but there are three times, five times, or 10 times longer, then imagine that we will encounter similar things again a year later. Just splitting these actions is terrible.

Now, let's program the pattern. a popup, with a form, that updates itself. that's a pattern that cocould totally crop up again. here's the same thing as a mootools class:

Now, let's program by mode. A pop-up layer has a form and is automatically updated. This is the pattern to be repeated. The following is a mootools class that implements the same thing:

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:

It is undeniable that my class is already two times longer, but it is still not associated with my login link. To make it take effect, I also need to initialize it:

 
Window. addevent ('domainready', function () {New popupform ($ ('loginlink'), $ ('loginform'), $ ('logingroup'), {oncomplete: function () {(function () {This. hide ();}. delay (1000, this); // wait a sec, then hide the popup }})});
 

Trade-offs, but big benefits have some trade-offs, but they pursue the greatest benefit

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 tables, too more lines of code and saved me a lot of time in ways I hadn't originally considered.

In addition to the previous code, I also need nine other lines of code to do this. 15 lines of code and 42 lines of code seem not a good deal, but I recently wrote this in all my code. By changing to this way of thinking, I have been freed from writing a lot of code segments, saving a lot of time that I didn't consider before.

* 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 callthem.

* My code is clearer and easier to read. I have some very small ways to do only one thing, but I know what they are doing and why. The names of my classes describe what they are going to do, and they are very small. They only do one thing. If I need a class to do two things, I will write two classes and a small control class to call 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.

* My code can be used repeatedly. If this mode appears again, I do not need to write the code again. I was intimidated by the frequency of their appearance. I never thought about reusing code for less than a week, but now I start to use them 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.

* My applicationsProgramWhere -- my current webpage is, I usually have very few code. I don't want to write much code to a page. All I do is instantiate some classes for each given page element. These small "footprints" (page execution time ?) This means that the less code, the better for the page.

* 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.

* When does it need to be reconstructed? Maybe I have a new version of the Framework I am using, or I have found a new browser bug, or if a browser hits the market (such as chrome), or I find a bug in my own code (this is the most common of the reasons ), I need to fix them immediately. If I have written code for each page, I will need to fix it one by one. In another aspect, if my page only instantiates several of my classes, I only need to modify my classes. Because I control the class interfaces, I can completely rewrite my classes without having to access the code that instantiates them.

* 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.

* Finally, I completely changed my way of thinking about developing user experiences. I prefer to develop an experience and reuse it instead of creating a new one from the beginning. This can create a consistent experience, which means a better user experience for me.