[link|http://jgwebber.blogspot.com/2005/01/dhtml-leaks-like-sieve.html|http://jgwebber.blog...s-like-sieve.html]

The problem is not JavaScript. Nor is it really the DOM. It is the interface between the two. JavaScript uses (sometime after Netscape 2.0, I think) a fully garbage-collected memory allocator. For anyone who doesn't understand this, this simply means that memory can never be truly leaked, even when objects reference each other circularly (e.g. A->B->A). Both Internet Explorer and Mozilla are built on roughly similar component models for their native object layer (i.e. the DOM). Internet Explorer uses the native windows COM model, while Mozilla uses a very similar XPCOM model. One of the things these two models have in common is that objects allocated within them are not garbage collected &emdash; they are reference counted. Again, for those unfamiliar with the vagaries of memory management systems, this means that objects might not get freed if they take part in a circular reference (as above).

Now the designers of these browsers have gone to some trouble to keep their COM layers (I'll refer to both as COM for simplicity) from leaking during normal usage. If you're careful, this is not too difficult &emdash; you simply have to be vigilant about potential circular references and use various hacks to refactor them out of existence. And of course their JavaScript garbage collectors can't really leak at all. Where things start to go sour is when you have circular references that involve both JavaScript objects and COM objects. Let me use an example to illustrate this point. Let's say you have a JavaScript object 'jsComponent' with a reference to an underlying DIV. And the DIV contains a reference to the jsComponent object. It might look something like this:

var someDiv = document.getElementById('someDiv');
jsComponent.myDomObject = someDiv;
someDiv.myComponent = jsComponent;

What's wrong with this? What basically appears to happen is that jsComponent holds a reference to someDiv. In a reference-counted memory manager, this means that it has a reference count of at least 1, and thus cannot be freed. Now someDiv also holds a reference to jsComponent (because jsComponent cannot be freed if it is still accessible via someDiv, or things could go really bad). Because COM objects cannot truly participate in garbage collection, they must create a 'global' reference to myComponent (I'm not sure what the actual implementation looks like under the hood, because I haven't dug through the source for either browser, but I imagine it's similar to the semantics of Java's createGlobalRef() JNI call). Thus begins the deadly embrace: someDiv's reference count will stay at 1 as long as jsComponent is not freed, but jsComponent will not be freed until someDiv drops its global reference to it. Game over: that memory is irretrievable without human intervention.
-----
So much for the AJAX revolution. Actually, its still gaining ground, but we are just starting to understand all of the impacts. This little lovely will have us reworking code for about a week and changing our practices.