The Better way

By now, we are all using some compiler to compile your code. Right? If you haven't started, grab the Closure Compiler to follow through on this example.

1. Download the latest Closure Compiler http://closure-compiler.googlecode.com/files/compiler-latest.zip
2. Unzip
3. Copy the compiler.jar file into your directory with the JS Files.
4. follow along below and enjoy!

If you are using Closure Compiler or Uglify already, you are in luck! Both of these compilers allow you to annotate your JavaScript. Annotating your files allows you to describe them to the compiler. Things like @license will make sure that the comment goes to the top of the file after compression. Look through the http://code.google.com/closure/compiler/docs/js-for-compiler.html list to see what each one does. We are going to focus on @define.

Take the following Code

/**
 * @preserve Copyright 2009 SomeThirdParty.
 * Here is the full license text and copyright
 * notice for this file. Note that the notice can span several
 * lines and is only terminated by the closing star and slash:
 * BORROWED FROM THE ANNOTATED DOCS
 */

/** @define {boolean} */
var DEBUG = true;
var x = 1,
        y = 2;

var myNewObj = function(name, item) {
        var shortName = "Mr " + name,
                longName = "Dr. " + name + " M.D.S";

        this.getShortName = function() {
                if (DEBUG){
                        console.log("I am returning short name: " , shortName)
                }
                return shortName;
        }

        this.getLongName = function() {
                if (DEBUG){
                        console.log("I am returning long name: " , longName)
                }
                return longName;
        }

        return this;
}
// a bunch of your other code her

if (DEBUG) {
        var drWho = new myNewObj("Who", "blank");
        console.log(drWho.getLongName());
}

If we run the above code, we get the following output:

I am returning long name:  Dr. Who M.D.S
Dr. Who M.D.S

The above code would allow us to quickly turn on and off the debug statements and see what the JS code was doing. If we use this pattern, we can actually not worry about the value of DEBUG when we are finished with the file. We can actually change the value when we compile the input.

The compiler

If you take the above code and compress it using the following command:

	java -jar compiler.jar --js input.js --define=DEBUG=false --js_output_file output.js --compilation_level SIMPLE_OPTIMIZATIONS --formatting PRETTY_PRINT

It will turn the output into:

/*
 Copyright 2009 SomeThirdParty.
 Here is the full license text and copyright
 notice for this file. Note that the notice can span several
 lines and is only terminated by the closing star and slash:
 BORROWED FROM THE ANNOTATED DOCS
*/
var DEBUG = !1, x = 1, y = 2, myNewObj = function(a) {
  var b = "Mr " + a, c = "Dr. " + a + " M.D.S";
  this.getShortName = function() {
    DEBUG && console.log("I am returning short name: ", b);
    return b
  };
  this.getLongName = function() {
    DEBUG && console.log("I am returning long name: ", c);
    return c
  };
  return this
};
if(DEBUG) {
  var drWho = new myNewObj("Who", "blank");
  console.log(drWho.getLongName())
}
;

The compiled code now outputs the following:

undefined

The return output for the new code is blank

Advanced Compiling

We can actually take this one step further, but be warned this is not for the faint of heart. If you want the statements removed completely you will need to rework your code just a bit.

Lets start with a modified version of the starting code:

	/**
	* @preserve Copyright 2009 SomeThirdParty.
	* Here is the full license text and copyright
	* notice for this file. Note that the notice can span several
	* lines and is only terminated by the closing star and slash:
	* BORROWED FROM THE ANNOTATED DOCS
	*/                

	/** @define {boolean} */
	var DEBUG = true;
	var x = 1,              
	y = 2;          

	(function() {
	        /**
	          * A new Obj
	          * @constructor 
	          */            
	        myNewObj = function (name, item) {
	                this.shortName = "Mr " + name,
	                this.longName = "Dr. " + name + " M.D.S";

	                return this;
	        }

	        myNewObj.prototype.getLongName = function() {
	                /** 
	                  * @this {myNewObj}
	                  * @return {string}
	                  */
	                if (DEBUG){
	                        console.log("I am returning long name: " , this.longName)
	                }
	                return this.longName;
	        }

	        myNewObj.prototype.getShortName = function() { 
	                if (DEBUG){
	                        console.log("I am returning short name: " , this.shortName)
	                }
	                return this.shortName;
	        }

	        myNewObj.prototype['getLongName'] = myNewObj.prototype.getLongName;
	        myNewObj.prototype['getShortName'] = myNewObj.prototype.getShortName;

	        if (DEBUG) {
	                var drWho = new myNewObj("Who", "blank");
	                console.log(drWho.getLongName());
	        }
	})();

Here we moved the code into a closure function.

	(function() {
	})();

Next we split the myNewObj into a constructor and prototypical inheritance. We also added a new annotation: @constructor. This tells the compiler that it is able to be invoked from other areas of the code.

	/**
	  * A new Obj
	  * @constructor 
	  */            
	myNewObj = function (name, item) {
	        this.shortName = "Mr " + name,
	        this.longName = "Dr. " + name + " M.D.S";

	        return this;
	}

	myNewObj.prototype.getLongName = function() {
	        /** 
	          * @this {myNewObj}
	          * @return {string}
	          */
	        if (DEBUG){
	                console.log("I am returning long name: " , this.longName)
	        }
	        return this.longName;
	}

	myNewObj.prototype.getShortName = function() { 
	        /** 
	          * @this {myNewObj}
	          * @return {string}
	          */
	        if (DEBUG){
	                console.log("I am returning short name: " , this.shortName)
	        }
	        return this.shortName;
	}

Next, we need to make sure that the functions are available to everyone else. Since the advanced compiler will change all variable names, and delete portions of code that aren't reachable, we will make them reachable again. We do this by attaching each of the available functions onto the objects prototype again. For more information on this, check out Advanced Compilation and Externs tutorial on Closure Compiler.

	myNewObj.prototype['getLongName'] = myNewObj.prototype.getLongName;
	myNewObj.prototype['getShortName'] = myNewObj.prototype.getShortName;	

Now that we have the JavaScript setup properly, we can compile to see what the output becomes. We compile the code with the following options

	java -jar compiler.jar --js input.js --define=DEBUG=false --js_output_file output.js --compilation_level ADVANCED_OPTIMIZATIONS --formatting PRETTY_PRINT --generate_exports

It will turn the output into:

/*
 Copyright 2009 SomeThirdParty.
 Here is the full license text and copyright
 notice for this file. Note that the notice can span several
 lines and is only terminated by the closing star and slash:
 BORROWED FROM THE ANNOTATED DOCS
*/
myNewObj = function(a) {
  this.d = "Mr " + a;
  this.c = "Dr. " + a + " M.D.S";
  return this
};
myNewObj.prototype.a = function() {
  return this.c
};
myNewObj.prototype.b = function() {
  return this.d
};
myNewObj.prototype.getLongName = myNewObj.prototype.a;
myNewObj.prototype.getShortName = myNewObj.prototype.b;

Summary

Don't feel overwhelmed trying out the advanced optimizations. Sometimes it just takes some playing around with the code to get it into the best possible outcome. If you aren't that familiar with JavaScript, I would highly recommend sticking with the SIMPLE_OPTIMIZATIONS and just having a slightly bigger file to content with.

A quick heads up, if you haven't heard about the new CSSLint project from Nicole ## and Nicholas Zakas, you have been missing out. The project aims to take CSS to the next level and help you understand why your css isn't performing very well. What, you didn't know your CSS isn't performing? Thats because most of us haven't had a good Code Review on most of our CSS.

CSSLint for TextMate

First and foremost, I would like to say, I forked the original jsHint TextMate Bundle. If you don't already have this, you need it. It will change the way you put together your JavaScript, just as I suspect CSSLint will do for your CSS.

I talked with Nicholas at the Velocity conference and decided I would put together a quick CSSLint TextMate Bundle that could make use of the Node Module for CSSLint. After a couple of hours playing with the way TextMate Does its bundles, I was able to get a working product. A Couple of quick emails back and forth and we have a Beta version of the CSSLint TextMate Bundle.

Installation

Installation is simple. Just download this file CSSLint TextMate Bundle. Unzip the contents, and then rename the file to csslint.tmbundle.

Once you have renamed, just double click on the icon, and it should automatically add it to TextMate.

Prerequisites

You need Node.js and TextMate, that's all.

If you don't have Node.js installed on your system you can also use Pierre Bertet's fork which uses WebKit's JavaScriptCore instead.

This bundle uses #!/usr/local/bin/node to launch the node process. If you get a node - not found error,the PATH variable is probably not setup in TextMate.

Features

A couple of quick highlights.

• Runs automatically upon save (⌘S)
• Can be bypassed by pressing ⇧⌘S
• Output is only shown when errors are found
• Based on Node.js

ScreenShot

Contributions

Feel free to contact me about any features you would like to see in the bundle. Or submit a pull request and I will take a look.

Cheers!

JC Fant

Souders just posted the following tweet.

Someone out in #webperf land should test how inline scripts block downloads - eg, image - inline script - image - are the images parallel?

So here is my response to the question...

Answer: No

The Test Page

The page itself is pretty simple, two images served from placehold.it and in between them, jQuery 1.5.2 in an inline script block. Take a look at the sample test here.

The Tests

Using webpagetest.org, I ran the scriptTest.html file through IE6|7|8|9 and Chrome 11. In each of the browsers the waterfall graph comes out the same. The inline script blocks any more downloads until the script has finished parsing and been run.

Waterfall Graphs

Here are the waterfall graphs for each of the browsers on webpagetest.org

IE6

Test Results

IE7

Test Results

IE8

Test Results

IE9

Test Results

Chrome 11

Test Results

But Wait!

This isn't just about images and inline style blocks. What happens when we use a style sheet? Will it give the same behavior?

Next Test

Here is a new test, it has an external style sheet (style.css), the inline JavaScript block, another external style sheet (screen.css) and an image from placehold.it.

Results

In each case the inline JavaScript is blocking the page from getting any more resources. As soon as the JavaScript has been processed it can then move on to getting the background image, screen.css and the placeholder.it image.

IE6

Test Results

IE7

Test Results

IE8

Test Results

IE9

Test Results

Chrome 11

Test Results

Conclusion

Be careful with your inline blocks. They CAN AND WILL hold up the rest of your page when they are encountered.

So I recently went looking on how to get class from element in JavaScript. Turns out most of the results were for getting elements by class name, rather than actually getting the class of the element I already had.

Here is how you get a class name from an Element using JavaScript.

	document.getElementById("tag_cloud-2").className

	Output:
		"sidebaritem widget_tag_cloud"

Now, that wasn't so hard. Lets take a look at a performance test: jQuery versus getting a className.

Here is the setup for the test

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.2/jquery.min.js"></script>

<div class="wrapper">
	<div class="innerWrapper">
		<div id="getMe" class="button">
			<a href="javascript:void(0)" id="button" class="buttonRef">
				<span class="buttonText">Text</span>
			</a>
		</div>
	</div>
</div>

<script>
	var jElem = $("#getMe");
	var dElem = document.getElementById("getMe");
</script>

Here are the tests:

1. jQuery - get Element + get Class   $("#getMe").attr('class');
2. GET DOM ELEM + get Class           document.getElementById("getMe").className;
3. jQuery get Class                   jElem.attr('class');
4. DOM get class                      dElem.className;

Chrome 11 Results

In Chrome using a cached element, getting the classname is 48x faster than using jQuery.
In Chrome getting the element and then getting the classname is 25x faster than using jQuery.

FF 4.0 Results

In FF using a cached element, getting the classname is 65x faster than using jQuery.
In FF getting the element and then getting the classname is 83x faster than using jQuery.

Safari 5.0 Results

In Safari using a cached element, getting the classname is 30x faster than using jQuery.
In Safari getting the element and then getting the classname is 35x faster than using jQuery.

Summary

Whenever possible, using the browsers built in methods will always be faster, and just because you have a library available doesn't mean you should be using it for every DOM query. The speed advantage alone should dictate which methods of the library you are using and when.

During the course of building web apps, we usually end up with functions to do certain tasks. However, since those tasks sometimes need to be done differently in each of the browsers, we end up with large if else statements to get the job done.

This is where Self Defining Functions come in handy.

Here is a simple Person Object that has a getPayInformation object. Lets assume for the sake of the argument that this function is called 100's of times. In this case, each time the getPayInformation function is called, it first has to figure out the role, then do the calculations for the pay.

function Person(name, role) {
    if (!(this instanceof Person)){
        return new Person(name, role);
    }

    this.name = name || "John";
	this.role = role || "Guest";
};

