Recent:
Calling it Quits
After a long time, this weblog is coming to an end... I haven't been posting much here recently, and certainly no longer pieces. From now on I'll be posting those at Novemberborn. I've set up two feeds there, one for links and one for all text entries. Right now they redirect to delicious feeds, which creates the crazy circumstance that the Atom feeds you think you are loading are in fact RSS 1.0 feeds. That'll change once I get a proper app running on Novemberborn though. (No promises on that.)
So, go and subscribe to those feeds. There are some goodies in them already (namely this and this from the meeting of last Sunday).
See you on the other site!
Sunday, April 10, Utrecht
And there's another one coming up! Sunday, April 10th, in Utrecht. We'll be meeting at 1pm at Utrecht Central Station, after which we'll hopefully (it depends on the weather) go find a nice spot near the Dom. For more info and signing up see the wiki, spread the word, and be there!
Why Mozilla Memory Leakage is Not That Bad
Today Anne linked to an article on Mozilla.org: Using XPCOM in JavaScript without leaking. This article explains that, indeed, you can create memory leaks in Mozilla by using closures. However, the leaked memory will be collected after the document is closed (e.g. you load a different page):
(...) neither the element nor any of the properties nor any of the objects reachable from those properties can be freed until the document is no longer displayed.
Basically this means that you won't run into the memory leakage issues IE suffers from. You can optimize your code though to prevent memory leakage for JavaScript objects which are no longer being used. Personally I don't think this is much of a problem, unless you are developing a heavily used web applictaion which will stay open for hours.
This also means that Event Cache cannot be used to optimize memory usage in Mozilla, unless you create specific caches for specific pieces of the code.