Can i use both mootools and jquery

A big part of that is making it easier to extend the prototypes of natives, and take advantage of prototypal inheritance. You can do these things with vanilla JavaScript but MooTools makes it easier and more pleasant. Despite its name, the MooTools Class function is not really a class nor does it create them. It has design patterns that might remind you of classes in a more traditional programming language, but really Class is all about objects and prototypal inheritance.

Unfortunately, using words like "class" are the most convenient way to describe these things, so for the purposes of this article, when I refer to "classes" I'm referring to functions that return objects - which I'll call "instances" - that inherit from a prototype. You pass Class an object above, we pass an object with members like "isAlive" and "eat" and this object becomes the prototype of every instance of that class.

To create an instance, you call it like this:. Now we have an instance of Human. But the important thing is that bob has these properties through inheritance. When we reference bob. JavaScript looks at bob and he doesn't have an eat method, so it looks up the inheritance chain and finds it on the object we passed when we created the Human class. This is true for energy , too. At first glance this looks potentially bad; we don't want all the humans we create to gain energy every time that bob eats.

The important thing to recognize is that the first time we assign a value to bob 's energy, we assign him his own value and we no longer look at the prototype for it. So the first time bob eats, he gets his own definition for energy set to 2. Note that bob 's name and age are unique to him; these are assigned to him when the class is initialized in the initialize method. This whole pattern may seem a little odd to you, but the value here is that we can define functionality for a pattern and create instances of that pattern every time we need it.

Each instance maintains its own state. So if we create another instance each one is independent of the other, but inherits from the same base pattern:. Let's revisit our jQuery faq plug-in.

What would happen if we wanted to add more functionality to that plug-in. What if we wanted to make an ajax version that fetched the answers to the questions from the server? Let's imagine that the faq plug-in was authored by someone else and we want to add more to it without altering it in any way we don't want to fork it. Our only real choices are to either duplicate the faq plug-in's logic entirely remember, it's a single function , essentially forking it, or we can invoke it and then add more logic to it.

Given a choice, the latter seems to save us the most trouble. It would look something like this:. This has some down sides. First of all, our faq class is going to repeat our selector for the definitions, which might be expensive; there's no way to store the retrieved definitions and pass it on for the second time they are needed.

Secondly, we can't add our ajax logic into the middle of the faq plug-in's own logic for displaying the definition. The original plug-in called slideToggle which expands the definition using an effect. This is problematic because this effect is going to go off before our ajax finishes loading. There's no real solution here unless we just duplicate the entire faq plug-in. Now let's consider our MooTools Human class.

It has properties like isAlive and energy and it has a method called eat. What if we wanted to make a new version of Human that had additional properties? With MooTools, we extend the class:. You can see that we've added a lot of functionality here into a subclass. This subclass has all these properties that are unique to Ninjas.

Ninjas start off with an initial energy value of Ninjas get a side. They also get an attack method that lets them kill other Humans , but it costs the Ninja energy. Picking this apart a bit, there are some interesting things to consider here. Note that we have an initialize method in the Ninja class. This would appear to overwrite the initialize method in the Human class, but we can still access it by calling this.

Further, we can control when our logic occurs; before or after the call to the parent. We can assign new values to properties like the energy value and we can define new functionality. Imagine if we could do this with our faq plug-in for jQuery. We could load our ajax and THEN slide open the value.

MooTools has another pattern called a Mixin. Unlike the parent to child relationship that is defined by extending one class into a subclass, you can also define classes that are mixed into other classes to imbue them with their properties.

Here's an example:. Here we've broken the qualities that make a Ninja different from a Human and put them in a class of their own. This lets us reuse this code outside of Ninja. We could then imbue our Ninja class with the qualities of a warrior like so:. Ninja still works as it did before, but Warrior is at our disposal to reuse:.

Now we have a Samurai class and a Ninja class. But look at how little code both Ninja and Samurai took to define. Both of them are similar in that they are humans with warrior qualities, but they are different in that samurais are always, always good, while ninjas have shifting allegiances. By spending the time to write a Human class and a Warrior class, we're able to have three different classes with no repetition of code while maintaining a very granular level of control over when methods are called and how they relate to each other.

Each instance we create has its own state and the code itself is very legible. Now that you have an overview of how classes work in MooTools, let's look at our faq class that we wrote in jQuery and write it as we would in MooTools and then extend it to add Ajax to it just as we did with jQuery.

That's a lot of code. Even if we remove all the comments it's still two dozen lines long. I already illustrated above that we could build this plug-in with roughly the same amount of code as the jQuery version. So why is this one so much longer? Well, we've made it much more flexible. To use the class, we just call the constructor, like this:.

We can access methods and properties of the instance. But what about our ajax functionality? The problem with our ajax extension to the jQuery version was that we couldn't delay the opening of the definition until after it loaded. We don't have that problem with our MooTools version:. Now we have a version of our FAQ class that allows us to get the definitions from the server.

Note that we were able to integrate the new logic in a way that doesn't expand the definition until after the content comes back from the server which we couldn't do with the jQuery version. Also note that we really only had to describe the new functionality the ajax and little else. This extensibility makes it possible for you to create families of plug-ins that offer different shades of functionality.

It also means that you can use someone else's plug-in and alter just the bits that you to be want different if you need to without forking it. Once you do that, you may as well just keep them mootools rather than re-write everything or try to mix frameworks. Personally I'm inclined to say convert it jQuery, since I believe jQuery is eventually going to corner the market. The implication then is that it will convert to jQuery at some point, and so the long term costs to business are probably best optimized by doing the conversion earlier while there's less to convert and mootools is still relevant so you can easily get help with the conversion.

But that's certainly arguable. Whenever I'm given the choice between the two, I lean towards Mootools - especially if I'm intending to do any sort of effects or animations.

Mootools's base FX libraries are far more robust and generate better results cross-browser in my experience. Like others have suggested, you could take this opportunity as a learning experience. If you're satisfied with jQuery and don't feel the need to learn another framework, port the code over. You can't really go wrong with either in the end.

Since you're more comfortable with jQuery, I would just call jQuery. That is, of course, if time is a factor. There is a project that twists and prods Mootools to make it look like JQuery a wolf in a sheep's clothing Odd, this is not something that should be happening, to be honest.

Since mootools 1. That is, if the order of loading is as described:. That's the theory, anyway. If you are seeing a different behaviour, then there is something wrong going on with the browser. There have been plenty of questions on the subject recently, just read through the latest mootools questions. Viewed 3k times. Improve this question. Valli69 Valli69 6, 3 3 gold badges 20 20 silver badges 27 27 bronze badges.

Theoretically yes, though when I tried it produced quite a bit of grief. Add a comment. Active Oldest Votes. Improve this answer. Elliot Bonneville Elliot Bonneville No problem, I'm glad I could help. It is possible to use both libraries together.