Person.prototype.getPayInformation = function() {
	if (this.role === "Admin"){
		// fetch some data for the admin role. 
		// do some awesome calculations to munge the data 
		// ...
		return {
			"role"  : "Admin",
			"rate"  : 10.00,
			"hours" : 40
		};
	}else if (this.role === "CopyCat"){
		// fetch some data for the admin role. 
		// Calculating the Info for a copy cat is harder. Has some different calculations based on 
		// how many words they wrote
		// ...
		return {
			"role"  : "CopyCat",
			"rate"  : 37.00,
			"hours" : 23
		};
	}else if (this.role === "Crane Operator"){
		// fetch some data for the admin role. 
		// Calculating the info for a crane operator is based on hourly, anything over 40 is time and a half.
		// ...
		return {
			"role"  : "Crane Operator",
			"rate"  : 90.00,
			"hours" : 42
		};
	}else{ 
		// fetch some data for the admin role. 
		// we don't need to do anything for the guest, its always 0.
		// ...
		return {
			"role"  : "Guest",
			"rate"  : 0.00,
			"hours" : 0
		};
	}
}

What would happen if we knew that after the first time through this person was an admin. We would no longer need to do that check over and over again.

function Person(name, role) {
    if (!(this instanceof Person)){
        return new Person(name, role);
    }

    this.name = name || "John";
	this.role = role || "Guest";
};

Person.prototype.getPayInformation = function() {
	if (this.role === "Admin"){
		this.getPayInformation = function() {
			console.log("Lazy Function Definition");
			// fetch some data for the admin role. 
			// do some awesome calculations to munge the data 
			// ...
			return {
				"role"  : "Admin",
				"rate"  : 10.00,
				"hours" : 40
			};
		}
		return this.getPayInformation();
	}else if (this.role === "CopyCat"){
		this.getPayInformation = function() {
			console.log("Lazy Function Definition");
			// fetch some data for the admin role. 
			// Calculating the Info for a copy cat is harder. Has some different calculations based on 
			// how many words they wrote
			// ...
			return {
				"role"  : "CopyCat",
				"rate"  : 37.00,
				"hours" : 23
			};
		}
		return this.getPayInformation();
	}else if (this.role === "Crane Operator"){
		this.getPayInformation = function() {
			console.log("Lazy Function Definition");
			// fetch some data for the admin role. 
			// Calculating the info for a crane operator is based on hourly, anything over 40 is time and a half.
			// ...
			return {
				"role"  : "Crane Operator",
				"rate"  : 90.00,
				"hours" : 42
				};	
		}
		return this.getPayInformation();
	}else{ 
		this.getPayInformation = function() {
			console.log("Lazy Function Definition");
			// fetch some data for the admin role. 
			// we don't need to do anything for the guest, its always 0.
			// ...
			return {
				"role"  : "Guest",
				"rate"  : 0.00,
				"hours" : 0
			};	
		}
		return this.getPayInformation();
	}
}

Now, we only have to do the check once and then each subsequent calls can skip the check and just get to work.

So what does the output look like?

	var tammy = new Person("Tammy", "Admin");
	console.log(tammy.getPayInformation());
		"Lazy Function Definition"
		> Object
			{
				"role"  : "Admin",
				"rate"  : 10.00,
				"hours" : 40
			}
			
	var john = new Person("John", "Guest");
	console.log(john.getPayInformation());
		"Lazy Function Definition"
		> Object
			{
				"role"  : "Guest",
				"rate"  : 0.00,
				"hours" : 0
			}
	
	var lola = new Person("Lola", "CopyCat");
	console.log(lola.getPayInformation());
		"Lazy Function Definition"
		> Object
			{
				"role"  : "CopyCat",
				"rate"  : 37.00,
				"hours" : 23
			}
			
	var chad = new Person("Chad", "Crane Operator");
	console.log(chad.getPayInformation());
		"Lazy Function Definition"
		> Object
			{
				"role"  : "Crane Operator",
				"rate"  : 90.00,
				"hours" : 42
			}

Looks to be a pretty neat way to do Browser Feature detection instead of nested if statements. Moving to a Module pattern helps to support the Self Defining Function Pattern.

Hey guys, I'm sure this has been answered before but I can't seem to find anything by searching Google or /r/jquery. I am a beginner with this so forgive me, but I can't find an explanation to this anywhere and I'm curious. When I try to stop the default submit function of a form in the <head> tag of a .html file it won't work, but when I copy and paste the same code into the <body> it works fine. Regardless of where I place it, it is always below the link to the jquery library. This is really confusing and I was hoping you guys could explain this for me. Thanks! via jQuery <script> in <body> or *lt;head>.

Problem

Here was a copy of the code that worked:

However, if he moved the <script> tag into the head, the form submit stopped working.

Why?

Why on earth would the first one work, and the second one not? Well, it comes down to when the dom is ready. In the second example, jQuery is looking for a form tag that hasn't been parsed by the browser yet. So it returns an empty jQuery object, to which the submit event is attached.

