One of the things I found recently when I discovered this was quickly writing out DOM elements and then Removing them.

Example

Take the following code, it appends a Node element to the DOM. As soon as the onload or onerror function is fired it removes the element.

var urls = [
...
];

for (var i = 0; i <= urls.length; i++){
	addObjectElement(url);
}

function addObjectElement(url){
	var obj = document.createElement("object");
	obj.data = url;
	
	obj.onload = obj.onerror = function() { removeElement(obj) };
	
	document.appendChild(obj);	
}

function removeElement(item) {
	var parent = item.parentElement;
	p.removeChild(item);
}

The previous could would end up causing an issue where FireFox would actually think it was still working. Thus creating the "Connecting" issue and the spinning icon.

How do we fix it?

Well, actually the fix is simple. If you wait a small amount of time to actually do the removal, firefox will unlock the thread rendering it back to the being normal.

Let's take a look.

The fix

var urls = [
...
];

for (var i = 0; i <= urls.length; i++){
	addObjectElement(url);
}

function addObjectElement(url){
	var obj = document.createElement("object");
	obj.data = url;
	
	obj.onload = obj.onerror = function() { setTimeout(function(){ removeElement(obj)}, 5); };
	
	document.appendChild(obj);	
}

function removeElement(item) {
	var parent = item.parentElement();
	p.removeChild(item);
}

Once we add the setTimeout to the code, even at a small 5ms delay, we unlock the thread and cause firefox to resume normal operation.

Create the iframe

We need to create the iframe without using a src. This way the browser won’t try to load anything into the frame itself.

	var docElem = window.document;
	var iframe = doc.createElement("iframe");
	iframe.height = iframe.width = 0;
	docElem.appendChild(iframe);

Notice we created a 0x0px iframe that we appended to the DOM

Add some content

Now, we just need to add some items to the newly created iframe.

	iframe.document.appendChild(obj);

Hmm, that isn’t working properly in all browsers. Well it turns out, first you need to actually get the proper content window for the iframe before we write to it.

Getting the proper content window to write to an iframe

	if (iframe.contentWindow){
	        iframe = iframe.contentWindow;
	}else{
	        if (iframe.contentDocument && iframe.contentDocument.document){
	                iframe = iframe.contentDocument.document;
	        }else{
	                iframe = iframe.contentDocument;
	        }
	}

Now that we actually have the proper context to be able to write to the iframe, lets take a look at how to do it.

Properly writing to an iframe

var img = document.createElement("img");
img.src = "someurl.jpg";
iframe.document.open();
iframe.document.appendChild(obj);
iframe.document.close();

Putting it all together in one place

Here is the full code in one place to see how it works

	var docElem = window.document;
	var iframe = doc.createElement("iframe");
	iframe.height = iframe.width = 0;
	docElem.appendChild(iframe);

	if (iframe.contentWindow){
	        iframe = iframe.contentWindow;
	}else{
	        if (iframe.contentDocument && iframe.contentDocument.document){
	                iframe = iframe.contentDocument.document;
	        }else{
	                iframe = iframe.contentDocument;
	        }
	}

	var img = document.createElement("img");
	img.src = "someurl.jpg";
	iframe.document.open();
	iframe.document.appendChild(obj);
	iframe.document.close();

Summary

Why would you use a hidden iframe to show an image? Well, the reason is more about caching items in a browser than actually showing an image. Truth be told, many of the major websites use something similar to cache content for subsequent pages on the site. The technique is different and each browser requires some special logic. But the gist of it remains the same. So the next time you need to create an iframe and write to it, this is the proper techinique.

1. create an iframe
2. append the iframe to the DOM (otherwise, the iframe element doesn’t have the proper content window to discover)
3. detect the content window
4. open the iframe to writing
5. write to the iframe
6. close the iframe
7. Get Beer!

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:


<html>
<head>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript" charset="utf-8"></script>

<script>
$("form").submit(function(){
return false;
});
</script>
<form id="uriForm" action="">
<input type="textbox" name="uriInput" id="uriInput" />
<input type="submit" value="submit" id="submit" />
</form>
</body>
</html>


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


<head>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js" type="text/javascript" charset="utf-8"></script>

<script>
$("form").submit(function(){
return false;
});
</script>
</head>


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


$(document).ready(function() {
$("form").submit(function() {
return false;
});
})


.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.


$(document).delegate("form", function() {
$("form").submit(function() {
return false;
});
})


.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.


$(document).ready(function() {
$("form").live("submit", function() {
return false;
});
})


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:


function Person(name) {
this.personName = name || "John";
}

var jason = Person("jason");
console.log(typeof jason); // undefined
console.log(jason instanceof Person); // false
console.log(window.personName); // jason


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.


function Person(name) {
var that = {};
that.personName = name || "John";

var jason = Person("jason");
console.log(typeof jason); // Object
console.log(jason instanceof Person); // false
console.log(jason.personName); // jason
console.log(window.personName); // undefined


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”.


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

var jason = Person("jason");
console.log(typeof jason); // Object
console.log(jason instanceof Person); // true
console.log(jason.personName); // jason
console.log(window.personName); // undefined


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


function ClosurePattern() {
this.someMethod = function someMethod() {
console.log('foo');
}
}


Setting up the Prototypal Pattern


function PrototypalPattern() {}
PrototypalPattern.prototype = {
someMethod: function() {
console.log('foo');
}
}


Setting up the Prototypal Hoisting Pattern


function sm() {
console.log("foo")
}

function PrototypalWithHoisting() {}
PrototypalWithHoisting.prototype = {
someMethod: sm
}


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.