Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>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.</p> </blockquote> <p>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 <code>new Array()</code> vs <code>[]</code> to how you structure your app. </p> <p>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 <code>Class</code>. And the fact that you can abstract having to deal with prototypical inheritance by passing an object to a special constructor <code>Type</code> function that returns your instance is ... oh wait. It looks different but what it does pretty much sounds like normal javascript. Only easier -- why <em>wouldn't</em> you prefer that? </p> <p>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 <em>a lot</em> 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. </p> <p>The thing is, you cannot <em>directly</em> compare a MVC framework with MooTools, it is not the same. At all. You can compare the so called Model constructors vs Classes. </p> <p>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.</p> <p>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 <em>use</em> I don't mean I can't use it but it feels awkward to <em>extend</em> and build on. I am sure it's just down to experience, though, have yet to read all the backbone patterns examples out there.</p> <p>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 <code>Backbone.sync</code> 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.</p> <p>In MooTools, I would have just extended my Model class and could have defined a custom Class Mutator property (like <code>Binds</code> or <code>Implements</code>). Done. Write what you know, they say, and not for nothing...</p> <p>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. </p> <p>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. </p> <p>There are other attempts. <a href="https://github.com/lyonbros/composer.js">Composer</a> 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.</p> <p>Garrick Cheung released a framework called <a href="https://github.com/GCheung55/Neuro">Neuro</a> which has huge potential.</p> <p>I wrote <a href="http://dimitarchristoff.github.com/Epitome/">Epitome</a> - 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.</p> <p>SeanMonstar released Shipyard, which is used by Mozilla Flight Deck - <a href="http://seanmonstar.github.com/Shipyard/">http://seanmonstar.github.com/Shipyard/</a>. Whereas it's not native mootools, it's mootools-ish with mootools class etc - only w/o extending natives, so a great alternative. </p> <p>BTW, try irc.freenode.net #mootools or the mail list and you will always get a good answer.</p> <p>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, <a href="https://github.com/mootools/prime">Prime</a>) 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 <code>hasOwnProperty</code> checks. Anyway... </p> <p>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!</p> <p>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... </p> <p>In the interests of full disclosure - you will find it MUCH harder to find a decent mootools dev when you recruit. Cannot be ignored...</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload