When you start developing in any JavaScript framework, you’re stuck wondering where to begin. Everyone’s got a tutorial, and an opinion, but when you’ve got “an idea” and just need to delve into the code to make it happen (say… porting functions? Figuring out the basics?) then sometimes wandering through the API isn’t the best thing you could do.

Suggested Dojo Reading

Sitepen has provided a nice primer on the basic functionality most people start off with in their library investigations, but where to go from here?

Is like a more detailed view into the Dojo API. I’d start here if I wanted to peruse the API in a more logical way then in their API docs.

I suggest reading the Dojo Basics from Dojo Campus to get in deep with querying elements and Dojo Quickstart Events to figure out attaching events.

Understanding Dojo Toolkit

The more I use Dojo, the more I see correlations with Java – and that’s not a good thing. In Java, you have JavaDocs telling you about the thousands of Java functions, parameters, returns you can have. VERY powerful. VERY difficult to learn. Most of the JavaScript frameworks took a different approach – they made what they did powerful, but kept it simple. Easy to read, easy to peruse – like the PHP docs (in my opinion). the function names and organization make total sense.

In Dojo, it doesn’t feel as quite intuitive – for me – and that’s it’s biggest downfall. It has a high barrier of entry, and a large, robust, sophisticated toolkit that you aren’t really expected to know every inch of (like Java), but understand the basics and have an API to refer to when you want to do the more powerful functionality.

Unfortunately, Dojo still feels like it’s in the infancy of this aspect, as navigating to the more complex aspects is a pain. Should my Dojo work increase in the near future, I may invest in a book to try and become more acquainted with the more difficult aspects.

Accessibility in the Framework

I’m seeing inklings in their code with reference to WAI, but I haven’t even *attempted* to fool with that in any accessibility sense. As my current projects haven’t adequately been in need of WAI guidelines, I’d love to see a more thorough analysis.

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.

In PHP you have the time() function to pull the UNIX Timestamp:
[code lang="php"]
$unix_time = time();
echo $unix_time;
[/code]

We don’t have an easy-as-pie solution for JavaScript however – instead, we have this function we can use:
[code lang="javascript"]
function unix_time()
{
// tada!
return parseInt(new Date().getTime().toString().substring(0, 10));
}
[/code]

“Power tends to corrupt, and absolute power corrupts absolutely. Great men are almost always bad men.”

-Lord Acton, in a letter to Bishop Mandell Creighton, 1887

I’ve noticed a disturbing trend that I myself have fallen victim to. I’m seeing sites coded where we do more in javascript for our styling needs and interaction, with no fall back support for non-javascript users. Styles are called explicity from javascript (which requires a lot of transversal to find out “is it this #000 or that #000?”). onclick events. Onblur. Really?

Use the power of your framework!

Don’t do the work if you don’t have to!

For example, mootools allows us to grab any item on the page and add events to it:

[sourcecode language='javascript']
$$(‘a’).addEvent(‘mouseenter’,function(e){
alert(‘you entered the anchor!’);
});[/sourcecode]

Why stop with one event?

(straight from the mootools documentation!)

[sourcecode language='javascript']
$(‘myElement’).addEvents({
‘mouseover’: function(){
alert(‘mouseover’);
},
‘click’: function(){
alert(‘click’);
}
});[/sourcecode]

Using mootools we can make our code totally unobtrusive. No more onclicks littering the pages. We can leave the HREF tag pointing to static pages. We can inject elements on teh fly, so if someone doesn’t have flash/javascript we don’t show certain elements:

[sourcecode language='javascript']
// don’t have flash?
if(Browser.Plugins.Flash.version !== 9) {
// hide stuff!
$$(‘.flashNeeded’).setStyle(‘display’,'none’);
// show stuff!
$$(‘.noFlashNeeded’).setStyle(‘display’,'block’);
}[/sourcecode]

But not to forget our jQuery bretheren (we’re all one big family)…

Let’s do the same in jQuery!

[sourcecode language='javascript']

// single event
$(‘a’).mouseover(function(){
alert(‘you entered the anchor!’);
});

// multiple events
$(‘a’).bind(‘focus’, function(){
alert(‘focused!’);
}).bind(‘mouseover’, function(){
alert(‘moused over!’);
});[/sourcecode]

jQuery doesn’t do Flash out of the box…

At least, I can’t dig it up – but that’s not a bad thing!

The users of jQuery (A hearty, formidable group) have created the jQuery plug-in to detect flash versions!

It’s all a matter of preference and opinion and bias as to whether it should be included with the main library or not.

The Framework Wars are dead.

We see similar abilities in all the frameworks – and instead of bickering about “being the best” we should work on contributing and learning these frameworks.

Toby Miller put it best – “One framework at a time, please!”

One framework at a time, please!

You wouldn’t hand-over JSP code to a PHP client, would you?

I really hate stumbling on sites that think just because there is a “no conflict” version we should just jam as many frameworks together that we can. That, to me, defines a lazy developer. I fight that battle – instead of being lazy and saying “I know this one better, so let’s turn no-conflict on” we should instead be saying “the client uses library X so we should develop accordingly – even if that means learning a new code!