I decided to fix this for myself using a ridiculously short Greasemonkey script, using the window object’s “onbeforeunload” function to make sure I actually meant to close the tab/window.

Here it is for consumption. This is obviously not a work of genius or of any considerable effort, just a fix for my own absentmindedness.

Updated:
I added a little more functionality to the script. There is now a button that will show up in the top right corner that will let you turn off and on the close prompt so that you can browse the last.fm without getting the ‘Are you sure?’ prompt on every page load.

I’d eventually like to start contributing code, but I’d like to get used to the community first and see how things are done. With such an intentionally lead codebase, contributing actual code might be a challenge, so helping people out in the channel might be the best way to help.

Next up, I’d also like to help out with django by doing the same. With a more extensive codebase where size is not as big of as concern as it is in jQuery, getting a patch in or two would not be as difficult I would imagine.

The first thing I did was profile it using Firebug’s Net tab. Of all the tools in my web developer’s tool chest, Firebug is far-and-away my favorite, my oft-used, and my most recommended app. Not only does it give you a super nice DOM browser and a great Javascript debugger, but it also has a nice download profiler under its Net tab. It gives you every single element that the browser requests for your page with its HTTP headers and, even more importantly, the time to complete each transaction.

The profiling introduced a few things instantly. First, there were a lot of images and some were rather hefty. Since I was building the site from somebody else’s design files, and that is definitely not my domain, there was not much I could do about that.

The second thing was the Google Maps calls. I put the Google request calls at the end so the rest of the page could load before them. Doing just this took about a second and a half off a fresh homepage load. It was a marked improvement, but still nothing spectacular.

The final thing brings me to the topic of this post. Our standard JS library at work is Dojo. Dojo is great when you are trying to create a RIA interface with all the bells and whistles, such as tabs, number spinners, rich text editors, grids, and trees. Its widget library, dijit, is quite impressive. An early complaint of dojo was that it was a big download. If I remember correctly it was something like 100kb. The Dojo team fixed this 0.9 with a more modular dependency download structure. Say you needed to only use widget A. You’d make the Dojo call in your page for the widget and Dojo would then only download the bits of JS it needed to get that widget on the page. The problem with this is that if you are only using a small subset of the library, you had an exorbitant overhead, not in download weight, but in HTTP requests.

For example, I was only using Dojo to do some absolute positioning stuff for some help tip bubbles and a few simple Ajax calls. This was like going squirrel hunting with a Scud missile. Even with just using core Dojo (no widgets), I made about a dozen HTTP requests just to get the pieces of JS I needed. In total, it took a little over 2 seconds just to load the JS library, even though it only equated to about 60Kb of total file size.

These small tasks almost bordered on something that I could do myself, but since I can be a lazy programmer, I figured a small lightweight JS library that people much smarter than myself have written and tested would be the ticket. I noticed that jQuery was being mentioned more and more in a good way around the web, so I figured this would be the perfect trial to test it out. I can definitely say ‘mission accomplished’ with jQuery.

I used the non-gzipped packed version which had a weight of 47Kb. This took around 50ms to download and even better it all came in one HTTP request, with no just-in-time loading. The Ajax API between Dojo and jQuery was similar enough that it took very little modification to port it over and I even minimized some of my Javascript to use the awesome syntax of jQuery. By simply switching to jQuery, I shaved a little over 2 seconds from the page load time with no loss of functionality. Nice.

After all the profiling and modifying, I managed to cut the page load from a little over 8 seconds to a little over 4 seconds.

As a side benefit, it was actually fun to write Javascript. With jQuery’s well-document API and function list (something that Dojo definitely lacks last checking), I spent more time Getting Things Done than tinkering and experimenting. I was actually trying to do things to improve the visual effects of the site because jQuery made it simple to do so. It was almost completely painless.

This is not a slam on Dojo at all, because if you need some advanced UI features, I’d definitely go down the path towards Dojo. This was simply using the best tool for the job.

I am now looking for more excuses to use the tiny, tidy little jQuery library in other spots. jQuery brought joy to Javascript development, something I wouldn’t really have thought possible.