Eric Hynds » JavaScript

Working With XML, jQuery, and JavaScript

Eric Hynds — Sun, 29 Aug 2010 16:44:34 +0000

A recent requirement of mine was to convert large CSV files to XML, and then build an accompanying interface to update & manage the data. jQuery was most useful for traversing & manipulating the large DOM’s, but I did run across a few gotcha’s worthy of discussion. There doesn’t seem to be much info on the interwebs about XML and jQuery outside of an XHR request, so here’s what I picked up along the way.

You cannot pass an XML string to jQuery’s constructor

Well technically you can, but it’s not supported and jQuery will not treat the string as XML. You’ll still be working with an HTML document object. jQuery has no idea/doesn’t care that the elements are not valid HTML elements though, so this might be just fine as long as your XML remains detached from the DOM. To feed XML to jQuery correctly, you must pass a parsed XML string (a la XML object) to jQuery’s constructor.

A new feature ticket exists to add cross-browser XML compatibility to jQuery, whose summary yields another good nugget of info:

As documented, the $(“”) method only supports parsing HTML strings, but users often try to parse XML strings with it. This doesn’t work since jQuery uses the .innerHTML property for parsing and implicitly enforces HTML rules on the string. IE in particular will throw errors or misparse XML strings passed to $() in this way.

Furthermore, the second you try to pass any sizable XML or HTML string to jQuery’s constructor, Firefox 3 is going to fail with a “script stack space quota is exhausted” error (see the bug report filed with Mozilla).

As Dave Methuin (core team member) explains:

Firefox seems to be dying on the constructor check for HTML, which uses a RegExp?:

match = quickExpr.exec( selector );

The string you’re passing in is long and html-ish, and I suspect Firefox is backtracking heavily trying to match the huge string. We can either assume a long (>1K chars) string must be HTML or come up with a RegExp? that doesn’t need to backtrack so much.

So how do you convert a string to an XML object? It depends on your browser.

Parse an XML string into a DOM

The following only applies if you’re manually parsing an string. If using XMLHttpRequest the browser does all this automatically – just use the responseXML property.

To re-iterate, jQuery alone is not capable of parsing XML strings. You will need to leverage the DOM parsing method baked into the browser, which all support in one form another. Firefox, Chrome, and Safari have a DOMParser object, and IE uses their proprietary ActiveX object. To create a cross-browser solution:

This snippet checks for the absence of DOMParser in the window scope, and if true, defines it. If the browser has an ActiveXObject (IE), the MLXML.DomDocument method is used to convert the string to an DOM. If ActiveXObject isn’t present but XMLHttpRequest is (fail-safe), a pseudo AJAX request is created and the parsed string is returned in the responseXML property of XMLHttpRequest.

Now that we have a normalized DOMParser, parsing XML is easy:

Converting an XML DOM back to a string

Again, IE has a different implementation than everyone else, but it’s still trivial to normalize. Firefox/Chrome/Safari use the XMLSerializer.serializeToString method, whereas IE has an “xml” property on the XML object.

$.data() is unreliable

First a note on how $.data actually works. When jQuery is loaded, $.expando is set to the current timestamp prefixed with “jQuery”. Expando becomes the name of a property set on elements when data is added via $.data/$.fn.data. The expando’s value is a UUID and acts as jQuery’s link back to the proper store in $.cache – where the data is actually stored. Each key in the $.cache object is the UUID.

That said, the ActiveX object that IE uses for XML parsing has issue with jQuery trying to set expando properties on elements. And instead of working around this issue, it appears that the solution will be to document the fact that $.data doesn’t work cross-browser on XML documents.

Therefore, avoid setting data on XML documents.

getElementById will always return null

If part of your performance plan involves setting id attributes to leverage the speed of getElementById, think again. getElementById does not work on XML documents.

As documented in Mozilla’s MDC:

DOM implementation must have information that says which attributes are of type ID. Attributes with the name “id” are not of type ID unless so defined in the document’s DTD. The id attribute is defined to be of ID type in the common cases of XHTML, XUL, and other. Implementations that do not know whether attributes are of type ID or not are expected to return null.

“ID” is a data type, and in an XML document, the browser has no clue that an attribute named “id” should be interpreted as such. The same applies for the class attribute and getElementsByClassName, but have no fear; getElementsByTagName (and querySelector/querySelectorAll in modern browsers) will continue to work as expected.

jQuery’s Sizzle (and probably all other selector engines) account for this, so $("#id") will continue to work as expected. Just don’t expect the same performance as getElementById.

The only benefit I see to passing raw XML to jQuery(), without parsing it into an XML DOM first, is the fact that getElementById will continue to work. I still wouldn’t recommend it though.

$.isXMLDoc()

This little utility method exists for testing whether or not a DOM node is within an XML document:

Useful when you want to be certain you’re correctly passing an XML DOM to jQuery.

No XML love in WebWorkers

Initially, part of my performance strategy in this project was to leverage WebWorkers to avoid locking up the main UI thread. After consulting the brilliance at Bocoup, Rick Waldron noted that XHR objects used within workers will only return responseText, and never responseXML. This is by design as responseXML is not considered thread safe. The DOMparser object is not available inside workers either, so unless you want to roll your own XML parser (hint: you don’t) do not try to request or parse XML.

References

Most of these links are scattered throughout this post, but if you want them all in one place:

jQuery ticket for “Error ‘script stack space quota is exhausted’” error
http://dev.jquery.com/ticket/6796
Mozilla ticket for “Error ‘script stack space quota is exhausted’”
https://bugzilla.mozilla.org/show_bug.cgi?id=579656
jQuery ticket for $.data fails on XML documents in IE
http://dev.jquery.com/ticket/6890
MDC DOMParser Object
https://developer.mozilla.org/en/DOMParser
MDC XMLSerializer Object
https://developer.mozilla.org/en/XMLSerializer
MDC getElementById
https://developer.mozilla.org/en/document.getElementById
jQuery’s constructor API documentation
http://api.jquery.com/jQuery/
$.isXMLDoc() API documentation
http://api.jquery.com/jQuery.isXMLDoc/
Add cross-browser XML support to jQuery – feature enhancement ticket
http://dev.jquery.com/ticket/6693

If you know of any other XML gotcha’s, please leave them in the comments below!

jQuery and Performance: What is ‘this’?

Eric Hynds — Mon, 04 Jan 2010 14:14:50 +0000

In my opinion, one of the best jQuery performance tips is to minimize your use of jQuery. That is, find a balance between using jQuery and plain ol’ JavaScript, and a good place to start is with ‘this‘. Many developers use $(this) exclusively as their hammer inside callbacks and forget about this, but the difference is distinct:

When inside a jQuery method’s anonymous callback function, this is a reference to the current DOM element. $(this) turns this into a jQuery object and exposes jQuery’s methods. A jQuery object is nothing more than a beefed-up array of DOM elements.

Digging a little deeper

As you begin to nest functions the context of this changes:

<a href="#"><span>Hello Worldspan>a>
 
$("a").click(function(event){
	var self = this;
 
	$(this).find("span").each(function(){
		console.log(self, this);
	});
 
	event.preventDefault();
});

In this example I save this to the variable “self” so it can be referenced inside the each() loop. Otherwise it’s impossible to reference this as the anchor element inside the loop, because this is now the “span” DOM element.

Depending on what you’re doing, using this is sometimes easier and always faster than $(this). I’m not talking about scraping jQuery altogether, but rather recognizing that a lot of DOM interaction (especially the simple stuff) can just as easily be done in vanilla JS using this; you are not required to use the jQuery API. Example:

<a href="test.htm">Testa>
 
$("a").click(function(){
	var href = this.href; // the href property can be accessed through 'this'
});

A more verbose example demonstrating the uses of this and $(this) to get an anchor’s href value. These statements are equivalent:

$("a").click(function(){
	var href;
	href = this.href; // sets "href" to "test.htm"
	href = $(this).attr("href"); // also sets "href" to "test.htm" after going through the jQuery attr() method.
 
	// because $(this) is really just a beefed-up array, we can pull off the DOM element using array notation.
	href = $(this)[0].href;
});

The point here is that turning this into a jQuery object and using the attr() method is more time consuming than just referencing the “href” property of this. When manipulation is involved the performance implications are even greater.

