MooTools Development in Dojo Land

by keif on June 3, 2009

I am a MooTools JavaScript developer. I love the framework, and in writing MooTools code, I’ve become a better Object-Oriented-Programmer, and a better JavaScript developer. If you follow technology, you know there’s multiple JavaScript frameworks – jQuery being the most popular (IMO), with Dojo Toolkit being the most used in enterprise applications.

After having used JavaScript libraries (originally prototype/scriptaculous, some Moo.FX, then jQuery, then MooTools, and currently a project using Dojo) you come to expect a certain amount of consistency in general concepts, and in that expectation, the libraries have delivered.

$, $$, dojo.query, dojo.byId, document.getElementById – give me my element nodes!

So, basic JavaScript, people have developed a few different ways to get the elements they want, including custom functions – like Robert Nyman’s getElementsByClassname – which take advantage of local browser support, but you’re still forced to account for those without it. *cough*IE*cough*

MooTools uses the $ or $$:
[code lang=”javascript”]
var idEx = $(‘someId’); //get element by ID
var arrayEx1 = $(document.body).getElement(‘someElement’); // return first matching ‘someElement
inside of ‘someContainer’, or document.body in this example
var arrayEx1 = $(document.body).getElements(‘someElement’); // return array of ‘someElement’ (or class name, if you have the right components downloaded) that are contained inside of ‘some container’, or in our example, document.body.
var arrayEx2 = $$(‘someElement’); // return array of all found ‘someElement’
[/code]

Pretty powerful stuff, for so basic an idea.

jQuery is kind of similar:
[code lang=”javascript”]
var someArray = $(‘someElement’); // return an array of those elements/that ID/etc.
[/code]
Very powerful for a single selector – but it has the added bonus that they’ve allowed it to be overwritten, so you can use jQuery with another library (say, MooTools) that also uses the $ selector. It took me a little bit to get used to the return of an array outside of a single element.

Dojo does things a little differently
[code lang=”javascript”]
var someArray = dojo.query(‘someElement’); // return an array of elements
[/code]

The get(‘selector’).get(‘selector’) (like mootools $(some).getElements(‘someElse’)) can be pulled off in dojo/jQuery, but perhaps not as intuitive, in my opinion (again, I’m biased as a long-time MooTools fan/developer).

Which is better?

I can’t say which JavaScript library is better. Perhaps more-so, I don’t want to. It’s moot. You pick the library you’re most comfortable with, and most importantly, for your Clients – you pick the one that they’re development team can run with for the long-term.

How to choose a JavaScript Library – the condensed version

I’m a life-long student, and a professional developer – I’ve coded many languages, and I’m learning others, so it’s easy to see certain correlations that have started popping up.

MooTools… is definitely for the JavaScript Developer, and if you’re Object-Oriented as well, it’s even better.

jQuery… is for the designers out there who know some xhtml and want to get some JavaScript without dealing with the headaches it can bring. It’s go ta low barrier of entry, but I’ve thought of this Thomas Jefferson quote:

That which is Popular is not always Right, what is Right is not always popular

Don’t read too much into that. I just infer that people that say it’s “the way” have some additional education to do in general.

Dojo… is for the Java Developer crowd. As I’m delving more into Java, I see the strong similarities, and see why it’s involved in a lot of Java-based enterprise solutions – you could jump back and forth between Dojo and Java and feel pretty comfortable.

Coding Syntax, Preference, What’s Left? DOCUMENTATION!

This is the area most things suffer in – either too much or too little documentation. I’ve grown fond of MooTools docs structure. It’s easy to find what I need with it’s break down of how the functions are applied – string, array, elements… Easy!

jQuery docs are along the same lines, but I have difficultly in navigating them. I blame myself because of my long-term familiarity with MooTools, it’s become second nature, so jQuery is still slightly foreign.

Dojo docs, in my opinion, are the WORST of the docs. They’re broken down into their three main components (dojo, dijit, dojox), but beyond that it’s a guessing game to get to the API reference you want/need. I was finding myself hitting the wrong sections because the search led me there, but it was not representing what I was searching for.

I really feel their Dojo Campus is a much better doc representation than their dojo book, or their API docs. Their book is incomplete, and if you search and find references to the book, you’ll find items incomplete, moved, referencing different version of the book, to the point you’re better off not even reading it. Along with the occasional example randomly not loading, then working, then not. It was a nightmare!

The problem – perhaps the only problem – with Dojo Campus, is the search functionality. It defaults to “title search” which failed for me 99% of the time (because I needed something in the content, and was searching for the wrong titles). Even worse, the search isn’t even featured on the home page! I had to go four clicks in until I stumbled upon it for this post. (It’s accessible in two: Click on Tutorials and one of the options)

To my understanding, the Dojo Campus is going to become the “new” face of Dojo. And with their continued improvements in coding it’s becoming a stronger contender, and more importantly, more user friendly.

Examples from the frameworks

Every framework suffers from this. Outdated examples, drastic version differences that break code, or multiple version examples. MooTools and jQuery, for the most part, are pretty solid. Dojo, I hate to pick on you, but this is where you hurt the most. I googled – a lot – and the demos – official, sitepoint, others – are all over the place. Version 0.4, 0.9, 1.2.3, 1.3… and what’s worse, no one indicates what version the demo is in, so when I started looking at Sortable Tables, I find out it was made obsolete in another version. Links to non-existent pages in the dojo book… a mess!

In my own projects, it lead me to re-write a lot of items that existed in Dojo, but for a beginner with their library I ran into way too many issues to make it feasible to spend any more time playing with the code.

Overall, my impressions have not changed

MooTools is my favorite, jQuery is a recommended secondary, and Dojo is reserved as a “use it if you have to.” They pretty much throw the W3C to the wind with their coding structures – those dijits generate a mess of divs and classes as a default, to the point that I see the benefit in their examples, but in most of my scenarios, it was overkill (and my fellow devs would kill me if I ever coded something in that spaghetti menner).

It really showcases a difference between people that code for the front-end, and those that work with the front-end but primary experience is the back-end. the code makes sense to the extent in relation to Java code – but in comparing it to the majority of front-end applications, it’s a nightmare.

  • http://sweethomeimprove.com Sweet_Home_Improvement

    Great post.. this is really a great information..This will be useful post.. I will comeback for more..

    Cheers,
    sweethomeimprove.com

  • http://http://www.userinsight.com/solutions/prototyping-and-wireframes prototyping research

    test

Previous post:

Next post: