Biggest AJAX problem
Or, how I found myself in front of a 700 MB memory footprint Firefox.
AJAX is becoming the new “de facto” standard in the web application industry. Every where you look on the web there are changes and on almost all sites to approach the AJAX world. Gmail and Yahoo Mail are some of the biggest web applications implementing AJAX and the results on both are amazing.
Browser world
If you ask a JavaScript developer about what is the biggest problem of JavaScript programming it will probably tell you it’s browsers’ incompatibilities. This is a very big issue and as long as the major players will not come to an understanding (and unfortunately they won’t) and provide a common ground it will remain a big issue.
I will not mention here other problems from the CSS world for example.
Fortunately along with AJAX came a lot of frameworks and libraries that address this problem and hide the ugly details from the programmer.
The PROBLEM
In my opinion there is a worse problem then hacking your way around bugs and differences. That problem is represented by memory leaks.
JavaScript VM comes with a garbage collector and aside from some edge cases you might encounter, it does a pretty good job. Once you close a page a lot of work is done behind the scene to clear unreferenced objects. A lean, mean cleaning machine.
Well… AJAX can mess this up. The page is not closed any more.
The problem is not AJAX in itself as a programming paradigm but in what it can do for the application. With AJAX you can retrieve data from the server without closing the page and rebuilding it. And that data is placed inside the same page and manipulated by JavaScript programs. New DOM objects are created over and over, new JavaScript objects are created based on those data, new events are attached to all this objects. Few programmers destroy those object and unattache the events.
AJAX is still young and most of the people that have done some AJAX implementation for their site are just pulling some HTML parts from the server and using innerHTML to replace the content of a div element. No harm done. As the applications are becoming more and more complex the use case changes. XML or JSON is pulled from the server and DOM objects are created based on them. It is very easy to forget something.
Unfortunately most JavaScript programmers are sloppy. They were taught to be that way by the old browsing habits. There was no need to clean after you. When the page needed some more information, it was regenerated on the server and rendered again by the browser. A clean sheet to work on. Everything that was persistent were the cookies on the browser.
Taking care of your things in JavaScript is harder than you think. Very good programmers missed this. I was using an AJAX application from a well known company (not here to throw the stone) and after heavy usage for about two days without closing my browser, it reached the respected 700 MB footprint in my laptop’s memory.
Remus,
Nice post… Any advice for fellow JS developers on how to properly manage their memory in Ajax-based applications? Examples would be great!
Great post and one to watch but it still worth it for all the benefits gained. I’ve built (2) enterprise consoles using 100% JS rendered DHTML and haven’t seen this problem manifested to the extent the value of zero footprint outweighed the hassles.
More references…
http://javascript.weblogsinc.com/2005/03/07/javascript-memory-leaks/
Thanks,
Tim
Your post is so good for me , an ajax newcomer.
I need to deeply study this technology.
Thanks a lot.
@Frank: there are no examples, only good practices.
@Tim: The problem manifests itself more aggressively on the AJAX world as the browser does not clean the page any more. The article pointed by you is about leaks due to browsers bad design. I’m am talking here about leaks caused by the bad design of our AJAX applications.
Use case: the page requests an XML from the server. After the response is received the JS from the page creates a partial DOM tree (let’s say an ul) from it and a JS object as a manager. The manager has a reference to the partial DOM tree root [ul]. This [ul] is attached as a child to a div element into the page. The manager is attached as a listener to a button [Sort] on the page that will trigger a sort action on the [ul]’s children, let’s say. Clicking on another button [Load] on the page will trigger this course of events again with different data.
This use case will trigger rapid memory consumption by the browser. To prevent this the manager must be detached as a listener of the [Sort] button before a new piece is loaded. Otherwise we will end up creating more and more DOM objects and the GC will not destroy them as we are not “marking” them as unused, they still have references to them from the application.