JQuery - Best way of wiring GUI objects to events?

Question

Ever since JQuery came along a few years ago I've been using it in all my client-side scripts. Initially I used the '$() syntax to grab and manipulate objects this, to me, is the 'old skool' paradigm of explicitly wiring up button events to functions:

<button onClick='myFunction(this);' ...  />

with a related function:

function myFunction(obj){
    alert('this is how old-timers like me do it!')
}

Some of my colleagues prefer to do the attaching of scripts to events a la JQuery:

$(document).ready(
    $("#myButton").click(
        function(event){
            alert('this is the newer JQuery way of doing things');
        }
    );
);

Initially I found the overly-bracey JQuery syntax with its reliance on anonymous functions etc. difficult to read, but my eyes and brain have adjusted so I'm happy with either way now. I would however like our codeshop to be consistent. Does anyone have any opinions on which approach is 'better'?

Answer 1

The 'jQuery' way enforces the separation between content and functionality, which is a Good Thing IMO. It reduces the 'noise' in your content/markup. It also enables a programmer to concentrate on the scripting, whilst a 'marker-upper' concentrates on the HTML.

BTW, you don't have to be 'overly-bracey', or use anonymous functions if you don't want to:

function myFunction(obj){
    alert('this is a compromise!')
}

$(function() {
    $("#myButton").click(myFunction);
});

Answer 2

The jQuery version you have can be much smaller as well:

$(function() {
  $("#myButton").click(function(){
    alert('this is the newer JQuery way of doing things');
  });
});

I'd go with this or any other unobtrusive route (not inline handlers), there are just fewer issues overall, and maintenance can be much easier. Remember with this route there can be no JavaScript in your page, it can be loaded and cached once by your client meaning faster page loads as well.

There are many things you just can't do properly (or cross-browser) inline as well, for example the very useful mouseenter and mouseleave (so they don't fire when entering a child) events are only available inline in IE.

Answer 3

I think the second approach is cleaner for several reasons :

• it really allows you to separate content and behaviour, that is you can define your content's structure first and only later take care of the specific behaviour... This is especially helpful if your team involves different technical profiles (somebody takes care of the raw HTML, somebody else is the Javascript expert ...)

• This really helps maintenance, as you know where to look for the potentially buggy javascript if something goes wrong , instead of having to look through the whole HTML.

• when your HTML is actually dynamic (generated on server-side, à la PHP or ASP.NET), it is actually quite painful to have to include those client-side elements in the HTML you generate... This is a very common source of errors, therefore it is good to have the javascript out of the way.

Answer 4

The jQuery version is better because it separates behaviour (JavaScript) from structure (HTML).

If brackets seem too many, you can use a language which compiles into JavaScript, such as CoffeeScript (http://jashkenas.github.com/coffee-script/):

$ ->
  $("#myButton").click ->
    alert 'this is the newer JQuery way of doing things'