Benchmarks

To quantify my claims, I wrote a profiling function that calculates the execution time of looping a block of code 50,000 times:

var profile = function(label, code, iterations){
	var start, total, i = iterations = iterations || 50000;
 
	start = (new Date).getTime();
	while(i--){ code.call(); }
	total = (new Date).getTime()-start;
 
	console.log(label + ': %d ms (looping %l times)', total, iterations);
}

I then setup a page with one anchor element and a click event to call the profile function:

$("a").click(function(event){
 
	// save $(this) and 'this' - their reference change inside the profile function!
	var $this = $(this), self = this;
 
	console.log('Accessing the href attribute of a link:');
 
	profile('$this.attr("href")', function(){
		href = $this.attr("href");
	});
	profile('self.href', function(){
		href = self.href;
	});
	profile('self.getAttribute("href")', function(){
		href = self.getAttribute("href");
	});
	event.preventDefault();
});

Update 1/7/2010: JAlpino pointed out in the comments that the getAttribute(“href”) method can be called on this to gain an additional +/- 350ms, as opposed to using this.property syntax. I’ve added this method to the benchmarks & results. Thanks, JAlpino!

The results using jQuery 1.3.2 and 1.4a2 respectively on Firefox 3.5.6:

self.href provides a 270% improvement when using jQuery 1.3.2 and a 200% improvement when using 1.4a2. Using the getAttribute() method provides an additional 72% boost over self.href! Keep in mind that in ‘the jQuery way’ these numbers do not include the time it takes to convert this into a jQuery object; we’re caching that outside the profile function, and thus are only benchmarking the performance of the attr() method. How does this perform over $(this) when used for manipulation? I ran the profiler again, this time changing the link color to red:

profile('the jQuery way', function(){
	$this.css("color", "#ff0000");
});
profile('vanilla javascript', function(){
	self.style.color = "#ff0000";
});

We’re looking at a 632% improvement under jQuery 1.3.2 and a 206% improvement under 1.4a2. Pretty good for changing one line of code.

Putting `this` into `context`

You can pass an optional second argument called context to the jQuery object constructor, which gives jQuery a starting point when searching the DOM for your selector. The context can be either a DOM element or jQuery object, but ideally should be a DOM element – like this! Given the markup below and what we know about this and $(this), the “span” child of the anchor can be found four ways:

<a href="testing.htm"><span>test linkspan>a>
 
$("a").click(function(){
	// these statements accomplish the same thing
	$(this).find("span");
	$("span", this);
	$("span", $(this));
	$("span", $(this)[0]);
});

The first example turns this into a jQuery object and calls the find() method. The second example looks for a span element using this – a reference to the anchor DOM element – as the starting point. Because the context argument in the third example is a jQuery object, jQuery internally converts the statement to $(this).find(“span”), which is equivalent to the first example. We’re about to see that this is the slowest method, however, probably due to the overhead in converting the context to a find(). The fourth method is equivalent to $(“span”, this), except that this is first converted into a jQuery object, and then the DOM node is pulled off the array.

My original plan going into this blog post was to show you the performance benefits you can gain when using this as the context argument to the jQuery constructor as opposed to $(this), but my results show otherwise. Note that I ran these tests 20,000 times instead of 50,000 (Firefox got cranky):

$("a").click(function(event){
 
	// cache $(this) and 'this'
	var $this = $(this), self = this;
 
	profile(' $this.find() ', function(){
		$this.find("span");
	}, 20000);
 
	profile(' $("span", this) ', function(){
		$("span", self);
	}, 20000);
 
	profile(' $("span", $this) ', function(){
		$("span", $this);
	}, 20000);
 
	profile(' $("span", $this[0]) ', function(){
		$("span", $this[0]);
	}, 20000);
 
	event.preventDefault();
});

When using jQuery 1.3.2, $(this).find() was 4% faster than providing a DOM element as the context and 53% faster than using a jQuery object – pretty negligible. 1.4a2 shipped with some nice speed improvements; the performance of all four are about the same, but $(this).find() is still a bit faster.

