techno.blog("Dion")

Roberto Saccon has given the Bespin project a nice gift, by porting the Bespin codebase to Dojo. This was a lot of work and is very much appreciated. The obvious question is going to be “Why did you decide to change from Prototype to Dojo?”

Firstly, Ben and I really like Prototype. I am a Ruby guy, so it feels good to me. I talked about it a bit here, and I will use Prototype in many projects in the future.

The state of Ajax frameworks is quite interesting. On the one hand, many of the top dogs have actively learned from each other which has lead to many of them offering similar functionality. For example, Dojo and Prototype can do a good job with DOM selectors, which jQuery is known for.

Although you can do a good job in any of the top libraries, they still differ in scope, and are optimized for certain use cases, project sizes, and functionality wants.

jQuery offers a phenomenal API for doing stuff with the DOM. It feels right. It is also trivial to extend this world, which has lead to the huge number of plugins to do just that. Because of the clean, simple API, we have seen a huge surge in jQuery usage and interest. I would say that it is optimal for designers and beginner JavaScript folk. This is not to say that it isn’t also great for experts. There is large support from folks like Simon Willison. John Resig did something amazing. If you think functional, this will be your cup of tea even above and beyond.

Prototype goes a little further in that it offers more sugar on top of the language itself. Some find the strapping on of methods on core Objects as obscene. Personally, I love it. It just feels so much nicer for me to say array.last() or array.include(thing), compared to dojo.indexOf(array, item) > -1 for example. In fact, looking at a bunch of code has me feeling a touch nuts with all of the “dojo.” items in it. My brain is starting to ignore them.

That being said, Dojo’s purity gives you a lot. It may be more verbose to dojo.byId than $, but we have no namespace pollution.

The community quickly wanted us to package up Bespin in a way that we could share things. We wanted the same, and have natural components (e.g. the Editor, Thunderhead itself), and some didn’t like the leakage of the Editor component requiring Prototype which in turn meant pollution into the global namespaces. With Dojo we can hide away nicely, and can even run a build to become foo instead of dojo if we wanted.

Since the community really wanted it, and someone stepped up and actually did it, we accepted the change. On our codebase it had some interesting side effects. For example, before hand we had Prototype, Script.aculo.us, and a slew of third party libraries to give us a bit of this, that, and the other. With Dojo, they had everything we were needing and more, so we could hg rm external/ and be done. We are also doing Comet work and the like, and it fits in nicely.

The first change here was to get Bespin working in Dojo, but now we have more work to make sure that:

• The codebase feels Dojo-y
• Use more of the Dojo features (e.g. dojo.keys for key handling, CSS store, Comet, …)
• Clean up and package our stuff nicely (e.g. bespin vs. editor vs. th)

If you are a Dojo fan, or fancy getting into it anyway, please join in! There are a few Prototype things left around, so some of the spirit is there.

A bit of an aside…

A big pain with Ajax and components, is the whole “I really like that jQuery UI component, but I am using Prototype already…. grrr”. Simon Kaegi of IBM has been putting together some thoughts and code around a JavaScript module system that would enable you to say “I want service X which happens to depend on jQuery, and service Y which depends on Prototype.” I am very interested to see where this goes. We sorely need it! The annoying problem on the client is that having multiple libraries is not cheap. On the server though? Not as big a deal potentially.

Picture via Dunechaser

I still get asked “what Ajax framework should I use?” frequently indeed. I think that people feel that with my Ajaxian postings I have seen every framework in the world and will have a magic feel for things.

I dread these questions, as context is king for making the decision, and “feel” is a major part of it too. The various frameworks have in many ways come closer together over the years, so making the choice is harder, but also maybe not as big a deal as it once was.

That being said, I really enjoyed Glenn Vanderburg talk about why he prefers Prototype to jQuery. This is the kind of subject that is asking for trouble and foaming at the mouth from people on various camps. Glenn has the kind of nature, wisdom, and touch that makes it hard to think that way. He gives thoughtful points and isn’t trying to cause a stir.

