Daniel's Corner

I know I promised a review of jQuery and Dojo Core, but I still haven’t had a chance to review them. But rather than let another week go by without a word, I thought I’d write about something more personal:

I’ve been living in Germany about 9 months now (6th country I’ve lived in). In this time my knowledge of German has improved significantly. Learning my third language has been an interesting experience, and in many ways it was more different from my second (English) than I had expected.

For example, when I learned English, there was a long period of time where I could understand much more than I could speak. I thought that this was natural when learning any language and was surprised to find that this is not the case with German. With German I have always been able to say more than I can understand. The main reason is the huge variation in how German speakers talk. I’ll explain:

For us born in the Americas, we are used to a very homogeneous language. The differences between different Spanish-speaking regions (Mexico, Argentina) or between different English-speaking regions (Ontario, Texas) are nothing compared to the differences between different German speaking regions. Each region in Germany speaks its own “dialect”. German dialects vary smoothly so that a person can always talk easily with someone from neighbouring towns, but over a larger distance, the dialects become mutually unintelligible. A speaker from northern Germany could not communicate with one from southern Germany, were it not for the fact that they have both learned “High German” in school. To them, “High German” (the official language) is more or less a second language. If you “learn German”, High German is what you learn, but there are few regions in Germany that actually speak it natively.

For those of you familiar with Spain, think of the difference between Castellano and Catalán.

The situation with writing is better, but not much. Similar to Spanish but unlike English, in German people write more elaborately than they speak. Sentences are longer, words more complex and they even use different verb conjugations.

I have to say that it is a weird experience to have a one-way communication where I can talk to my girlfriend’s parents but I can’t figure out what they say. But all in all, learning German has been a fascinating and rewarding experience, and I look forward to being a true trilingual.

Edited to add: Someone pointed out that “Dojo Core” can be considered a base toolkit. I will review Dojo Core along with jQuery in next week’s post.

Today I’d like to shift focus and talk about choosing an AJAX toolkit. Unlike most reviews, I will not do a feature comparison. There are many reviews that do that and I’d bring nothing new to the table. Instead, I will talk about aspects which I consider very important but are overlooked by a mere feature comparison:

• Does the toolkit try to change the character of the language?
• Does the toolkit make good use of JavaScript features?
• Does the toolkit help you learn to use JavaScript as it was designed?
• Does the toolkit introduce the risk of breaking valid JS code?
• Does the toolkit smooth out cross-browser incompatibilities or does it add new ones?

These issues are subjective and hard to assess, but are nonetheless very important. JavaScript is a very powerful but very unique language. Using a toolkit that denies the nature of JavaScript and tries to kludge it into behaving like something it’s not is to deny yourself the opportunity to learn the full power of the language.

I’ll quickly divide AJAX toolkits into two groups:

Base Toolkits

Light weight. They include core functionality like DOM tools, utility functions, etc but for example, no GUI widgets. Examples include Prototype, MooTools, jQuery and Mochikit.

GUI frameworks

Heavy weight. They include GUI widgets like trees, tabs, dialogs and drag and drop. Examples include Dojo, YUI, Ext and Script.aculo.us.

These two groups are very different and should not be compared directly. Yes, the distinction is not clear cut, but you have to draw a line somewhere. In this post I will only look at base toolkits. I might look at the GUI toolkits another time.

Skip to: Prototype | MooTools | Mochikit | jQuery

Prototype (up ^)

Prototype is a popular AJAX toolkit and its supporters are not going to like what I have to say about it. The problem is that it:

• Pollutes the global namespace with many functions.
• Modifies base classes of JavaScript.
• Tries to change the nature of the language.

I have a big problem with libraries that modify the JavaScript base classes. These extensions are not necessary (jQuery is living proof). For example, would you like the Array object to have an “each” method? Sure. But we don’t need to extend the Array object to do that. Look at how jQuery does it:

// jQuery
$(myArray).each ...

// Prototype
myArray.each ...

jQuery’s version only adds 3 characters and it leaves the base class intact.

What’s wrong with extending base classes? It can break existing valid code, it can break other libraries, it makes the library less portable and it makes it harder to tell which features are part of JavaScript and which were added by the library.

Consider the following code for example:

var myFriends = ["Joe", "Janet", "Jason", "Jess"];
for (var i in myFriends) {
	... do something with myFriends[i] ...
}

This is valid JavaScript and Prototype will break it. Ok, there are reasons why you might want to avoid for-in loops altogether, but that doesn’t excuse Prototype breaking valid JavaScript.

In addition, some of Prototype’s changes are not cross-browser. Cross-browser programming is hard enough as it is, and one of the things I look for in an Ajax library is to smooth-out differences, rather than add more of its own.

Prototype doesn’t just extend base classes, it tries to fundamentally change the nature of the language. For example:

The Hash() object

Why do we need a Hash() object? JS Objects already provide this functionality:

/* Prototype */
var myHash = new Hash();
myHash.set('name', 'Bob');
myHash.set('age', '21');
var name = myHash.get('name');