To reiterate, I’m not saying skip jQuery and code everything in plain JS because it’ll make your site faster. The speed improvements I pointed out are trivial but can absolutely add up, especially in larger applications. There are a number of good reasons to use $(this) over this; cross-browser compatibility is one, the extreme ease of use another, but just be aware this exists.

Click here to see the code and run these benchmarks yourself.

JavaScript Loop Performance: Caching the ‘.length’ Property of an Array

JavaScript Loop Performance: Caching the ‘.length’ Property of an Array

Eric Hynds — Wed, 09 Dec 2009 21:52:48 +0000

I was reading this article from SitePoint earlier about how inefficient the JavaScript is behind Google’s new Closure library, and saw some interesting discussion about caching an array’s length property before entering a ‘for’ loop. This is what I’m talking about:

// uncached length property
for(var x=0; x < myArray.length; x++){}
 
// cached length property
for(var x=0, len=myArray.length; x < len; x++){}

I saw this tip and didn’t think twice about it; I’ve always been told that caching the length property is indeed faster. I then saw a couple comments saying otherwise:

Anyway, the loop performance is not as big deal as you present. Of course, it’s nicer and more professional to preassign the array length instead of testing it again in every step. But the performance is not such problem. The Javascript basic operations are very fast, making the difference quite unnoticeable. Those two loops performance will differ only in milliseconds for a million-iterations loop in today’s average computer. This means the same loop traversing an array containing a million items will take about 15 ms if the array.length is tested every time, and about 10 ms if the length is preassigned. So, we are talking about saving nanoseconds per a thousand-iterations loop. This makes no sense from the performance point of view.

And:

These are nearly Identical in performance. Even if the loop does nothing, so that the time spent in the loop is all spent incrementing i and checking its value, it is STILL hard to detect the performance difference. And if you do anything of substance in this loop, the time spent checking against someArray.length is dwarfed by the loop body. This is a stupid complaint.

I have always blindly assumed that the performance hit was due to the interpreter calculating the .length value each time it is referenced, but after talking to some javascript folk (#javascript irc.freenode.net), I discovered that .length is actually a stored value. Since JavaScript doesn’t need to re-calculate it on every iteration of the loop, where would the performance hit come from? Anyway, I thought it would be fun to run some benchmarks of my own to see the difference. Below is little script I put together, but please take it as a grain of salt because JavaScript time is not accurate.

var array = [], start, diff;
var results = { nocache:[], cached:[] }
 
// build array to loop over
for(var x=0; x < 1000000; x++){
	array[x] = x;
}
 
// run tests 25 times
for(var x=0; x < 25; x++){
 
	// length not cached
	start = new Date().getTime();
	for(var y=0; y < array.length; y++){}
	results.nocache[x] = new Date().getTime() - start;
 
	// length cached
	start = new Date().getTime();
	for(var y=0, len=array.length; y < len; y++){}
	results.cached[x] = new Date().getTime() - start;
}
 
// output results
document.write( 'No cache time: ' + avg(results.nocache) + ' Values: ' + results.nocache.join(',') + '' );
document.write( '
Cached time: ' + avg(results.cached) + ' Values: ' + results.cached.join(',') + '
' );
 
// logic from http://javascript.about.com/library/blaravg.htm
function avg(arr){
	var av = 0, cnt = 0, e, len = arr.length;
 
	for(var i = 0; i < len; i++){
		e = +arr[i];
		if(!e && arr[i] !== 0 && arr[i] !== '0') e--;
		if (arr[i] == e){ av += e; cnt++; }
	}
 
	return av/cnt;
}

The code first builds an array with 1,000,000 items, records the execution time of looping over the array 25 times using both methods, and then figures the average. Here are the results:

The results are what I expected except in the Windows versions of Firefox 3.5.2/3.5.5. In all other browsers I tested it is faster to cache the .length value, but in FF3.5 for Windows it is actually faster not to cache. Internet Explorer receives the most benefit with a ~30% increase in performance when caching, with Opera (Linx) and Chrome (Linux) in fourth and fifth place respectively. The amount of time is indeed negligible, but every millisecond counts, right?

If nothing else it is interesting to see how long it takes different browsers to loop through a large array. Firefox and Safari FTW!

jQuery and Performance: What is ‘this’?