The Fix

We have a couple of ways of fixing this issue.

.ready()

The .ready() event attached to the BODY tag, will allow us to attach the submit event as soon as the DOM is ready

.delegate()

The .delegate() method can be placed anywhere in your page. Since the delegate function will attach the event to any current "form" elements, or any future "form" elements that may appear in the DOM. The gotcha... If you only have one form element on the page, this will work fine. However, IF for some reason, you create another form element, this same event will be attached to that form as well.

.live()

The .live() method is a variation/alternative of the .delegate() method. However, at least one element must exist before you can use it. Which means, you still need to wrap it in a .ready() or put it in the footer.

This method is a variation on the basic .bind() method for attaching event handlers to elements. When .bind() is called, the elements that the jQuery object refers to get the handler attached; elements that get introduced later do not, so they would require another .bind() call.

In all, either .ready() or .delegate() will work, just make sure you use them properly. You don't want to add another form or other element and have it get an event you hadn't planned on.

In the 3rd chapter, Literals and Constructors, I noticed this section on "Patterns for enforcing new" with the following entry:

When your constructor has something like this.member and you invoke the constructor without new, you're actually creating a new property of the global object called member and accessible through window.member or simply member. This behavior is highly undesirable, because you know you should always strive for keeping the global namespace clean.

Take a look at the following code:

Eek! Thats not what I expected at all. So how can we force this to always create a new Object each time, regardless of whether or not the Object ("function") has been called with new?

Solutions

There are a couple of solutions. We can either, change the scope of the internal variable to something other than "this" OR we can always force a "new" on the object.

Use "that"

If we change the function to create a new object called "that" and then assign personName to the new object, we can make sure that the global namespace isn't polluted.

Well, that is much better. However, if we check whether or not "jason" or "tammy" are actually people we see that both fail. So while this gets us to the point of not polluting the global namespace we aren't creating actual "people".

Force "new"

We can actually check to see if "this" is an instance of Person, if not, returning a "new Person".

Much better, now we actually have true instances of "Person".

The good news in all of this is that in ECMAScript5 strict mode, this no longer applies. As the "this" reference will no longer point to the global namespace.

After listening to his pod cast, (you can find the transcript here), I decided to put the two patterns to test. So I fired up a new test on JSPerf.com

Setting up the Closure Pattern

Setting up the Prototypal Pattern

Setting up the Prototypal Hoisting Pattern

Results

Closure Pattern

The closure pattern is quick in Chrome, but not nearly as fast in all the other browsers.

Prototypal Versus Hoisting

Prototypal and hoisting run neck and neck in all browsers, with Prototypal winning out in Chrome.

Closure Versus Prototypal

Here we are can start to se the overall winner in object creation.

Closure, Prototypal, Hoisting

I threw this one up here so you can see all 3 types next to each other.

Conclusion

After look at this set of test, I really think it all depends on your use case. While the Closure Pattern lends itself to readability and the ability to have both public and private variables as well as public and private methods, object creation is much slower. Also, as Brendan points out, you aren't getting the same functionality as creating an object via the Prototypal Pattern.

