3 Easy Steps to Avoid JavaScript Memory Leaks

Introduction

Jack Slocum's blog used to carry an interresting post about memory leaking occuring in regular webpages. Sadly it has gone MIA.

(please note, full copyright and credits for below text belongs to Jack Slocum. Text is almost 99% verbatim from the webarchive. And even though written in first person, it was not done by me)

So, resurrected from the Web Archive I give you...

3 Easy Steps to Avoid JavaScript Memory Leaks

October 2, 2006 by Jack Slocum

You may not know it, but almost every site you visit that uses JavaScript is leaking memory. That may sound like an exaggeration, but it's true. Don't believe me? Leak Monitor

With this handy extension for FireFox, any time you leave a page and it leaves code pointing to JavaScript objects - it displays a popup with details about the leak. It even gives you details about the function or object that created the leak.

Leaving http://script.aculo.us/
This is probably the most common leak I see - prototype.js, line 74:

The Dojo Mail example page
This one takes it to the extreme, filling two popups (look at the scrollbars!).

Word Press
This one is the most irritating. Every time I edit a post in WordPress, this is what I see.

Visiting all your usual sites, you will find almost every one of them is leaking memory. It's actually quite shocking that some of these sites wouldn't have some sort of testing in place to make sure this isn't happening.

-Even with all the JavaScript, example code and what not on this site, you will not have any leak alerts. I don't do anything special to avoid leaks. -

It's as simple as these 3 steps:

1. Never put anything in a DOM expando or property other than a primitive value unless you plan on cleaning it up.

This is the most important rule of all. It may seem convenient to put your JS object in a DOM expando, so you can $() and get it, but don't do it. Sure, I know what you are thinking, I am being a little paranoid. There are lots of instances where putting a JS Object in a DOM expando won't cause a leak. That's true, but there are also many that will... some which are not so easy to detect (i.e. closures). So to avoid the possibility all together, I follow this simple rule.

2. Clean up all your DOM event handlers on unload if there's a chance they could reference a DOM object.

There's no reason to manually do this when there are libraries that do it automatically. I use YAHOO.util.Event for all my event handlers, it handles this for me automagically. Other libraries (prototype, dojo, etc) have some sort of mechanism to do the same thing, although I'm not sure how effective they are. If you look at the leak images above once again, you will notice almost all of them are in event related code of those libraries.

3. Set your XMLHttpRequest onreadystatechange handlers to null when you are done with them.

I use YAHOO.util.Connect for all my XHR connections and it uses a polling mechanism instead of readstate, so I don't need to do this anymore. If you can switch to YAHOO.util.Connect (or YAHOO.ext.UpdateManager built on top of it), I'd recommend it.

Summary

Avoiding memory leaks is not that difficult. It doesn't take any special coding skills or expertise. By following the easy steps above, even a novice can write JavaScript code that is leak free. For all the big sites out there (including the new Yahoo Mail!?!?) please take the time, and fix your site so maybe I (and others) can browse the web without a memory leak on every page.