Is mootools alternative of jquery + backbone / spine / sprouteCore

Question

I was full time java developers, now I also work on JavaScript. couple of years back when I started learning JavaScript, first library I tried was jquery like most of the people. But it made my life harder, and after sometime I started writing fairly large JavaScript app. It wasn't coming together for me using jquery. I had huge codebase without much of a structure. It was method blocks updating HTML blocks using selectors. Then I tried mootools and obliviously as a java developer it appealed to me a lot. And I was able to write managible web apps having huge code base.

As per my understanding Mootools is not considered a preferred way to write JavaScript because it mimic conventional OO over default prototype-based OO language. So now to really understand javascript and desire of walking with the world, i decided to try other approaches, so again I turned back to jquery, and realise that only jquery is not enough. So started looking at current trending frameworks like backbone, spine, ember.js, sprouteCore. Strangly I found that these frameworks at their core tries to mimic conventional OO like mootools only by having constructors and creating a object of class and reusing this class object to create instance objects. So

• Am I missing something?
• Is mootools way really wrong?
• Mootools project is very alive and releases new versions/features, but I don't see many people talking about it on Internet, also there are no comparisions vs backbone/spine etc.

Answer 1

As per my understanding Mootools is not considered a preferred way to write JavaScript because it mimic conventional OO over default prototype-based OO language.

Where do you get that from? The greatest thing about javascript is that is so loosely typed (see what I did there) - you can write the same thing in a platitude of ways. There are also so many ways to abstract it and repackage it - and this applies from a simple new Array() vs [] to how you structure your app.

If you love JavaScript (or just know it and secretly hate it), you will be fine with MooTools. The API is mostly either native js or ES5 spec or - rarely - an extra utility that also feels 'natural'. The notable exception that stands out is Class. And the fact that you can abstract having to deal with prototypical inheritance by passing an object to a special constructor Type function that returns your instance is ... oh wait. It looks different but what it does pretty much sounds like normal javascript. Only easier -- why wouldn't you prefer that?

A lot is being made these days of the clientside MVC boom and this 'new way of developing apps'. Suddenly, jQuery folks were given the luxury of tap water! I have spoken to a lot of MooTools developers over this and (un)surprisingly discovered that most think MooTools rarely needs anything like that. I tend to agree with them. The only gaping hole is a view controller with templating but there are a fair few solutions.

The thing is, you cannot directly compare a MVC framework with MooTools, it is not the same. At all. You can compare the so called Model constructors vs Classes.

I have now spent a while researching various MVC framework solutions and patterns to see if our new app can be moulded into a 'best practice' shape.

Basically, I tried backbone.js (with and w/o a mootools adapter) and found it awkward to use after MooTools - it felt like a step back. When I say use I don't mean I can't use it but it feels awkward to extend and build on. I am sure it's just down to experience, though, have yet to read all the backbone patterns examples out there.

Typical issue I run into - wanted to have a special Model property that tells it to use localStorage to fetch/save. Not obvious how - examples tend to show you can either route Backbone.sync to one or the other but not both at the same time. I had to actually decorate the function and extend it, keeping the original referenced in case the model did not require localStorage. NOT the best / most obvious pattern to maintain and leaves me dependent on their changes not breaking my code.

In MooTools, I would have just extended my Model class and could have defined a custom Class Mutator property (like Binds or Implements). Done. Write what you know, they say, and not for nothing...

Another issue - it's tightly coupled with data and you cannot reuse models like classes - eg, a User model loads a user and renders through a User Edit view. You then want to create a new customer and suddenly, you cannot reuse the old object that easily and just render the same view but with empty values. I think it will also be down to inexperience on my part or bad architecture.

Ember.js I found slightly more moo-ish as an interface though It did not quite click either. Frankly, backbone was less trouble to setup.

There are other attempts. Composer is one - once again for mootools but it tries too hard to be backbone and is written by people that are relatively new to the framework so I would not call it mature. Knockout etc etc. There's a new one every day, literally.

Garrick Cheung released a framework called Neuro which has huge potential.

I wrote Epitome - a full MVP implementation based upon classes and events and wrapped in AMD modules, feel free to check it out. It also comes with a builder, documentation builder and many little goodies to get you started.

SeanMonstar released Shipyard, which is used by Mozilla Flight Deck - http://seanmonstar.github.com/Shipyard/. Whereas it's not native mootools, it's mootools-ish with mootools class etc - only w/o extending natives, so a great alternative.

BTW, try irc.freenode.net #mootools or the mail list and you will always get a good answer.

Anyway, enough on MVC. The points about MooTools have been made countless of times. Haters will be haters. Those that love it don't look back. If you are a programmer from an OOP background or are looking for something that renders itself well to patterns, do yourself a favour and stick with it. Exciting times are ahead. Roadmap for 1.5: AMD, for 2.0 (aka, Prime) Host object prototyping optional. These have been the two biggest talking-down points in the eyes of critics. No more 'dirty' prototypes so people can get on with using for ... in loops incorrectly on non-objects and without hasOwnProperty checks. Anyway...

Other things to worry about may be of importance. Like, the size of the 'community'. I think having a healthy community is a great thing but even if you look at jquery, the amount of actual contributors vs users is low. The ratio of quality CODE vs good looking effects is bad. The plugins you can use - a lot are not well written or dead and unsupported. When you draw the line, it's a lot less glamorous than you'd think!

I am not saying that mootools or other frameworks don't have these problems. It is fair to say MooTools people and especially the core devs are fairly private and less vocal about what they do. It may send the wrong impressions, I don't know. It certainly is no jQuery. Ultimately - if you have the resources and the know-how, use what works best and what will scale. There are even these that use coffeescript and swear by it. Who am I to judge...

In the interests of full disclosure - you will find it MUCH harder to find a decent mootools dev when you recruit. Cannot be ignored...