Scriptble » jQuery

Getting A Class From a DOM Element

JC Fant IV — Fri, 13 May 2011 19:34:32 +0000

Lately, if I am searching for a way to do something in Javascript the only results I am getting ways of doing the procedure using jQuery. While, its true jQuery is pretty much the de facto standard for writing JavaScript anymore, understanding the underlying technology is a must. As well as alot of times, I don't need to load jQuery on the page just to get a DOM Element or its class.

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




	
		
			
				Text

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.

Writing and Updating DOM Elements in a Frame

JC Fant IV — Thu, 17 Feb 2011 00:30:45 +0000

Handling writing and updating objects in an iframe can be bothersome in most browsers. Sure things like jQuery tend to help, but not always.

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


	$("#FRAME").contents()

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


	$("#FRAME").contents().find("HEAD");

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


	$("#FRAME").contents().find("HEAD").append('');

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?


	var ifrm;
		
	function addElementToFrame(newStyle) {
		if (typeof ifrm == "undefined"){
			ifrm = document.getElementById('previewFrame');
			if (ifrm.contentWindow){
				ifrm = ifrm.contentWindow;
			}else{
				if (ifrm.contentDocument.document){
					ifrm = ifrm.contentDocument.document;
				}else{
					ifrm = ifrm.contentDocument;
				}
			}
		}
		
		/*
		 * Now that we have the document, lets add a new style tag
		 */
		$("HEAD", ifrm.document).append("");
		
	}

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?


	var ifrm;
		
	function addElementToFrame(newStyle) {
		if (typeof ifrm == "undefined"){
			ifrm = document.getElementById('previewFrame');
			if (ifrm.contentWindow){
				ifrm = ifrm.contentWindow;
			}else{
				if (ifrm.contentDocument.document){
					ifrm = ifrm.contentDocument.document;
				}else{
					ifrm = ifrm.contentDocument;
				}
			}
		}
		
		/*
		 * Now that we have the document, look for an existing style tag
		 */
		var tag = ifrm.document.getElementById("tempTag");
		
		/*
		 * Hmm, this doesn't look right, but it is. IE will not allow you 
		 * to use a pre-existing style tag and set the innerHTML for that 
		 * element. Which means, we can't create the style tag in another
		 * function and pass back the element and then set the innerHTML 
		 * to what we need. Plus, with this limitation, now we need to 
		 * actually remove the style element from the DOM and recreate 
		 * it each time. LAME.
		 */
		if (typeof tag != "undefined" || tag != null){
			$("#tempTag", ifrm.document).remove();
		}
		
		/*
		 * We only have one shot at writing out the style tag, we must 
		 * include the css at that point as well or IE will bail with an
		 * unsuported method exception.
		 *
		 * add a new style tag
		 */
		$("HEAD", ifrm.document).append("");
	}

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

Expanding the jQuery Plugin Development Pattern

JC Fant IV — Tue, 15 Feb 2011 01:00:25 +0000

Doing research on a recent project, I came across an article by Mike Alsup on a "jQuery Plugin Development Pattern". If you haven't seen it already its worth a trip to learningjquery.com to checkout the implementation of his pattern.

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

Claim only a single name in the jQuery namespace

Accept an options argument to control plugin behavior

-Provide public access to default plugin settings-

Provide public access to secondary functions (as applicable)

Keep private functions private

Support the Metadata Plugin

Allow for extending the object via callbacks (either hooks or events) as applicable

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.

Claim only a single name in the jQuery namespace
Accept an options argument to control plugin behavior
-Provide public access to default plugin settings-
Provide public access to secondary functions (as applicable)
Keep private functions private
Support the Metadata Plugin
**Allow for extending the object via callbacks (either hooks or events) as applicable**
**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.


	;(function($){
	})(jQuery);

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.


	;(function($){
	    $.fn.tabs = function(tabOptions) {
	        // support mutltiple elements
	        if (this.length > 1){
	            this.each(function() { $(this).tabs(tabOptions) });
	            return this;
			}
        }
	})(jQuery);

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.


        // support mutltiple elements
        if (this.length > 1){
            this.each(function() { $(this).tabs(tabOptions) });
            return this;
		}

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.


	;(function($){
    $.fn.tabs = function(tabOptions) {
        // support mutltiple elements
        if (this.length > 1){
            this.each(function() { $(this).tabs(tabOptions) });
            return this;
        }

        // SETUP private variabls;
        var tabs = this;

        // setup options
        var defaultOptions = {
								//default options go here.
                                };
								
        var options = $.extend({}, defaultOptions, tabOptions);

        return this;
    }
})(jQuery);

