ReadyState4

For the last year or so I’ve been predominantly focused on mobile web applications. While I’m a big fan of jQuery, at it’s current revision of *32.18 KB (compressed and gzipped) I think it’s generally too big for the mobile web. That’s when I discovered Zepto, a jQuery-like library that features 90% of the same functionality at a weight of 4.8 KB (compressed and gzipped). Life was good again and I resumed working with iOS and Android web apps, bidding IE adieu.

Fast forward to now and I need to make some general web pages again for a project and I need to support IE once more. These pages have some light-to-moderate js functionality and though I could write a small library from scratch, I’d be a fool in wasting so much time, though minimally, I only need:

• Cross-browser event support
• Cross-browser ajax support

Though one does arguably write faster and more concisely (smaller file size) if one has:

• A chainable API
• A CSS selector engine

The answer? Use an older version of jQuery. jQuery 1.2.6 for example is 17.18 KB (compressed and gzipped). Almost half as small as the current version. It gives me all four requirements above. Every version of jQuery has been battle-hardened against the most finicky older browsers and the newest batch of browsers aren’t really causing too much trouble. I had been writing with Zepto in Chrome initially when I made the switch to test in IE. I made the switch to 1.2.6 without issue. IE and all browsers are happy.

While I would love to take credit for thinking this through, it actually happened by accident. I referenced jQuery version 1.2.6 from Google’s CDN instead of 1.6.2.

I’m sure someone’s going to comment how I’m missing some major optimizations in later versions, but after trying the project out, I already have split second performance using an old build. If I start doing crazy animations or need .live, I’ll move up some revisions. If you do plan to try this out for yourself, know that jQuery 1.3 (20.08 KB) is when Sizzle was introduced and in jQuery 1.6 a lot of the API was modified or had signature changes (nothing that’s affected me so far).

Here’s a list of some versions along with their file sizes. Check the blog for more details.
1.6.2 (32.18 KB) – misc small bugfixes
1.5 (30.12 KB) – ajax timeout and abort
1.4.2 (24.86 KB) – .delegate
1.4 (27.25 KB) – extended .live support
1.3 (20.08 KB) – Sizzle and Live
1.2.6 (17.18) – 100% faster events
1.2 (17.21 KB)

And don’t forget if you’re using Google’s CDN (a good idea), always fallback to your own version, too, just in case.

*2.6.1, I use Charles Debugging Proxy for measurements.

I noticed both backbone.js and spine.js are using it:

http://jashkenas.github.com/docco/

Creates pages like this:

http://documentcloud.github.com/backbone/docs/todos.html

After setting up a make / jsmin build system for concatenating and minifying CSS files I looked around to see what’s the best compresser to do the same with JS these days and it looks like it’s a toss-up between Google Closure Compiler and UglifyJS.

I’ve heard from two different developers about problems caused by Google Closure compiler: one edge-case where it incorrectly rewrote some JS, and the other about having to write your JS a certain way for maximum efficiency. After reading up on UglifyJS here and seeing how both jQuery and Zepto are now using Uglify (jQuery moving from GCC to Uglify 3 months ago), I think I’ll give UglifyJS a try and let you know how it goes. The readme file that comes with Ugly is in both html and org formats. I’m liking it already…

I’ve been teaching JavaScript to a person with no programming experience and one with lots of programming experience in other languages. Both situations can be tough as one has to learn certain programing concepts (as well as how the web generally works) and the other must unlearn some that don’t apply here (like getting out of the strongly-typed world and appreciating the benefits of duck-typing).

Explaining various concepts in JS such as prototypes, closures, and even “literal” shorthand is interesting. I find the questions from both ends great—sometimes even challenging to explain which actually strengthens me as a JS developer. Still some concepts are hard to explain and the JavaScript Rhino book is too large and boring to dish out as homework. Then I stumbled across this page by Simon Willison which was written as a re-introduction to JavaScript but also makes a perfect condensed overview of what JS is for existing programmers: https://developer.mozilla.org/en/A_re-introduction_to_JavaScript. It even goes over a little history of the language and how to avoid nasty memory leaks in IE (circular references). Saves us a lot of time and explaining so that we can continue with more complex topics.

I was taking a look at my friend Takashi’s JavaScript tweener which isn’t released yet and noticed he setup his code in a particular way for a few methods that get called dozens of times a second. He explained to me that it was for optimization through memoization. I ran a test case, and indeed it’s much faster. Check it out:

a = {};
a.deep = {};
a.deep.variable = {
    here: 3
}
 
function plain(){
    document.body.appendChild(document.createTextNode(a.deep.variable.here));
}
 
function memoized(){
    var z = a.deep.variable.here;
    return function(){
        document.body.appendChild(document.createTextNode(z));
    }
}
 
 
now = new Date();
    for (var i = 0, max = 5000; i < max; i++){
        plain();
    }
alert(new Date() - now);
 
now = new Date();
    for (var i = 0, max = 5000; i < max; i++){
        memoized();
    }
alert(new Date() - now);
 
// plain:  759
// memoized: 36

There’s a more complex example on the subject posted a month ago on Ajaxian and an easier to understand one on Oliver Steele’s blog written back in 2006.