Should I convert from MooTools to jQuery? [closed]

问题:

I have a fairly large codebase that depends on MooTools v1.11 and am about to convert to version 1.2. Since this is a pretty major overhaul, I've toyed with the idea of converting to jQuery.

Anyone have advice on whether to update to jQuery or just stick with MooTools?

I mostly use MooTools for Ajax, drag and drop, and some minor effects.

回答1:

If you're upgrading anyway, then it may be worth looking into.

jQuery seems to be well on its way to becoming the One True Javascript library (given that MS and others have decided to embrace it), so if this is code you intend to work on for a while, then it's probably a good idea to switch at some point (if only because there will be more places to get help and plugin code, as it's very likely to continue to be popular for a while, which will help ensure the long-term flexibility and maintainability of your code). So, given that you're having to convert it anyway, now might be the best time to do it.

I think jQuery becoming the framework to use is a good thing. It wouldn't have been my choice (I like MooTools, too), but it's certainly an excellent bit of code and definitely fits the purpose with at least the competence of its competition. I'm happy to see any kind of consistency, and I will be moving my code to jQuery at some point.

回答2:

If it's not broken. Don't fix it.

jQuery might have X or Y but if everything is dependent on MooTools, you might have a lot of work ahead of you to convert from MooTools.

Keep MooTools if you used it extensively through out your site. However, if you only have 2-3 pages with minor effects... the change might be worth it.

回答3:

Why make the switch? I've converted code bases from 1.11 to 1.2, and it's pretty quick and easy (and I'm using it for more than just a few effects).

jQuery may be adopted by MS, according to one site it performs better in IE - but this is not about how well it does with IE, it's about how well it works for your site (is IE a major player on your site?).

Do you know jQuery? If you don't, then you've got to rewrite the code from scratch, and you'll be rewriting your code altogether.

Or are you just trying to come up with reasons to tell your manager that "we should do this in jQuery" because you want to learn it?

As far as "the one true framework" - that's a ridiculous claim that only users make, not developers.

回答4:

The switch from MooTools 1.1.1 to 1.2.1 isn't that big of a deal. http://github.com/mootools/mootools-core/wikis/conversion-from-1-11-to-1-2

There's even a compatibility layer that makes MooTools 1.1.1 code function in 1.2.x. You may have to manually fix a few things here and there, but it's relatively minor.

Switching to jQuery, or YUI or DOJO, or anything else would require completely throwing out all the code you have and stating over. No client of mine would ever allow that kind of waste.

Also, if you're used to coding using proper MooTools Classes, then jQuery may come as a huge shock to your system. It's not that jQuery forces you to write unreadable and unmaintainable code, it's certainly possible to code very readable and maintainable code in any language. But jQuery has no built-in Class system to help you.

Especially with a large codebase, it is important to keep your code nicely organized.

I am quite biased of course.

回答5:

There's a site up about it describing the differences in philosophy jqueryvsmootools.com

I think that's what it comes down to in the end. A functional DOM centric approach or an Object Oriented JavaScript approach.

回答6:

As others have pointed out, jQuery is a library (for toying with DOM mostly), Mootools (1.2) is a full fledged javascript framework that allows you to organize your code in an object oriented fashion and thus keeping it easy to maintain.

I recommend you read this to really know what each one really is (jqueryvsmootools.com)

And this other link, so you know how to get best from both worlds ;):

http://ryanflorence.com/object-oriented-jquery-with-mootools-pigs-take-flight/

In the end it boils down to what you need. My general recommendation: if you need to grab some quick snippets and fancify your web application jQuery alone is good; if you are going to center your development in javascript, you should really try mootools: the code will scale and you should better be ready.

To upgrade your code from Mootools 1.1 you can use the upgrade helper, it will help you identify the code in conflict through the javascript console (mootools.net/blog/2009/12/31/mootools-1-1-upgrade-layer-beta/)

[Sorry for posting only 1 active link, this is my first answer]

回答7:

It depends on how well you know jQuery and what your deadline is. If you know it well, it does take less lines of code, which means less bandwidth for your customers.

Also if you look at this site you can see that in the leading browser IE, jQuery has better performance than Mootools.

That being said, if everything is working in Mootools v1.11, why are you updating the scripts at all? Like the previous poster says, if it's not broken...

If it is not working properly in Mootools v1.11, how do you know it will work in Mootools v1.2 or even jQuery for that matter? It would be a shame to put a bunch of development time and either have some of the same bugs, or introduce new bugs because of the framework you use.

回答8:

At this point Slickspeed is becoming totally unimportant, selectors are too fast anyway. Also just so you know, Sly by Herald Kirschner, a member of the Mootools dev team just released Sly, a selector engine that beats Sizzle. The stuff about animations being the defining factor for NOT choosing mootools that was left by one of the posters was basically ass backwards, Mootools has been the king of animations for years now. Whatever you pick it will all work. Mootools has a more classical feel that I think keeps me organized, jQuery is more function based and does not venture into classes that much. An one augments native types and the other doesn't, a different strategy but that is it.

• Daniel

回答9:

I'm quite happy with Mootools. I've been tempted several times to try out jQuery because more and more people are using it these days, but somehow I still still don't get the nice OO feature like Mootools does. Another thing that I don't really like about jQuery is getting id with the dollar function by adding the hashkey(#). This can be problematic if you want to create html ids using the framework. If I were you, just upgrade to the latest version of Mootools. Mootools is not a bad library at all.

回答10:

In your question you mentioned that you're using MooTools for "Ajax, drag and drop, and some minor effects". While Mootools can do that well, (and I may get blasted for saying this) in my opinion you're not really using Mootools for the right reason. We use Mootools in our applications, and really we cannot think about substituting JQuery for it. If the aim is to write object oriented, long term maintainable code that other applications in your organization can leverage, Mootools wins hands down.

And just selector speed is a wrong criteria to judge by (though I believe Mootools is up there now). Most places in our code we already have references to the elements we want to change. The most time is spent in actually manipulating the DOM once you have the element, and in our internal tests (will try to publish them) Mootools is much faster than JQuery in the usual kind of operations we perform. Our applications are the kind where we rely on previously built Mootools controls (built by us or others) to create application screens using data coming in from Web Services.

回答11:

Asses if you have the programmer hours to do the over haul.
Doing so will mean that you are going to rewrite the code from scratch. This again implies that you will have to go through the cycle of functionality, review, and test, fix bugs etc. That said one of the most important problems programmers not-so-competent with JavaScript make is that most pieces of code accessing DOM elements tend to create memory leaks (which is the highway case for most web developers). jQuery by nature does a lot to mitigate this. Or rather jQuery takes away the JavaScript from JavaScript.
2nd. one of the more compelling reasons to move to jquery is that your JavaScript code weight will decrease dramatically. This makes sense for a client side code intensive page. The concise nature of jquery will allow you to easily review code too.
The company I work (support.com) with had tons of Mootools code. During the start of 2008(after heated hours of debating-for which I was against moving to jQuery) we started migrating to jQuery in a phased manner. I haven’t regretted till date.

回答12:

This argument is boring, Mootools is O-O so people form a proper O-O background appreciate its intelligence more than people from a PHP4 or HTML background.

回答13:

The only compelling reason I could give for such a migration would be if making the switch would reduce the amount of code you have to maintain, and/or make things simpler. There is usually a lot of work involved in such a switch, so you would want to be able to go back after all that work is done and say "Yeah, it was worth it."

回答14:

You should take this choice based on the purpose of your application.

jQuery is amazingly cool for animations, however I feel Mootools is more sophisticated, so If the important thing is the app and not the animations stick to Mootools

Speed is also a subject on this. As of today Mootools has a slightly slower performance but I rather not pay attention to it until Mootools 1.3 is released.

Checkout performance of the latest frameworks at http://slicktest.perrohunter.com

回答15:

JQuery is a smaller codebase with wider support. If it meets your needs it might be a good switch. I would say that the trade off that you need to decide on is whether the migration effort and learning curve are worth the effort versus the wider feature set, smaller code size and popularity and support for JQuery.

If the change between versions of MooTools is really that steep then the migration might well be justified.

回答16:

The article referred to at the jqueryvsmootools website puts it quite nicely:

If jQuery makes the DOM your playground, MooTools aims to make JavaScript your playground

So, coupled with the answer here "If it aint broke, don't fix it", I'd say address your needs and not public opinion.

Given that your site is already in Mootools, you need to assess whether jQuery offers anything you need which MooTools doesn't offer; and whether the bother of converting is less than the bother of writing the extension.

It seems that jQuery has the ability to quickly allow you to play with the DOM, but all the extra fancy stuff and other areas of work (like Dates) requires a plugin.

This helped me to answer my own question too!

There are some areas where they don't overlap, which is a pity. GUIs are easy to put together in jQuery, with lovely widgets and animations. MooTools, I find, either have sets with too few features, or are too heavy for general web use.