But if you have figured Ajax out, good for you. On my end, I was able to do a little bit of Ajax project from time to time but I still have troubles figuring things out. It’s still a matter of trial and error for me.

In my journey in figuring out Ajax, I came into contact with one of the peculiar situation that will only happen to Ajax. If you have been to the world of programming language, you may already have encountered innerHTML. This little tool is often used by programmers to easy write objects in a DIV. Although the longer way of using DOM is also good, programmers naturally select the easier way… including me.

But things got awry when I tried to use innerHTML while I was building an Ajax based software. You may already have heard how Ajax can be as complicated as it combines different programming languages into one complicated program. The end result will always be a beauty but it will take your time and effort just to make one simple program. By all means, I have to look for way to make my Ajax coding a little bit easier. Instead of using DOM for myDiv, I decided to use innerHTML. Although Ajax still took time to be finished, using innerHTML helped me get through the challenges in creating this complicated program.

Thinking that I already have a pretty good Ajax software I decided to make it run. But as soon as it started, I figured out something is definitely wrong with my program. The information I entered doesn’t seemed to be processing as planned. Worst memory leaks seemed to be plaguing the program, causing me to re-evaluate the entire program right from the scratch. Soon enough, I traced the problem in innerHTML. Apparently innerHTML cannot process the XML documents that well causing it to bypass, or even withheld some information. Although memory leaks doesn’t happen in Mozilla, more than 80% of the worldwide users are into IE and this is where the problem usually starts. The only resort for this Ajax based program to work is to change the innerHTML into DOM. I know it’s going to be really complicated but considering the consequences, you should stick to the longer but safer road of DOM. Ajax is not only for rocket scientists but also patient rocket scientists.

So if you want a stronger Ajax-based software that could practically be stable in IE; ignore innerHTML as much as you can and use DOM. Although it will take some time, you may never have to review your program again.

I currently process incoming XML using an XSL document – which works very well. However when done under IE6 the XSL transformation is output as plain text [please let me know if there is a DOM alternative] which means the only way to insert my newly transformed code is to use innerHTML. This seems to leak memory like a biatch! Note that the leak doesn’t occur in FireFox.

So why does innerHTML leak? Well after some digging I found out a few interesting facts – lets look at the who, where, why and how…

Where did innerHTML come from?
innerHTML is not a standard, it is a proprietary format by Microsoft. Given Microsoft’s huge installed base and popularity other browsers included innerHTML for the sake of compatibility. It was never in the w3c specification. It subsequently isn’t future proof and isn’t designed for xhtml [xml mime type].

Why is innerHTML used?
innerHTML is used as a cheap and easy way to write objects to a container element like a span or DIV. It tends to be faster than traditional DOM methods and takes substantially less time to write. For example you can quickly write a table structure into a DIV container using innerHTML like so:

var myDiv = document.getElementById('myDivId');
myDiv.innerHTML = "


Title


Mr



";

The equivalent code using DOM methods would take up considerably more time and lines of code to accomplish. So for lazy coders or new guys innerHTML provides a great way into the world of JavaScript. To be fair to innerHTML, it works very well for the most part, yes its ugly, its not “right” but if your in a rush and don’t have the requirements my client has then it can work very well. You should try, where possible, to avoid it though as it can have unpredictable results and its a bad habit to rely on innerHTML to change or update your web page. DOM methods, in the long run, will serve you better.

So why / how does innerHTML leak memory?
The specific answer to this I do not know but we can theorize a solution. Firstly, as previously discussed, innerHTML is not designed to work with xhtml documents, meaning that it can incorrectly interpret the string you pass to it. This means it doesn’t actually render exactly what you ask it to – basically it adds things you never asked for. If you parse the html later on using DOM methods you may run into errors or bugs where the DOM hierarchy isn’t as you expected.

Is there a solution?
Yes! Simply don’t use innerHTML. I don’t think you’ll ever find an article, and there are quite a few, that puts in in good light [aside from its obvious benefits]. However if you are in my position and are forced to use it then, apparently, there are a few things you can try doing.

Firstly as the memory leak may be coming from its incompatibility with xhtml it is well worth re-writing your code to accommodate this, or by re-structuring your xhtml in a different way. Unfortunately it’s quite hard to know exactly what innerHTML is doing so its a bit of guess work.

If you wish to use DOM methods to replace your existing innerHTML code then please look at this very good article on innerHTML alternatives.

Cool effects:

1. Accordion effect
2. Auto-scrolling page navigation
3. Carousel (able to use with Rails)
4. Crossfader
5. Data Picker
6. FrogJS Javascript Gallery
7. Goofy Boxes
8. Image Transition Manager
9. Lightbox
10. Lightwindow: Lightbox prototype.js version
11. Modalbox: like Mac OS
12. Password strength meter
13. Prototype window
14. Scal: calendar component
15. Slideshow
16. Slideshow 2
17. Scroll with slide component
18. Scroll 2
19. Shopping cart
20. Tooltips
21. Validation

If you want to do cross-domain scripting with XMLHttpRequest, e.g. fetching data from a remote location but you’re on a local page or local XUL application (file:///), you need to tell Mozilla/Firefox about that, otherwise you get the infamous error:

Error: uncaught exception: Permission denied to call method XMLHttpRequest.open

Below is an example that can be run locally (save it to your harddisk and open the page with Mozilla/Firefox). It will fetch some RSS XML data from wunderground.com and alert it.

Always remember: XMLHttpRequest needs UniversalBrowserRead!

If the page with the XMLHttpRequest is on a http:// URI (on a webserver), it is not possible to fetch data from another domain!!! This is a security measure of Mozilla/Firefox.

Still, it comes in handy, if you can read remote data from a local application. E.g. you’ve got a local XUL application that needs to get data from other servers – Dude! Sweet!

If you’re doing some extension to the Mozilla/Firefox browser, you don’t need to care about permissions. Such an extension is installed into the core of the browser anyway, hence it has all privileges.

cross-domain-xmlhttprequest.html

  onclick="javascript:updateweather();"/>