jQuery 1.4 released

The latest and greatest version of jQuery, version 1.4, was released on January 14, the birthday of jQuery’s original launch. Bugfixes and improvements abound!

The jQuery team has put together a site devoted to the new version, called the 14 days of jQuery, covering the major version changes as well as infrastructure updates coinciding with the new release. For example, the documentation site has been completely redesigned, and been moved to it’s own subdomain home, api.jquery.com. Links from the primary jquery.com site should be updated within the next week. With video demos of new features, Q&A’s with the core team (including founder John Resig), it’s well-worth checking out for every jQuery developer.


Using jQuery for DOM event attributes

My last post discussed my conversion to JavaScript frameworks, and why you should be one too. I explained that I settled on jQuery because it simplified how I write JavaScript without strictly locking me into a set of features and effects.

A core part of this flexibility comes from jQuery’s document ready wrapper. It works like window.onload(), but provides a quantum leap in functionality. You can find more details at the link. Suffice it to say that all jQuery event listeners must go inside a document ready wrapper.

The problem is that document ready listeners only apply to DOM elements that exist when the document is ready. It works like a snapshot. When the document is finished loading, jQuery takes a picture of how it looks and references it for activating listeners.

“So what’s the problem?” you might ask. Anything that exists in DOM after that picture is taken essentially does not exist for listening purposes. Let’s look at an example. First, here’s a simple block of HTML:

[code='html']

generate new html

[/code]

…and the accompanying jQuery magic:
[code='js']
$(document).ready(function(){
$("a.currentAction").click(function(){
$("span#fooBar").append(
'

new action link'
);
});
$("a.newAction").click(function(){
alert('Here I am!');
});
});
[/code]

The link inside the span will create a new link using jQuery. That new dynamic link has its own jQuery listener to create a second new link as well. The catch is that the second link will never work; you’ll never see that alert box listed in line 8. The jQuery DOM doesn’t have an awareness of the second link at load time, so for its purposes the link doesn’t exist. Don’t believe me? Check out the demo I put together. I’ll wait.

Weird, right? Not to mention annoying…

So how can we daisy chain page dynamics using jQuery? Simple, we just have to go old school. Since jquery can’t listen to something that doesn’t exist at load time, we have to create a new listener. The easiest way to do that is using the onclick event. Let’s modify the JavaScript code from above a bit…

[code='js']
$(document).ready(function(){
$("a.currentAction").click(function(){
$("span#fooBar").append(
'

new action link'
);
});
});

function newClickAction(object) {
$(object).css({ backgroundColor:"yellow", fontWeight:"bolder" });
alert('Here I am!');
}
[/code]

This time, the new action stands on its own as a separate function, outside the document ready wrapper. We then added an onclick event to the generated HTML, thereby creating a new listener for the new link. The alert box will appear this time, and here’s another demo to show it in action.

There are two other things to note about this second example. First, notice that we have used jQuery code inside our custom function. The magic jQuery function $() is defined in the pages global scope. Since jQuery still must operate within the normal parameters of JavaScript, that function is available inside any other function. The thing to note here is that you can use jQuery outside of the document ready wrapper. This rule applies to any JavaScript library you might use.

The second thing to note in our second example is the argument called “object” passed into newClickAction(). This variable refers to the magic JavaScript variable this, which we placed inside our jQuery-generated HTML. The variable this always refers to the object in which it is called, whether it be a function or page element. jQuery is aware of the contents of a this reference, and thus can immediately identify the element by making it the sole argument of the $() function, as opposed to getting the element by id, class names, or tree navigation (i.e. parent descendant).

The two additional concepts are put into action when you click the link. jQuery finds the element and changes the background highlighting, while showing the alert box at the same time.

As you can see, things get pretty dicey quickly with uber-powered AJAX pages. Just make sure to keep your code clean, work on a single feature at a time, and you should be fine.


Get a JavaScript framework. Now.

We’ve been really into jQuery at our office for the past few weeks, and I have to say that I am absolutely in love with it. Coming from the world of writing “classical” JavaScript in “long-hand” format, jQuery appears damn close to magic; I half-expect a mystical gnome to pop out of my monitor when I use some of the more elaborate jQuery techniques. It’s that good.

If you still do JavaScript old-school, I would urge you by any means necessary to pick up and learn one of the several standardized JavaScript support libraries. It can only speed up your JS development, decrease your bugs, and perform some really cool JS acrobatics with relative ease. If you have any aspirations of utilizing Ajax techniques, frameworks are practically a requirement. The legwork involved in setting up an Ajax request manually is a real pain.

[aside]While a framework enables relatively easy Ajax effects, I recommend you build a simple Ajax effect totally on your own. I had a background in PHP/MySQL development before I even touched Ajax, and the experience was still challenging. Now when I use framework-powered Ajax, I know what’s going on behind the scenes, which makes me a better coder. Hmm, good future post fodder…[end aside]

Any of the big-name frameworks will get you started. When making your decision about where to start, I have one piece of advice: just pick one! Each has strengths and weaknesses, depending on your skill level and how you intend to implement it. The worst way to go about this would be to go around the web looking for insider advice on which one is the “best.” You’ll only find yourself in the middle of nit-picky flame wars. Such ridiculous arguments over different coding techniques/ tools are called “holy wars.” I find the term accurate.

At the same time, I don’t want you to wonder endlessly. Here’s what I would consider the top 4 (in no particular order):

Due to the nature of my work, most of my JavaScript is custom, and so I find the more “firm” frameworks restrictive. I personally lean towards jQuery because it focused on changing how you write core JavaScript, as opposed to providing me with prefab effects and formulas. But if your needs are simpler, the more formulaic frameworks, Script.aculo.us in particular, will suit you very well.

Before you start your next project involving JavaScript, learn to use a framework.  I promise you’ll wonder how the heck you got by with out it.