The closure pattern, the one where you have the method as a function expression inside the constructor, can actually be more expensive. If you think about it, each time you call that constructor (let's say you call it a million times), you have to evaluate the method function expression. You have to evaluate the assignment "this.someMethod = function() { /*etc*/ }". In JavaScript, every time you evaluate a function expression, you get a new object. You can tell it's a new object because of "==="; you can also mutate it: it's mutable. So you can set a certain property on it that would not show up on any other instances -- "someMethod". You'd say "new ClosurePattern()" and assign that to x, and also set y to "new ClosurePattern()". Now you've got two instances. x.someMethod !== y.someMethod, and "x.someMethod.foo = 42" would not cause 42 to appear on y.someMethod: they'd be different objects. That hurts! If you do a million constructions, you've got not just a million instances of the ClosurePattern object, you've got a million "someMethod"s inside it.

Unless I was creating an application that requires creating millions of JavaScript objects, I would still recommend the Closure Pattern for code re-use.

A normal way to access a frame in jQuery is below:

Now, lets say you actually want to get another element inside of the frame, lets get the HEAD element.

Awesome, we now have the head element of the document in the frame. Lets add a style tag to it.

Now this worked in most browsers... I say most for a reason. This was an actual use case I was trying to accomplish. However, good ole' IE wouldn't let me actually add a DOM element anywhere in the frame. The only thing I was able to do was to add in style tags on the elements. So how did I get around it?

Wow, interesting mix of using straight JavaScript and jQuery in there. However, what happens when I want to just update the same style tag with something new?

And that is how you can add new elements to a DOM in an iframe inside of your page.

"There are a few requirements that I feel this pattern handles nicely:"

1. Claim only a single name in the jQuery namespace
2. Accept an options argument to control plugin behavior
3. -Provide public access to default plugin settings-
4. Provide public access to secondary functions (as applicable)
5. Keep private functions private
6. Support the Metadata Plugin
7. Allow for extending the object via callbacks (either hooks or events) as applicable
8. Scope all selectors with the 'this' object

This is a great start to "authoring a jQuery plugin":http://docs.jquery.com/Plugins/Authoring. However, there are a couple more requirements that I would propse adding in.

1. Claim only a single name in the jQuery namespace
2. Accept an options argument to control plugin behavior
3. -Provide public access to default plugin settings-
4. Provide public access to secondary functions (as applicable)
5. Keep private functions private
6. Support the Metadata Plugin
7. **Allow for extending the object via callbacks (either hooks or events) as applicable**
8. **Scope all selectors with the 'this' object**

So lets take a look at how we can implement this pattern using a tab plugin.

Claim Only a single name in the jQuery namespace

Setting up a new plugin is pretty simple. First we need to add the plugin name to the jQuery.fn namespace.

Notice that We scope the setup of this plugin inside of an anonymous function that executes with the jQuery parameter as $. We do this so that the jQuery namespace can be changed in order to play well with other javascript frameworks. It also allows us to scope jQuery to $ incase the namespace has already been changed.

Next we need to setup the single namespace for our plugin.

Notice we setup the name of our plugin into the jQuery.fn namespace. Also, we add in a bit of trickery. We need to make sure that if this plugin is called on multiple DOM elements, that it will still function properly. We do this by looping through each of the elements and calling .carousel() on them. We then return "this" in order to allow chaining of methods.

Accept an options argument to control plugin behavior

By creating an options argument, we can allow the users to expand/change the default behavior of the plugin. The following code adds in a newOptions parameter and then uses jQuerys built in $.extend to override the default plugin options.

Notice the following code it expands the default options:

Provide public access to secondary functions (as applicable)

We can give access to public functions by attching the functions to the magic variable "this".

Keep private functions private

Private functions setup in the way below can only be called from within the scope that they were created. What this means is that there is no outside access to these functions. They can only be called from within another public methods or another private methods. In order to access this data we would need to setup public methods to call these private methods.

Support the Metadata Plugin

Supporting the Metadata plugin is fairly trivial. We test for the existence of the plugin and then add the data that would be attached to the element.

Allow for extending the object via callbacks (either hooks and/or events)

In order to do this, lets take a more in depth look at the changeTab function. It sounds complicated, however its a trivial task to setup and allow the moveSlider functionality to be altered by the external options.

In order to alter the behavior we need to allow the user to pass in some options.

Now, lets update hooks function to see what needs to be done in order to call the function.

What exactly is this doing? First of all the hooks function takes 3 parameters. thisObject is equal to the object that you want the callback function to have "this" set to, a method to call back on called hookList and the name of the event to be triggered. The reason we call it list, is that we will check to see if hookList is an array of functions or just a single function. The following call passes in the tabs object and the onstart callbacks.

Now, lets change the this.changeTab to make use of the beforeLoad and afterLoad events.

In the hooks method we use the .apply in order to pass "this" as the plugin to the next function. They will have access to all of the public methods that are on that instance of the tabs plugin.

Scope all selectors with the 'this' object

This is actually really simple, but will control the scope of the objects returned by jQuery. Without this, you may clobber another widget on the page or jump outside of the element you are working on. Lets take another look at the selectTab method and see how we can scope our selectors.

On the surface, there is nothing wrong with this. However, what happens if we have two different tab groups on the page? Nothing? How about an extremely large DOM? Would this slow down? Yes, actually it would and you may or may not be acting on a set of tabs that aren't your own.

So how do we fix this?

Wait, that is the same code? Close, but look closer at the $(tabCSS) selector. Notice, we now use $(tabCSS, tabs). (You could also use $(tabs).find(tabCSS); is faster in most browsers). This limits the scope of the search for the tabs and it won't clobber any other tab widgets on the page.