Notice the following code it expands the default options:


        var options = $.extend({}, defaultOptions, tabOptions);

Provide public access to secondary functions (as applicable)

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


	;(function($){
	    $.fn.tabs = function(tabOptions) {
	        // support mutltiple elements
	        if (this.length > 1){
	            this.each(function() { $(this).tabs(tabOptions) });
	            return this;
	        }
	
	        // SETUP private variabls;
	        var tabs = this;
	
	        // setup options
	        var defaultOptions = {
	                                    debug : false
	                                };
	        var options = $.extend({}, defaultOptions, tabOptions);


			// PUBLIC functions
	        this.changeTab = function() {
	            // change Tab
	        };
	
	        this.getOptions = function() {
	            return options;
	        };

	
	        return this;
	    }
	})(jQuery);

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.


	;(function($){
	    $.fn.tabs = function(tabOptions) {
	        // support mutltiple elements
	        if (this.length > 1){
	            this.each(function() { $(this).tabs(tabOptions) });
	            return this;
	        }
	
	        // SETUP private variabls;
	        var tabs = this;
	
	        // setup options
	        var defaultOptions = {
	                                    debug : false
	                                };
	        var options = $.extend({}, defaultOptions, tabOptions);

	        // SETUP private functions;
	        var intialize = function() {
					return tabs;
	        };
			
	        var findTabs = function() {
	                                // do something .
	                            };
								
			var selectTab = function(element, tabCSS, selectedClass){
									// do something .
								};
								
	        var hooks = function() {
	                                // do something .
	                            };
			
			// PUBLIC functions
	        this.changeTab = function() {
	            // change Tab
	        };
	
	        this.getOptions = function() {
	            return options;
	        };
	
	        return intialize();
	    }
	})(jQuery);

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.


	;(function($){
	    $.fn.tabs = function(tabOptions) {
	        // support mutltiple elements
	        if (this.length > 1){
	            this.each(function() { $(this).tabs(tabOptions) });
	            return this;
	        }
	
	        // SETUP private variabls;
	        var tabs = this;
	
	        // setup options
	        var defaultOptions = {
	                                    debug : false
	                                };
	        var options = $.extend({}, defaultOptions, tabOptions);

	        // SETUP private functions;
	        var intialize = function() {
	                // support MetaData plugin
	                if ($.meta){
	                    options = $.extend({}, options, this.data());
	                }

					return tabs;
	        };
			
	        var findTabs = function() {
	                                // do something .
	                            };
								
			var selectTab = function(element, tabCSS, selectedClass){
									// do something .
								};
								
	        var hooks = function() {
	                                // do something .
	                            };
			
			// PUBLIC functions
	        this.changeTab = function() {
	            // change Tab
	        };
	
	        this.getOptions = function() {
	            return options;
	        };
	
	        return intialize();
	    }
	})(jQuery);

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.


	// PUBLIC functions
    this.changeTab = function() {
        // change Tab
    };

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


    // setup options
    var defaultOptions = {
								beforeLoad : function() {
												// do something .
											},
								afterLoad : function() {
												// do something .
											},
                                debug : false
                            };

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

	   
        var hooks = function(thisObject, hookList, triggerName){
            $(presentation).trigger(triggerName, thisObject);
            if ($.isFunction(hookList)){
                return hookList.apply(thisObject, []).isOK;
            } else if ($.isArray(hookList)) {
                var result = {
                    isOK: true
                };
                for (var i = 0; i < hookList.length; i++) {
                    if (result.isOK) {
                        result = hookList[i].apply(thisObject, [ result.data ]);
                    }
                }
                return result.isOK;
            }else{
                return true;
            }
        }

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.


	this.changeTab = function(element){
		if (hooks(tabs, options.beforeLoad, "beforeLoad")){
			selectTab(element, options.tabsClass, options.tabsSelected);
			
			var tabOptions = {};
			if (options['tab' + tabs.mainTab] != undefined) {
				tabOptions = options['tab' + tabs.mainTab];
			}
			
			$(options.tabPanels, this).hide();
			
			if (options.afterLoad != undefined) {
				hooks(tabs, options.afterLoad, "afterLoad")
			} else {
				$('.tab' + tabs.mainTab, this).show();
			}
		}
	};

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.


         var selectTab = function(element, tabCSS, selectedClass){
              var selectedTab = 0;
              selectedClass = selectedClass.replace(/^./, "");
              $(tabCSS).each(function(){
                   if (this == element) {
                        tabs.mainTab = selectedTab;
                        $(element).addClass(selectedClass);
                   } else {
                        $(this).removeClass(selectedClass);
                   }
                   selectedTab++;
              });
         };

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?


         var selectTab = function(element, tabCSS, selectedClass){
              var selectedTab = 0;
              selectedClass = selectedClass.replace(/^./, "");
              $(tabCSS, tabs).each(function(){
                   if (this == element) {
                        tabs.mainTab = selectedTab;
                        $(element).addClass(selectedClass);
                   } else {
                        $(this).removeClass(selectedClass);
                   }
                   selectedTab++;
              });
         };

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.

