Totally dropping custom scripting and using jQuery

Comments
Bookmark and Share

jQuery, the Javascript framework, is like the ecstasy of web development: everybody’s doin’ it these days. (Well actually ecstasy was big in the 80’s, but a few months is like 25 in internet years. Just go with it.) When no two browsers seem to implement Javascript the same way, a framework is practically a necessity. But for a long time I held out and insisted on writing my own Javascript.

Why? Well, for starters, most of this site didn’t even use much Javascript, and the parts that did were only really important to one person: me. I used Konqueror as my main web browser, and its admittedly crappy JS support didn’t handle frameworks like jQuery correctly, so if I wanted the pages to work for myself, I had to write my own scripts. Besides, I wanted to support W3C standards. A simple way to do that is just to write code that conforms to the standard — at least, as well as anyone can tell what it means — so if you came to my site with a non-standard-compliant browser (*cough* IE *cough*) and it didn’t work, tough. Maybe it’d convince someone to use a better browser.

But over the past year and a half or so, all of those reasons have pretty much evaporated. I rewrote TextWriter with a new AJAX interface, and within several days, I already had someone pointing out a pretty significant (though not quite critical) bug when using it in Internet Explorer. Also, with the advent of KHTML 4, Konqueror’s support of Javascript frameworks improved by leaps and bounds. Stack Overflow is actually usable in Konqueror now.

And then there’s the standards issue. Although Microsoft still is a bit hardheaded when it comes to web standards, they do seem to have realized that they can’t completely ignore what the rest of the internet is doing. So I think we can expect better standards compliance from IE in the future.

There was one more thing that bothered me about the possibility of switching to jQuery. The core jQuery script alone is 24 KB, minified and compressed. A lot of people seem to think that’s nothing, but I’ve always been a fan of clean HTML, and so my pages are pretty small, file-size-wise. The jQuery script, and remember this is with every unnecessary character stripped out, is literally almost 4 times as large as the HTML page for TextWriter (7 KB for the latter). It seems silly to add a 24 KB script to a 7 KB page.

However, after some thought I don’t think that’s such a big deal, mainly because of browser caching. One advantage of jQuery’s popularity is that it’s everywhere. It lives all over the internet, and it’s available from several major content delivery networks. Probably 99% of anyone who uses a Javascript-capable browser has the script cached, and by using one of those CDNs instead of hosting the script myself, I can make use of those cached copies. So using jQuery won’t actually add much of any additional download time to the page.

What about the effect on page processing time? Sure, it takes a while to parse and execute all those 24 KB of code. I guess that could still be an issue, but I doubt that jQuery would have gotten so popular if it significantly slowed down page processing for a lot of people. This is one effect to keep an eye on, and I may revert to my custom scripts if it becomes serious.

The bottom line? Once I started trying to fix the aforementioned bug, I realized the one eternal truth of web page scripting: writing functional scripts for Internet Explorer will, in fact, drive you insane. Better let someone else worry about that.