I agree that there are plugins for jQuery all over the place, but it’s not hard to find the really useful made for mootools as well. It’s also pretty easy to write own classes which just use the Mootools power. With inheritance you can modify existing mootools features, which I personally do all the time.

If one will think only about using the framework – mootools is actually just two things: Classes and Events. Attaching Events to Classes is priceless. In example I have a class called Layout with parameters like Sidebar, ContentWindow. Layout itself does nto have any representation within the DOM (opposite to Sidebar and Content). Sizes of the Sidebar and Content will change on browser window resize. These will change if I’d resize the Sidebar as well. It’s enough to create Layout’s “resize” event and fire it on window and sidebar resize. If I’d add another element which will be affected on the Sidebar or browser window changes, I’m just creating an event for it and ordering Layout’s “resize” to fir it. Everything is working fine.

I know it can be done with jQuery and without the abstract Classes. I just think that looking at the code which uses mootools after half a year I can read it and understand. Sure it’s driving me crazy how stupid I was to not use Events or Options or anything and it lands on the refactoring list, but it’s easier to change code within Classes making them backwards compatible.

And to all flame warriors. It’s not what is better, it’s about what better suits you. You have to try both and decide instead of listening to some other person advices. It’s like buying a car without a test drive (I’ve done it and I’m happy, but it was a clear luck).

Here is how I see the two libraries: Mootools tends to be classical and extensible in modality and jQuery leans more toward functional, instance-based operations.

Think of this analogy:

jQuery to me is a nomadic tribe, it can move fast and setup its teepee quickly, where as Mootools would be more like a settler who builds a farm structure that consistently produces crops and reuses the same field with great efficiency.

Here is an example of what I mean:

In Mootools to inject an element somewhere you do – thisElement.inject(thatElement, ‘where’) – the ‘where’ is an optional string that indicates where to inject ‘thisElement’, which can be ‘top’, ‘bottom’, ‘before’, and ‘after’. So the same function is used with a specified option to determine the place of delivery.

Here is the jQuery approach, 8 functions with different names:

append( content )
appendTo( selector )
prepend( content )
prependTo( selector )
after( content )
before( content )
insertAfter( selector )
insertBefore( selector )

Holy guacamole Batman that is a lot of different functions to remember!

So I just like being able to think in my head: “Well I need to put this somewhere, where should I inject it? Oh, it needs to be at the top! so – this.inject(’targetEl’, ‘top’)”

Just makes sense to me more than the jQuery way, but I guess someone could just a soon point out that I have the memory of a goldfish and I should just grab some handy jFlashcards and be done with it…but I LIKE that Mootools can organize it all for me…so I digress.