erichynds

Welcome to my online development portfolio and blog. I'm Eric Hynds, a 23 year old website developer living outside of Boston, Massachusetts, and I'm passionate about developing functional, standard-compliant, and user-friendly websites.

Archive for the ‘JavaScript’ Category

Working With XML, jQuery, and JavaScript

Sunday, August 29th, 2010

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 $(“<html string>”) 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.

On the same note, 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).

script stack space quota is exhausted

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. (more…)

jQuery and Performance: What is ‘this’?

Monday, January 4th, 2010

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 World</span></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:

(more…)

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

Wednesday, December 9th, 2009

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:

(more…)