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).

Sunday, September 7, 2008

JQuery vs. MochiKit

I could go off on a rant here about how MochiKit "used to be cool man, but now they're not". I won't, because I've already done that elsewhere, and it's not exactly very productive. So what I will say is this: MochiKit has a lot of clever ideas, including a few really clever ideas, that most of the other Javascript frameworks don't. But its creator and primary contributors take the "if it ain't broke, don't fix it" philosophy to the extreme, and as a result the "active development community" responsible for the framework is anything but.

Because of this, I've come to the conclusion that tying your project's fate to MochiKit is like investing all your money at the turn of the century in horse carriage manufacturing: fine if your choice only matters in the near future, but in the long term that newfangled "horseless carraige" technology will make you wish you'd invested in automobiles. As a result, I'm now in the process of migrating both my personal projects and the website of the company I work for from MochiKit to JQuery.

Now the first and most obvious problems of doing this are the "you say tomatoe, I say tomatow" issues: each framework has its own name for various functionality they share. On top of that there's the differences in approach of the two frameworks, the most significant being that while everything in MochiKit is a function, almost everything in JQuery is a method. This makes a huge difference in how, say, event handling is done. And then beyond all that there are the things that JQuery just flat out doesn't have that MochiKit does, which I have to try and liberate from MochiKit without taking half a library of dependencies with it.

So, the next few blogs will chronicle this whole transition, both my thoughts on doing it and what I learn about both frameworks while doing it. And at the end, perhaps I'll even have some sort of "the best parts of MochiKit as a JQuery plug-in" to share with the world. Who knows?

Mission Statement

Mission Statement: This blog has none. At best it has a theme, which is already implied by the title (coding). I plan to use this blog to share new tricks I learn, unique solutions I find to problems, and of course the obligatory occasional article of programmer humor (eg. code quality measurement). Hopefully someone out there in that thar intarweb thing will find it useful and/or entertaining.

By the way, for those of you who are wondering about the title, I'm neither a fanatical fan of Wu Tang Clan nor random old martial arts movies, although the title is a pun on "Ghostfaced Killer". I actually got it from Dungeons and Dragons (3.5 edition); yes I am that much of a nerd (plus the title went well with another online moniker of mine, which I won't state out of fear of reprizal from crazy internet stalkers and/or people I've flamed in newsgroups).