jQuery 1.5 Deferreds

JC Fant IV — Sun, 13 Feb 2011 02:59:18 +0000

Eric Hynds on his blog the other day gave a very good run down of jQuery 1.5 Deferreds. From the post:

Deferreds, new in jQuery 1.5, decouple logic dependent on the outcome of a task from the task itself. They’re nothing new to the JavaScript scene; Mochikit and Dojo have implemented them for some time, but with Julian Aubourg’s AJAX rewrite landing in 1.5, deferreds in jQuery was the logical next step. With deferreds, multiple callbacks can be bound to a task’s outcome, and any of these callbacks can be bound even after the task is complete. The task in question may be asynchronous, but not necessarily.

Especially nice is being able to couple multiple statements and once they finish being able to go on to the next step.

In the following example, we retrieve JSON data and a separate template, once the calls finish we move onto rendering them using Underscore.js templating.


var JSONData = {};
var template = "";
function loadData(data){
     JSONData = data;
}

function loadTemplate(data){
     template = data;
}

function render {
     var output = _.template(template, { employeeList : employeeList } );
     $(document.getElementById("output")).html(output);
}

$.when(
     $.getJSON("JSONData").success(loadData), 
     $.get("template.tmpl").success(loadTemplate)
).then(
   render
);

Deferreds in jQuery is step in the right direction and adds in some very nice functionality to an already feature rich library.

