function register(name, fn) {
        
        fn = fn || proto[name]; // For what?
        
        proto[name] = function() {
            this.add(name, arguments);
            return this;
        };
        
    }

CS does look pretty cool, and kudos to the creator, but, for me, its yet another abstraction that fuzzes the details. I know I can’t really talk, being involved with one the highest abstracted programming stacks on the planet (the “web” stack).

Anyway, thanks for the info. I can see why CS (and other similar things) would be appealing to some, but for me, having being brought up with C-like languages, I feel quite at home with JS. I have been looking at Perl recently though, which is pretty cool.

Using CS would be the same as using GWT and compiling to typically less-than-good JavaScript.

James, I don’t think it’s quite fair to lump CoffeeScript (and ParenScript) in to the same group as GWT (or Pyjamas, etc…).

Both CS and PS expressions compile one-to-one with JS, keep the same variable names, and even indent properly so that the compiled JS looks “handwritten” or pretty printed. This makes a world of difference when debugging; perhaps the most common complaint of X-to-javascript compilers.

GWT, on the other hand, is a full blown Java framework and GUI toolkit. Who knows what kind of code ends up being generated?

It’s JS for people that don’t like JS…

I think in most cases its language geeks having fun. Personally, I love a lot about JS and dislike some too (Crockford has pointed out the beauties and flaws of JS so completely that it is almost cliche to reference or quote him any more). I think there is nothing wrong with exploring an alternate syntax; Because that is really all CS and PS are (with the exception of ParenScript’s macros, but I digress).

I will risk being labeled cliche: I believe it was Crockford that has the somewhat famous quote about JS being Lisp in C’s clothing or whatnot; why not see what it looks like when we strip the C syntax from it?

PS: I like the new design on your site, its snazzy 🙂

@K.Adam, good point! I did consider this too… But I thought the plugin-like syntax would be a little cleaner.

@Dss, there is no difference — that’s the point!

Macros are useful in the way that plugins are useful… You don’t need to write out all that code every time you want to use it.

@Nick, some interesting stuff there! I’ve looked at CoffeeScript, but I can’t say I’m very enthused. Using CS would be the same as using GWT and compiling to typically less-than-good JavaScript. It’s JS for people that don’t like JS…

What is different between:

var myMacro = jQuery.macro('myMacro');
myMacro.css('color', 'red').scrollTop(0).addClass('foo');
jQuery('div').myMacro(); // All that stuff happens! css()->scrollTop()->addClass()

and simply:

$('div').css('color', 'red').scrollTop(0).addClass('foo');

Something else to consider: If the goal is not to extend the jQuery API, then as you know, this macro plugin does break that goal. What if, instead, the macros were kept to the macro object. For example

jQuery.macro('cousins').parent().siblings().children();
jQuery('#elem').macro('cousins'); // YEH!
jQuery('#elem').replay('cousins'); // Alternative naming

This way, you can leave the jQuery object a little less cluttered. Naturally, the downside to this is if that macro ever needs to become a full fledge plugin, you would have to do more refactoring to make the conversion.