jQuery Presentation Follow Up

Hey folks!

As promised, I will be writing to follow up on my presentation with additional related information and things that I didn't get to cover in my 75 minutes. To start off, let's clarify again some things that I may have wrongly said or poorly explained.

$.extend()

When you are using the extend method in jQuery, I mentioned that it is often used to extend jQuery itself. Think about the example below.

After looking in the jQuery source code, the last line is better said as such:

If you only pass one object, it will extend jQuery. Also, I had said that $.extend() always returns jQuery. This is false! It returns the object that is being merged onto, the target, which proves to be useful.

Quirks With Setting CSS

When we were refactoring my existing plugin, we moved styles into an external stylesheet. Along with that, I have found out recently that there are some fatal errors that can result in any CSS based method (.css, .animate, etc.).

The first line silently fails in Internet Explorer (6, 7, 8). The second line is a fatal error in IE. The difference is that the second line is assigning an illegal value to a legal property. JScript doesn't like it when you do that.

Refactoring, Continued

The plugin that we refactored and reviewed at the end of the presentation is actually on my GitHub page under the name jquery.quickbox.js. In the past day or so, I've made some significant changes to it and added some functionality for captions. The biggest performance hit that was in the old version of the plugin was how I was handling my document searching.

The more times you make calls to jQuery, the bigger performance hit you're going to take. As much as you can, store jQuery objects in variables that you can use throughout your code. This is a pretty simple thing, but something that I hadn't realized I was doing until I saw I made the same three calls to jQuery dozens of times in my application. If you take a look at the source for this plugin, you'll notice that those calls have been pared down significantly.

Protecting jQuery

Since other libraries use a $ (and even a double-dollar function), we don't want to accidentally overwrite it an make the other library unusable. To do this, we include our entire plugin inside a self-invoking anonymous function.

See how we wrap an anonymous function? That way we can call it with the one argument jQuery immediately. This way we have the luxury of using the dollar sign in our plugin for readability and ease of use.

jQuery.noConflict()

Related to protecting jQuery is the noConflict() method. This is something that I briefly mentioned in the presentation. The only thing you need to do to make this happen is assign a new variable to jQuery.noConflict(). After including jQuery:

Then, $j becomes a reference to jQuery instead of the dollar sign.

Which Library to Use?

I've often found that people gravitate to a JavaScript library for two reasons: one, they like the programming style and methodology it uses; and two, it most easily does what they want it to do. That has been jQuery for me. The bulk of what I do with JS has been in the browser doing element creation, manipulation, and traversing, and asynchronous requests. There are libraries that do this just as well (and in fact, perhaps faster), but I've found the readability and logic behind jQuery to really make sense to me.

This is the point I'm trying to illustrate. Use the library that makes sense to you. In fact, there is nothing bad that can come about from learning each jQuery, MooTools, and Prototype. Most likely, you'll be able to see which has strengths in the area you use most often.