Sunday, September 21, 2008

Initial MochiKit=>JQuery Notes/Thoughts

First off, I decided to keep "$" as a document.getElementById alias, rather than let it be jQuery's alias (which it is by default). I did this because:
A) even with jQuery around, a document.getElementById alias is still useful
B) this way I didn't have to change nearly as many lines of existing code

But since I hate unnecessary long function names, I kept jQuery aliased to "$". Anyhow, here are a few specific comparisons between the two:
  1. A Better For/Each Function:
    forEach(someArray, function(value) {
    console.log(
    value);
    });

    becomes:
    $$.each(someArray, function(index, value) {
    console.log(
    value);
    });
    If your variable's type isn't important, you can also do:
    $$.each(someArray, function() {
    console.log(this
    );
    });

    but since "this" has to be an object, using it changes the type of the value to be "object" (even if the array was of primitives).

    Basically the two libraries have the same thing, just implemented differently. I love that jQuery provides an index variable, but I hate that they make it the first argument to the callback. If they'd only made the value array the first argument (as they did with their map function), I wouldn't even have to specify the index arg in the nine out of ten times I don't need it.

    So, while jQuery wins in the 1 out of 10 times I do need an index variable, MochiKit is a bit more convenient the rest of the time.

  2. Getting an element by its ID:
    var a = $("someId");
    becomes:
    var a = $$("#someId");
    but that's not really an accurate comparison, because "a" goes from being an HTML DOM element to being a jQuery results object. To get the actual HTML element, you need to do:
    var a = $$("#someId").get(0);
    Once you're used to working in jQuery land though, you find you often would rather have a jQuery results object though, as everything in jQuery "chains" off of such objects.

  3. Event hookup:
    connect(someElement, "onclick", clickHandler);
    becomes:
    $$(someElement).click(clickHandler);
    Now this is where jQuery really started to shine for me. By making the event types the name of the connection methods, jQuery eliminates the need to have "connect". But the brevity doesn't stop there. Let's say you want to connect an element that you don't already have as an object. In MochiKit you'd have to do:
    var button = getElementsByTagAndClassName("input", "submitButton");
    connect(button, "onclick", clickHandler);
    but with jQuery, that is reduced to a single line:
    $$("input.submitButton").click(clickHandler);

I'll probably have more direct comparisons later, but even with just what I've seen so far, I'm already thinking about revising my migration plan. Essentially all I want out of MochiKit is the utility functions that jQuery doesn't have, and the createDOM aliases. To get them I was going to create a MochiKit-jQuery plug-in. However, almost all of the functions in the MochiKit Base library aren't in jQuery, so it seems sort of silly to make a plug-in for them. Instead, I think I'm just going to keep using MochiKit Base "as is", and then make a jQuery plug-in for the createDOM aliases (by the same logic I could also just include MochiKit DOM, but then I'd have to include the Iter and Style libraries as well, and that is a lot of duplication of functionality).

1 comment:

brad clements said...

thanks for posting at least 2 posts about mochikit->jquery

I'm going down that road now, wondering about Signal..