ECMAScript - power and dangers of Closures and memmory leaks

A month has passed and our SOAP replacement has stabilised and is as robust as the webservices.htc solution we were initially using.

While researching (googling) some of the issues we have encountered with our product teams using the AJAX Framework we have discovered some issues with regards to the way ActiveX (Native Object) are used in ECMAScript and great care needs to be taken to prevent the creation of closures with these ActiveX objects.

Internet explorer does not carry out effective garbage collection of ECMAScript objects, specifically those with closures on Native Objects.

To prevent memory leaks, it is especially important to prevent accidental closures

Drip from a leak (Internet Explorer and AJAX pitfalls)

Sitting here working with an extremely complex and what, at times, seems an over engineered DHTML, JavaScript, XML/XSL, XSL:FO and HTML (AJAX) project with all the "Patterns" of a J2EE/J2SE project that we have introduced a plethora of Memory leaks in Internet Explorer.

This tracking down of memory leaks resulted in the classic Google search to see if anyone has already used the same development pattern as our project and encountered any specific memory leaks where we may suspect there are none.

To help me get started in tracking down our memory leaks I found the MFC application, dicussed on the AJAXIAN website, called Drip (Home Page) which helps you find your Internet Explorer memory leaks.

Blame the Tools and not the workman

The Internet Explorer "MSXML.XMLHTTP" (XmlHttpRequest Object) AJAX solution is fine if you are really careful not to create closures on any active controls in the process.

The following will already cause a memory leak...
request.onreadystatechange = function(request){
}

imagine what this will do...
request.onreadystatechange = function(request, dom, handler){
if(request.readystate == 4 && request.status == 200){
dom.loadXML(request.responseText);
handler.domLoaded();
}
}

How many people sit there and berate Microsoft products such as Internet explorer. One of the most common complaints is that IE is not as robust as FireFox or Mozilla.

If you look at what the developer is attempting to do when they have made the comment, you normally find they are trying to implement a "non standard" almost untested solution.

I have joined projects where the "propeller heads" have written some Visual Basic for Applications (VBA) inside a word document which parses the document for HTTP links and while attempting to use Microsoft Word as an Internet Browser complain that Microsoft Word is full of defects.

It does however seem that Mozilla products don't use ActiveX controls as part of their solution and they attempt to develop the solution to be an Object within the browser and not an external resource thus preventing and Operating System dependency for a developers solution.

Back in 1999 my project team were already using what is called an XML Island where we would script a Java Applet which communicated with an ASP page using GETs or POSTS.

The response was parsed on the server and the returned as JavaScript. The JavaScript was retrieved from the applet and eval'ed using the JavaScript. Ok this solution did require JAVA to be enabled in the browser and the version 4 browsers with JavaScript 1.2 were still new and all the calls to the server were synchronous but the JSON solution had no Memory leaks and there was no relying on a web browser's Garbage Collection of JavaScript objects. There were no Closures around expensive ActiveX controls such as XMLHttpRequest Objects and XmlDocument objects.