Gordon Weakliem references Patrick Logan who references Philippe Bossut who references Alex Russell’s OSCON talk on AJAX. The little tid-bit that gets me excited is the quote “Best data type to return: JavaScript instead of XML”. I want to add an emphatic “yes!” to that. Only a crazy fool manipulates XML on the client-side when manipulating Javascript is so much easier. And, yes, I also want add another link to this long chain of attributions.

If you’re a Lisp head, like us at Untyped, when you look at Javascript you get an itch to add back all the parentheses (and fix its silly scoping rules, but that’s another post). Unsurprisingly we’re not the only ones. There is this Lisp to JavaScript Compiler I found via LtU, and also ParenScript. These are pretty cool. Of the two ParenScript is more practical, though the translation remains fairly direct. I’d like to see these languages go further and add features not present in Javascript. I think ParenScript gets the scoping rules correct, so next on my list would be coroutines to make coding animations easier.

I just read about an interesting library for using CSS selectors to apply Javascript behaviours, courtesy of a link from Ajaxian. The idea is simple: use CSS selectors in Javascript code to specify DOM nodes that Javascript event handlers should be bound to. This abstracts the event handling code away from the HTML. This gives cleaner code, though I’m not sure how useful it will be in practice, for two reasons:

• It will be slower than just writing the event handlers directly in the HTML. How much slower I haven’t measured, so this may not be a problem.
• I don’t write much Javascript directly (except when trying out new ideas). Instead I tend to generate it (along with HTML) from other sources, so achieving a separation between Javascript and HTML isn’t an issue for me.

However I don’t want to give a negative view of this library. I think it is really neat, and it has interesting similarities to Aspect–orientedprogramming (AOP). In AOP you change code by specifying places to add extra functionality. This library is changing HTML by specifying places to add extra functionality. If you squint the right way HTML and Javascript merge into one, so there seems to be a relationship here. I don’t know enough about AOP to know if this analogy opens up any interesting new directions, but I know people who do, and I hope they’re going to comment on this. 

Todd Ditchendorf advocates the benefits of anonymous classes:

While the XMLHttpRequest class is certainly a major step forward for JavaScript in the browser, you have to admit… this API is crap … Instead of passing a function reference to [the XMLHttpRequest object], why not pass a reference to a JavaScript object? … Notice how [anonymous classes] allow you to package instance properties (fields, variables, attributes, whatever) and instance methods along with the actual callback method … Sure … you don’t need this kind of functionality … you can always just define a bunch of global functions and global variables to be used by your callback function, but, then you lose all the benefits that OO offers with regard to combining state and behavior into a single, encapsulated entity!

While I agree with his statements — the XMLHttpRequest API is crap — the alternative to anonymous classes is not a mess of global variables and functions, thanks to a feature in Javascript known as closures. It seems many Javascript developers don’t know about closures, as they come from the functional, not object-oriented, line of languages, so I thought I’d highlight them here.

Javascript allows functions to return functions, and I think most Javascript developers will be familiar with that. However, some may not know that such a function can reference variables defined in it’s parent function, even after the parent has returned. This means you can write things like:

function makeSayHello(name) {
var sayHello = function() {
alert("Hello " + name);
}

return sayHello;
}

var noel = makeSayHello("Noel");
var matt = makeSayHello("Matt");

noel();  /* Says "Hello Noel" */
matt();  /* Says "Hello Matt" */

Notice that noel and matt refer to the arguments to makeSayHello even after makeSayHello has finished executing. This is very useful when writing callbacks, as it allows you to setup the callback with the parameters it needs avoiding a mess of globals. For example:

function makeCallback(arg1 arg2) {
return function() {
doSomething(arg1);
doSomething(arg2);
}
}

You’ll see this pattern used a lot in our demos. It’s a neat trick and deserves to be better known.