$(“#ID”) is fast enough

JC Fant IV — Sat, 12 Feb 2011 22:22:38 +0000

We all know that the fastest selector to use is the ID. Something like $("#id") is better than using a class. However, after looking at the last test we did on The Great Assumption - JavaScript I noticed a large discrepancy in $("#ID") versus the native document.getElementById().

Now, I always assumed it was slower, but not anywhere near close to what I saw. So, lets challenge the assumption that $("#ID") is good enough.

Setting up the Test

You can see the test here: JSPerf $(doc.getElementById()) versus $("#id")

I wanted to test 3 of the latest versions of jQuery, same as the last test. I added the following to the test:

The Tests

So lets setup the actual tests:


		//getElement - 1.4.2
		$142(document.getElementById("button"));
		
		//ID - 1.4.2
		$142("#button");
		
		
		//getElement - 1.4.4
		$144(document.getElementById("button"));

		//ID - 1.4.2
		$144("#button");
		
		//getElement - 1.5
		$15(document.getElementById("button"));
		
		//ID - 1.4.2
		$15("#button");

Each one of the tests above will run and the result will be returned in Ops/Sec.

Results

After runs in all different versions of the browsers we have a fairly good idea of the results. Take a look below.

Native Browser Call Results

From the last test we know that getting a Node Element from the native browser call is suprisingly efficient and fast in many browsers. Well, that is unless you are using IE 6, 7, 8 or even the beta 9.

jQuery $("#ID") Results

The results from this test show that getting an ID using jQuery is much faster than using the class selector. However, it is way behind the native call. The root cause of this is actually due to how the init function is configured. Looking at the source for 1.5, an ID selector will hit 6 IF statements, plus 1 regex before it makes the native document.getElementByID(). After the call, there is a series of browser compatibility checks before it assigns the Node Element to the jQuery object and returns.


init: function( selector, context ) {
	var match, elem, ret, doc;

	// Handle $(""), $(null), or $(undefined)
	if ( !selector ) {
		return this;
	}

	// Handle $(DOMElement)
	if ( selector.nodeType ) {
		this.context = this[0] = selector;
		this.length = 1;
		return this;
	}
	
	// The body element only exists once, optimize finding it
	if ( selector === "body" && !context && document.body ) {
		this.context = document;
		this[0] = document.body;
		this.selector = "body";
		this.length = 1;
		return this;
	}

	// Handle HTML strings
	if ( typeof selector === "string" ) {
		// Are we dealing with HTML string or an ID?
		match = quickExpr.exec( selector );

		// Verify a match, and that no context was specified for #id
		if ( match && (match[1] || !context) ) {

			// HANDLE: $(html) -> $(array)
			if ( match[1] ) {
				doc = (context ? context.ownerDocument || context : document);

				// If a single string is passed in and it's a single tag
				// just do a createElement and skip the rest
				ret = rsingleTag.exec( selector );

				if ( ret ) {
					if ( jQuery.isPlainObject( context ) ) {
						selector = [ document.createElement( ret[1] ) ];
						jQuery.fn.attr.call( selector, context, true );

					} else {
						selector = [ doc.createElement( ret[1] ) ];
					}

				} else {
					ret = jQuery.buildFragment( [ match[1] ], [ doc ] );
					selector = (ret.cacheable ? ret.fragment.cloneNode(true) : ret.fragment).childNodes;
				}
				
				return jQuery.merge( this, selector );
				
			// HANDLE: $("#id")
			} else {
				elem = document.getElementById( match[2] );

				// Check parentNode to catch when Blackberry 4.6 returns
				// nodes that are no longer in the document #6963
				if ( elem && elem.parentNode ) {
					// Handle the case where IE and Opera return items
					// by name instead of ID
					if ( elem.id !== match[2] ) {
						return rootjQuery.find( selector );
					}

					// Otherwise, we inject the element directly into the jQuery object
					this.length = 1;
					this[0] = elem;
				}

				this.context = document;
				this.selector = selector;
				return this;
			}

		// HANDLE: $("TAG")
		} else if ( !context && !rnonword.test( selector ) ) {
			this.selector = selector;
			this.context = document;
			selector = document.getElementsByTagName( selector );
			return jQuery.merge( this, selector );

		// HANDLE: $(expr, $(...))
		} else if ( !context || context.jquery ) {
			return (context || rootjQuery).find( selector );

		// HANDLE: $(expr, context)
		// (which is just equivalent to: $(context).find(expr)
		} else {
			return jQuery( context ).find( selector );
		}

	// HANDLE: $(function)
	// Shortcut for document ready
	} else if ( jQuery.isFunction( selector ) ) {
		return rootjQuery.ready( selector );
	}

	if (selector.selector !== undefined) {
		this.selector = selector.selector;
		this.context = selector.context;
	}

	return jQuery.makeArray( selector, this );
},

Notice the elem = document.getElementById( match[2] ) on line 58. This is the part where it delegates its call to the native function.

HOWEVER, what is that on line 9? A use case for $(DOMElement)? Why yes, yes it is, and that leads us to the next test.

Hybrid Results

So by selecting the DOM Element, and passing it into to jQuery we have achieved nearly 100% or more increase in speed across all browsers (except IE). IE still benefits from this method, it had a 49% increase in operations per second.

Hybrid Results

Here you can clearly see that by using a hybrid solution we have achieve a significant amount of gain over using the built in jQuery ID selector. Its not nearly as fast, but allows us to benefit from the built-in functions of jQuery and speed up the operation.

Do This, Not That

Not exactly what I expected when I set out on this one. However I think we have a clear winner. IF you are using jQuery, pass the node Element in, other wise just use the native getElementById().

Conclusion

Do This


		$(document.getElementById("someId"));

Not That


		$("#someId");

The Great Assumption – Javascript

JC Fant IV — Fri, 11 Feb 2011 04:52:28 +0000

A couple of weeks ago I was sitting down with a Google Frontend Engineer friend of mine, talking about some of the JavaScript best practices we all have come to know and abide by. I found myself in agreement with 90% of everything we were talking about. However, something kept eating at me. Why do we both agree on these things? Is it because we actually sat down and did some test? Or is more because early in our careers we were told it was the correct way and have never gone about challenging our assumptions.

So with this post, I am going to start challenging our assumptions on what's right, OR validate those assumptions with some documented proof. Thus begins our first in a series of posts about performance, and a "Do this, Not that" series. Some of the posts will focus on jQuery, others on core JavaScript, however all of them should give you some insight on what to do in the future.

Find Versus Context

Everyone has heard that we should scope our requests in jQuery to make sure and only return results that we are looking for. This is especially true if we are writing a plugin. And lately I have been hearing we should be using .find() to get the elements we are looking for.

Of course, that peaked my interest. Why use .find() which I had heard was slower, than using $("", context) which scopes the call in much the same way in jQuery. So I set off to write a Performance Test that would check to see which one I should be using.

Setting up the Test

You can see the test here: JSPerf jQuery Find Versus Context versions 1-4-2 to 1-5

I wanted to test 3 of the latest versions of jQuery, plus the browsers native docuemnt.getElementById(). so I added the following to the test:

Notice that I am going to set a variable for each of the individual jQuery versions. This allows me to use multiple version in the noConflict() state. (They won't overwrite each other and I will be able to have all of them on the same page.) Also, I setup a couple of variables that I want to cache the results. If we had to call this for each of the tests, we wouldn't get an accurate result between a find and context search.

The Tests

So lets setup the actual tests:


	//Get - document
	var item = document.getElementById("button");

	//Get - ID 1.4.2
	var item = $142("#button");

	//Get - ID 1.4.4
	var item = $144("#button");

	//Get - ID 1.5
	var item = $15("#button");

	//Context - ID 1.4.2
	var item = $142("#button", context42);

	//Context - ID 1.4.4
	var item = $144("#button", context44);

	//Context - ID 1.5
	var item = $15("#button", context5);

	//Find - ID 1.4.2
	var item = context42.find("#button")

	//Find - ID 1.4.4
	var item = context44.find("#button")

	//Find - ID 1.5
	var item = context5.find("#button")

	//Get - Class 1.4.2
	var item = $142(".buttonRef");

	//Get - Class 1.4.4
	var item = $144(".buttonRef");

	//Get - Class 1.5
	var item = $15(".buttonRef");

	//Context - Class 1.4.2
	var item = $142(".buttonRef", context42);

	//Context - Class 1.4.4
	var item = $144(".buttonRef", context44);

	//Context - Class 1.5
	var item = $15(".buttonRef", context5);

	//Find - Class 1.4.2
	var item = context42.find(".buttonRef")

	//Find - Class 1.4.4
	var item = context44.find(".buttonRef")

	//Find - Class 1.5
	var item = context5.find(".buttonRef")

Each one of the tests above will run and the result will be returned in Ops/Sec. At this point, we are going to run a test to figure out how fast a context.find(""), $("", context) take for an ID and for a class. I also added in a default document.getElementById() to test how fast natively the browser is able to get a Node Element.

Results

After runs in all different versions of the browsers we have a fairly good idea of the results. Take a look below.

Find a class element Results

In General this test held true. Using find in all but FF3 and Opera is a faster way to find an element using a class.

Conclusion

Do This


		context.find(".someclass");

Not That


		$(".someclass");

Find an element by ID Results

WOW, not what I expected. Not one browse was a find faster than just using $("#someID"). Basically this all boils down to how jQuery treats an ID selector. It doesn't use the sizzle engine to query the Node Element, but uses the browsers built in document.getElementById(). However, if you pass in a context jQuery will use the engine to make sure the element falls within the context you are using.

Conclusion

Do This


		$("#someID");

Not That


		context.find("#someId");
		$("#someId", context);

Find an element using built in getElementById() Results

Ok, so this result really confused me after seeing the jQuery $("#someID") results. I wasn't expecting there to be such a discrepancy in operations per second. After seeing this result, I actually started putting together another post. Which will end up the second part of this series.

It should be noted that Chrome, Opera, Safari and FF are all doing well over a million operations per second in this area.

IE breakdown

After seeing the results above, I thought we needed one more graphic showing the extremely bad numbers IE put up in this test. There was no noticable change between IE6 and IE7, and while IE8 is better, its still bad. However, it looks like the IE9 team is finally taking web development seriously and trying to make some improvements. Of course those improvements still fall WAY short of any of the other browsers on the market.

Come on IE team, haven't we learned anything from the IE6 debacle?

Conclusion

Overall, the conlusion here is to never use a context based find/search for an ID. (since there is always only one on the page... right?) If you need to get an element using an ID, just call it via $("#someID").

IF you need to get a class element(s), follow this rule:
context.find() > $(".someClass", context) > $(".someclass");

Next Article >> $(“#ID”) is fast enough

JavaScript Performance Testing – An Indispensable Tool

JC Fant IV — Tue, 08 Feb 2011 05:36:23 +0000

Over the course of the last couple of weeks I have been looking into various tools to test Javascript Pefromance. I needed a way to test various JavaScript code snippets to see the overall latency/run time of each. I started looking for a way to manage the tests and be able to reference them in an easy way. Here are a couple of the performance suites I looked at and afterwards, my decision.

JSLitmus

You can find the source for JSLitmus here. It has a great set of features and allows you to install it on your own site. So here are some pros and cons I found when setting up JSLitmus.

Pros:

Single-file install (JSLitmus.js)
Works on Firefox, Opera, Safari, IE, Google Chrome, and iPhone browsers
Adaptive test cycles – tests take ~1-2 seconds, regardless of the operation
Google Chart + TinyUrl integration
Open Source MIT-style license (see source)

source: <http://www.broofa.com/Tools/JSLitmus/>

Cons:

Need to host this on your own server.
Need a place to save off/Manage existing Tests.
Some tests report “Infinity” when run, which meant that the tests were executing so fast that it couldn’t get an accurate read on the total OPS/Sec.

Conclusion:

JSLitmus is a nice set of tools. If you have access to your own host and are able to put together a way to manage the tests, I would recommend this is a possible solution. However, I did not go with this solution.

JSPerf

I found JSPerf.com after digging through the posts that Paul Irish’s put together about jQuery. 10 Things I Learned from the jQuery Source and 11 More Things I Learned from the jQuery Source. If you haven’t had a chance to read those, I highly recommend them, they help to give you a bit more information on whats going on in jQuery. They are also what lead me down the path to figure out why certain queries are slower than others, but thats another post all together.

Pros:

JSPerf is based on benchmark.js a very powerful performance testing suite.
Has an online environment to store and test JS
You can download the source and run it on your own host.
You can browse through other peoples tests, make changes and save copies.
You can see most popular tests
Has quick links to embed common JS frameworks
Uses a java jar to refine time calculations rather than just relying on JavaScripts built in time.

Cons:

Browsing tests is a pain in the online tool
Saving a copy of a test just adds a revision number to the end of the url rather than allowing you to create a new url for the test.
Sometimes test runs aren’t saved off properly. I noticed this on my Mac using Safari 5.0.3

Conclusion:

JSPerf seems to be able to handle all the aspects I need for everyday performance needs. I will be setting up a copy on this host, just so I can keep my own tests around and not need to bookmark them for reference later on.

Conclusion

Overall, I think JSPerf is the hands down winner at this point. Doesn’t mean I won’t find a better solution down the road, but for now, being able to quickly write a test on jsPerf and just run it to see how well it performs is much easier than hosting my own performance suite.

In the next couple of days I will be posting some of my performance test runs and some of the conclusions based on those results.

Underscore.js Templates

JC Fant IV — Sat, 29 Jan 2011 00:00:54 +0000

After the post about why Underscore.js, I think it is best to follow up on one of the best parts of the library. Now, I haven’t had a chance to go through the new templating in jQuery, however what I have found with Underscore.js has allowed me to complete some very complicated tasks in my day to day work.

Lets take a look at the documentation for _.template and then we will dig into it a bit more:

template_.template(templateString, [context])
Compiles JavaScript templates into functions that can be evaluated for rendering. Useful for rendering complicated bits of HTML from JSON data sources. Template functions can both interpolate variables, using

<%= ... %>, as well as execute arbitrary JavaScript code, with <% ... %>. When you evaluate a template function, pass in a context object that has properties corresponding to the template’s free variables. If you’re writing a one-off, you can pass the context object as the second parameter to template in order to render immediately instead of returning a template function.
var compiled = _.template("hello: <%= name %>"); compiled({name : 'moe'}); => "hello: moe" var list = "<% _.each(people, function(name) { %> <%= name %> <% }); %>"; _.template(list, {people : ['moe', 'curly', 'larry']}); => " moe curly larry "
Pasted from <http://documentcloud.github.com/underscore/>

So what can we do with this? Lets take a look at showing some employee data:

Standard Templating


var employeeList = [
                        {
                            name     : "John smith",
                            position : "CEO",
                            pay      : 1,
                            hours    : 2020,
                            type     : "USD"
                        },
                        {
                            name     : "Jane Smith",
                            position : "CFO",
                            pay      : 2,
                            hours    : 2020,
                            type     : "USD"
                        },
                        {
                            name     : "Alex Smith",
                            position : "Lead Programmer",
                            pay      : 500,
                            hours    : 2020,
                            type     : "EUR"
                        }
                    ];
var template = "\
                \
                    \
                        \
                             \
                             \
                             \
                             \
                             \
                             \
                         \
                        <% for (var index = 0; index < employeeList.length; index++){ %>\
                            <% var employee = employeeList[index]; %>\
                            <% var compensation = employee.hours * employee.pay; %>\
                            \
                                 \
                                 \
                                 \
                                 \
                                 \
                                 \
                             \
                        <% } %>\
                     \
                Name Position Pay Hours Type Total Compensation
<%= employee.name %> <%= employee.position %> <%= employee.pay %> <%= employee.hours %> <%= employee.type %> <%= compensation %> \
                ";
$(document).ready(function() {
    var output = _.template(template, { employeeList : employeeList } );
    $("#employeeContainer").html(output);
});

The corresponding output is below:

Now, if we were requesting the data from an Ajax call based on some parameters this would make it a bit more interesting, but you can get a feeling for how to take data and a view for that data and output something that actually makes sense.

So lets dig a bit more into the different tags, and why the \ is on each line.

JavaScript does not handle multiple line strings (why, no idea but it would be really helpful to have multi line strings. Even if they used something like the perl EOF delimiter to figure out where the end of the string should be, but I digress). In order to have a multi-line string, we need to add the \ (backslash) to the end of each line to tell the JavaScript parser that there is more on the next line.
Note that the string is started using the double quote “, which means we need to make sure anything in the string that is quoted is either in single quotes or escaped using the backslash. e.g. \”
<% versus <%=
1. So this is a bit more complicated, if you want to use straight Javascript and don’t want the output on the line we need to use <%. Also, if you use <% you MUST add a semi-colon ; at the end of the JavaScript line and then follow it with the %> to enclose the line of JS.
2. <%= is the way we actually print out the variables to the template. With this tag, DO NOT put a semi-colon ; at the end of the line or the template will break.

Dynamic Templating With Includes

There is one more thing we should look at. Templating is nothing without includes, so how on earth do you create an include with this system. Well, we can use some other magic that would allow us to access template from other templates.

So lets modify the script a bit, and see what we can do.


var template2 = "\
                \
                    \
                        \
                             \
                             \
                             \
                             \
                             \
                             \
                         \
                        <% for (var index = 0; index < employeeList.length; index++){ %>\
                            <% var employee = employeeList[index]; %>\
                            <% var compensation = employee.hours * employee.pay; %>\
                            \
                                 \
                                 \
                                 \
                                 \
                                 \
                                 \
                             \
                        <% } %>\
                     \
                Name Position Pay Hours Type Total Compensation
<%= Label.getHTML({ name : employee.name }) %> <%= employee.position %> <%= employee.pay %> <%= employee.hours %> <%= employee.type %> <%= compensation %> \
                ";
var Label = new function() {
    var template = "<%= name %>";
    this.getHTML = function(data) {
        return _.template(template, data);
    };
};
$(document).ready(function() {
    var output = _.template(template2, { employeeList : employeeList } );
    $("#employee2").html(output);
});

The corresponding output is below:

Overall with this method of templates and includes we can make very complex sites with a clear separation of data and views.

Underscore.js

JC Fant IV — Wed, 26 Jan 2011 00:00:52 +0000

Coming from a more technical backend role, and moving into JavaScript many people tend to look for very common functions to make their life easier. However, since JavaScript is considered a "functional" programming language, most of those little conveniences are currently unsupported. So I went searching a bit. Turns out there is a nice little utility belt library that gives us access to all of those built-in methods we all take for granted and are about to be supported in ECMAScript 5.

As the guys over at Underscore.js put it:

Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming support that you would expect in Prototype.js (or Ruby), but without extending any of the built-in JavaScript objects. It's the tie to go along with jQuery's tux.

Underscore.js uses the built in functions if they exist, and if they don't falls back to its own version. Since there are only a few browsers that currently support ECMAScript 5, it allows us to use these functions even on older browsers. Now, not only can we start using those constructs before they are officially supported in the browsers, but as soon as they become available underscore.js will get out of the way.

Here is the current list of who supports ECMAScript 5 and which calls are supported: http://kangax.github.com/es5-compat-table/ At the time of this writing it looks like underscore wouldn't even be needed in IE9, FF4, Chrome 7,8,9 and is only partialy needed in Opera 10.5-11.

Another key point about underscore.js is they do NOT extend any of the built in JavaScript objects. That means, all your existing objects will continue to work as expected. You won't have to worry about underscore.js adding methods to some of your current objects:

var someArray = [1, 2, 3];

for (var i in someArray){ //do something to someArray[i] }

We don't need to worry that someArray will now contain a new function that would be returned in the loop. Couple that with all of the new features we can now use, and this looks like a win/win for Frontend Engineers.

Lets take a look at some of the things we get with the library:

Object-Oriented and Functional Styles

Collections

each, map, reduce, reduceRight, detect, select, reject, all, any, include, invoke, pluck, max, min, sortBy, sortedIndex, toArray, size

Arrays

first, rest, last, compact, flatten, without, uniq, intersect, zip, indexOf, lastIndexOf, range

Functions

bind, bindAll, memoize, delay, defer, throttle, debounce, wrap, compose

Objects

keys, values, functions, extend, clone, tap, isEqual, isEmpty, isElement, isArray, isArguments, isFunction, isString, isNumber, isBoolean, isDate, isRegExp isNaN, isNull, isUndefined

Utility

noConflict, identity, times, mixin, uniqueId, template

Chaining

chain, value

Pasted from <http://documentcloud.github.com/underscore/>

There are a couple of things I want to quickly look at. First, how are they making sure that we use the built-in method if it exists, and second… does that say template?

So Lets take a quick look at the _.each() function to see how they use built-in functions if they exist.

// The cornerstone, an `each` implementation, aka `forEach`. // Handles objects implementing `forEach`, arrays, and raw objects. // Delegates to **ECMAScript 5**'s native `forEach` if available. var each = _.each = _.forEach = function(obj, iterator, context) { var value; if (obj == null) return; if (nativeForEach && obj.forEach === nativeForEach) { obj.forEach(iterator, context); } else if (_.isNumber(obj.length)) { for (var i = 0, l = obj.length; i < l; i++) { if (iterator.call(context, obj[i], i, obj) === breaker) return; } } else { for (var key in obj) { if (hasOwnProperty.call(obj, key)) { if (iterator.call(context, obj[key], key, obj) === breaker) return; } } } };

So if we look a bit more into what they are doing, it looks like they check to see if the object has a function called .forEach(); if it does, use the built-in function, otherwise figure out if it’s an array or object.

As for the second item in this list. I am going to devote another post just to templates, how we can use them and make them a bigger part of our frontend projects.

Finding an Element outside of your current iframe

JC Fant IV — Wed, 19 Jan 2011 19:37:20 +0000

Sometimes you are working within an iframe and need to be able to check for an element outside of that frame. It sounds simple enough, and you are right. The following bit of code grabs an element outside of your current iframe:


    if (typeof window.parent != "undefined"){
         window.parent.document.getElementById("SOMEID");
    }

Pretty simple! Now, lets look at a use case where you might actually need to do something like this. We will use jQuery to grab all of the links outside of the iframe and set an onclick event that will stop the link from working:


     $("A", window.parent.document).click(function(e, data) {
           // "this" is now the A that was clicked
           console.log($(this));
           e.preventDefault();
      });

Now, we couple that with some jQuery UI magic and we can create a nice modal dialog box to pop up when a user clicks and prompt them to make sure they want to navigate away from the current page.


     $("A", window.parent.document).click(function(e, data) {
            // prevent the link from redirecting the page
            e.preventDefault();

            // "this" is now the A that was clicked
            var url = $(this).attr('href');

            // create a modal dialog box to prompt the user from leaving the page
            var dom = 'Leave Page OR ' +
'Stay';


            var modal = $(dom).dialog({
                  modal: true,
                  resizable: false,
                  draggable: false,
                  closeOnEscape: false,
                  dialogClass: "no-titlebar loading-bar dialog-emphasis",
                  width: width || 250,
                  minHeight: height || 50
            });            

            // setup the actions for each of the links in the modal dialog
            $(".leave", modal).click(function(ev, data){
                        window.parent.location.href = url;
            );

            $(".stay", modal).click(function(ev, data){
                        modal.dialog('close');
            });
      });

* The dom string is causing issues with the syntax highlighter, which is why its on multiple lines, it should all be on one line. And there you have it, a modal dialog overlay preventing the page from being unloaded without user consent.

Name	Position	Pay	Hours	Type	Total Compensation
<%= employee.name %>	<%= employee.position %>	<%= employee.pay %>	<%= employee.hours %>	<%= employee.type %>	<%= compensation %>