Posted By: Anonymous
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.
- 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.
new Array() vs
 to how you structure your app.
Class. And the fact that you can abstract having to deal with prototypical inheritance by passing an object to a special constructor
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
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…