/* JavaScript */

// Option 1
var myObj = { name: 'Bob',  age: 21 };
var name = myObj.name;

// Option 2
var myObj = {};
myObj.name = 'Bob';
myObj.age = 21;
var name = myObj.name;

var Person = Class.create({
  initialize: function(name) {
    this.name = name;
  },
  say: function(message) {
    return this.name + ': ' + message;
  }
});

But JavaScript doesn’t need classes. JavaScript is a fully OOP language, it just has no classes. JS has lambdas, closures and prototypal inheritance and a very powerful object system. These are extremely powerful features and they solve the problems that classical inheritance is meant to solve.

See also:

• Prototype.js enumerable sugar not so sweet.
• How Prototype extends the Dom

MooTools (up ^)

My feelings about MooTools largely echo those about Prototype. Like Prototye, MooTools modifies base classes with similar consequences as Prototype. In particular, MooTools and Prototype cannot co-exist in the same program.

It’s not that I enjoy mixing libraries, but I expect that any well-designed library be properly encapsulated and can be added to an existing application without introducing bugs. Basic encapsulation is very fundamental. We wouldn’t tolerate this behaviour in Java or Python, why should we tolerate it in JavaScript?

MooTools also pollutes the global namespace with its own functions. I believe that libraries should contain all their functions inside a single namespace and not touch anything outside it. That ensures that the library plays well with other code.

MooTools also tries to emulate class inheritance in JavaScript, but over-all they don’t seem to try as hard to make JavaScript into some other language. I do understand that a lot of people want this kind of emulation, so I don’t hold that against the library.

Mochikit (up ^)

I like Mochikit, I really do. It does not extend base classes and does not seem to try to change the character of JavaScript. It does insert new global functions, and I wish it didn’t. But Mochikit is nonetheless a library that I would be quite happy to use in my programs.

Mochikit appears fairly well documented. That said, I’m concerned that I could not find any tutorial-style (task-oriented) documentation which is important for new users. Task-oriented documentation is very important and regularly overlooked.

Here is a code sample from Mochikit. It demonstrates DOM manipulation:

var rows = [
    ["dataA1", "dataA2", "dataA3"],
    ["dataB1", "dataB2", "dataB3"]
];
row_display = function (row) {
    return TR(null, map(partial(TD, null), row));
}
var newTable = TABLE({'class': 'prettytable'},
    THEAD(null,
        row_display(["head1", "head2", "head3"])),
    TFOOT(null,
        row_display(["foot1", "foot2", "foot3"])),
    TBODY(null,
        map(row_display, rows)));
// put that in your document.createElement and smoke it!
swapDOM(oldTable, newTable);

We see several new global functions (TABLE, TR, THEAD, TBODY, TFOOT, map, swapDOM). Otherwise, I like the code. Notice that Mochikit does not try to invent its own arrays or hashes. I saw this a lot while reading the Mochikit code samples. They use the native JavaScript objects throughout.

I was pleasantly surprised that I could not find any functions that try to push classical inheritance into JavaScript. Instead, I found several functions for functional programming (partial, map, filter) and even prototypal inheritance! (merge). I’m impressed.

Mochikit has a very interesting set of tools called MochiKit.Iter, which provide additional functional programming features like lazy iterators. Lazy evaluation is a powerful feature of functional programming.

I’m pleased to see that Mochikit has paid attention to the functional aspect of JavaScript. Functional programming is one of the sources of JavaScript’s power and I like to see a toolkit that encourages this approach to programming.

jQuery (up ^)

I owe you this one. I promise to add a review for jQuery soon. At first sight, I like it a lot. It seems to make good use of JS features, and its functions are contained in a namespace. But I don’t have enough time today to give it justice.

Next week I’ll also try to cover Dojo Core. Dojo Core is a subset of Dojo which can be considered a “base toolkit” in its own right.

In my previous post I talked about how to do prototypal inheritance in JavaScript, based on Doug’s presentation (which is part 1 of a 3-part series). In the same presentation, Doug introduces “Parasitic inheritance” in JavaScript, which is actually very much like classical inheritance, and it works remarkably well:

var Person = function(name, age) {
    /* "age" is a private variable */
    return {
        name: name,
        birthDate: function() {age += 1; return age;},
        setAge: function(n) {age = n;},
        getAge: function() {return age;}
    };
};

var Employee = function(name, age, group) {
    var e = Person(name, age);
    e.group = group;
    return e;
};

Notice that the sub-class Employee also has access to the private variable name. And how do we create objects? You can just call the functions:

var joe = Person("Joe", 31);
var sam = Employee("Sam", 24, "Sales");

Or if you prefer the traditional syntax:

var joe = new Person("Joe", 31);
var sam = new Employee("Sam", 24, "Sales");

The two options are equivalent, and they work the same!

And a neat property is that the objects created by these constructors are compatible with the prototypal inheritance we saw earlier:

/* object() defined in the previous post. */
var alice = object(joe);
alice.name = "Alice";
alice.setAge(27);