Hacker News Reader

Comment by jongdubois | Hacker News Reader

I think there's no point trying to avoid memory leaks in older versions of IE. Circular references due to closures are too common and it's not worth messing with your code.

IE users are probably used to getting a horrible user experience anyway. I'm sure they can cope with a few browser freezes/crashes every once in a while - They know how to take a beating :p

View on HN

The reason this is mentioned (and things like the part about caching array length in your for loop) is that this tutorial was mostly written back in 2006, when things were obviously a bit different with JavaScript.

The article has gotten updates since then (check the history), but not many and not to the extent it probably needs. Not sure why it keeps getting linked.

Since you seem to have an understanding of what is wrong with it, care to tell about everything you know that should be updated?

I would find that helpful. Since the article is a wiki, I would be willing to edit in any suggestions that magicalist makes, if magicalist doesn’t want to bother doing the editing him or herself.

There's definitely no point to avoid them for IE. The point as I see it is that it should be avoided for every browser.

Indeed IE's users are having terrible experience anyway, but let's just don't push FF and Chrome to their memory limits, just because we don't care with our code.

One of the best parts when I develop client-side web-apps is the debugging and looking close what the garbage collector is doing. For example : I usually don't use `delete` keyword, since I know it might create a node that GC's can't clear.

Can you expand on what you said about the `delete` keyword implications with the GC? I've never heard of that issue.

I haven't either, only that delete will cause code to be de-optimized.

I think it affected earlier versions of IE - Douglas Crockford detailed an issue here:

http://javascript.crockford.com/memory/leak.html

What the hell is wrong with people today? I was hazarding a guess what was being referred to and I get down voted?

Its main purpose is deleting a property from an object, which is a pretty slow operation on modern JS engines. Unless some code tests for the existence of a property, setting it to null is a better idea.

I'd suggest undefined over null if you want to effectively remove a property, since JSON.stringify won't serialize those properties... in an array, it will become null.

Though, I don't use delete much, I honestly don't worry about it much. In most contexts it's a bit of a premature optimization unless you are in a very low-level tool that will be used for example gaming, video or photo manipulation, there are probably better optimizations to make.

It was very important for IE <=6. Early AJAX web apps like GMail ~2004 were quite hard to get right - avoid most memory JS leaks or the memory consumption got out of hand too fast. That was in the days of 512 MB memory and WinXP.

I worked on an extjs app for a company where most of the users at the time where IE6 corporate wide (this was several months after IE8 was available. That said, there were such horrible memory leaks with references just in the nature of the application under IE (component<->JS ties wouldn't unwind/gc) it would quickly eat up memory after about half a day of work would need to restart the browser...

In the end a lot of people using the application would either have to restart during the day, use portable Firefox, which many actually did. Of course, there are/where many worse things in practice dealing with supporting IE<9 for relatively modern web applications. I'd still rather deal with that, than the v4 browser days.

I was stunned when I read the part about hooking the "this page is done now, let's go to another" event to manually clean up memory. (Old) IE worse than failure, indeed.

Reply on news.ycombinator.com