These days, without any real context (e.g. skills on the team, what the project does) I kinda think:

• jQuery is fantastic for taking a website and making it dynamic. Easy. elegant. Beautiful. If I was a designer doing a rich site I would stop here.
• Dojo is fantastic for building a large scale application that will do a lot, and end up with a ton of JavaScript. Everything you need will be found there. This isn’t to say that Dojo can’t be used on the small anymore. The new core is small and fast and good.

Prototype, for me, fits in between these worlds. It is small enough to feel small (not a huge library to learn) yet large enough that I don’t jump out into creating a lot of my own code.

On a recent jQuery project that grew fairly big and I found myself surprised that the core didn’t have certain methods and features. Much of it was small things (one example I remember is array utilities). I would find myself looking around for plugins, wondering which ones are good, and generally having a little bit of a tough time. Then there is a the type system. For something that isn’t strapping on a bit of code to the web site, I actually like Class.extend and the like. With jQuery I would use Traits or Base or something which is fine…. but not just there in the same way.

I get used to myArray.last() and having the convenience methods available to me directly on the objects, even if the puritan in me feels a little strange. Just as Ruby “felt right” to me. Prototype does too (duh, since its heritage). A blend of purity and pragmatism. More often than not Prototype surprises me “oh, wow, it has that function already!” On another recent project that got converted to Prototype, I was able to delete a LOT of code. Utility classes went away. Libraries went away. There is nothing better than the feeling of deleting code. Am I right? :)

So, I agree with Glenn. For me, Prototype is the right balance for many of my projects. I still enjoy playing and using others when the project calls for them, and I am ignoring the huge number of other great frameworks (YUI, GWT, MooTools, Ext, SproutCore, Cappucino, man I could go on forever here).

I created an introductory example discussing custom events as an implementation of the Observer pattern.

The example dynamically adds functionality based on checkboxes to simulate events that could change processing and uses the fire() and observe() methods from Prototype.

I strap on behaviour to a list of names. When you click on the name, something can happen. To do this I could have done the following:

$$('ul#leftchoices li').each(function(el) {
    el.observe('click', function(e) {
        if ($('colorchange').checked) {
           changeColor();
        }

        if ($('contentchange').checked) {
           changeContent(el.id);
        }
    });
});

In the click event itself, I do various checks and kick off behaviour. That can be fine for small actions, but what if you want to do more? This is when I prefer to abstract out the action and just fire an event:

$$('ul#leftchoices li').each(function(el) {
    el.observe('click', function(e) {
        el.fire('selected:choice');
    });
});

At this point, this bit of code becomes dumb. It doesn’t know what to do when you select the item, and it just hopes that somewhere, someone is listening. That is where the observers come in, such as this one that changes the main content based on the selected name:

$('contentchange').onchange = function(e) {
    if (e.target.checked) {
        document.observe('selected:choice', changeContent);
    } else {
        document.stopObserving('selected:choice', changeContent);
    }
}

When someone clicks on the checkbox, this method is fired and an observer is either added, or taken away.

Once you start building applications with this in mind, you may find a bit of a sea change. You start to think about the various events as a public API that you can easily expose to observers. Gone is the simple ability to look at one method and see what is happening, but the loose coupling gives you the ability to easily layer in your architecture. Based on some settings, behaviour can be dynamically added. You could even expose these events in a way that makes it easier for Greasemonkey hackers to come in and work with your application. All in all, a win-win for anything more than a simple example.

Although this example uses Prototype, you could do the same with the other top class JavaScript libraries. In fact, if someone wants to port this example to Dojo, jQuery, Mootools, YUI, or anything else, send me the files and I will put them up so we can all compare how custom events are done in the various toolkits.

UPDATE: We now have Prototype, jQuery, DOMAssistant, and Appcelerator versions. Thanks Malte!