Looking ahead a little bit: At the start of 2009, will JavaScript-based memory leaks still be relevant? Will onunload event handler cleanups still be required?
The largest offender has been Internet Explorer 6. Its market share is waning. Serious updates are being force-pushed to help old users. Internet Explorer 8 (beta?) will probably be out before the end of the year.
I’m fully willing to submit that they’ll be around for a long time, in one form or another – but just how long? One year? Two? Three? IE 5 is at < 2% and no major JavaScript library supports it. I suspect that we might have to wait until that level before people start to chop off IE6-with-JScript-5.6 support. Think about it: A year ago the world of Safari was pretty grim, but they gave us Safari 3 and it helped to clear things up significantly. Right now timers can be frustrating in Firefox 2, but Firefox 3 is giving some serious love to clean things up. It definitely appears as if the IE team is becoming serious about moving forward, so what can we expect here?
As I start working on my next book I have to ask questions like this. If I write about memory leaks will it even matter by the time the book is published? (Not saying that the book won’t happen until 2009, but that’s probably when it’ll be on most bookshelves.) Memory management will always be an issue, but memory leaks (as we know them) are surely doomed – it’s just the time frame that is unclear. Regardless, I think there should probably be a web-only article on memory leaks, I’m just not convinced that it should be in the book, proper.
Jonathan Snook (January 13, 2008 at 9:56 pm)
I’d like to see that day because I’m still not seeing it. I see Firefox leaking like crazy (people say it’s the add-ons). And there’s leaks in the WebKit within Adobe AIR — sure, there’s ways to work around it but in an environment like a desktop application that is more likely to be open for days, memory leaks are magnified. So, by 2009? It’d be nice but I’m not holding my breath.
Mark (January 13, 2008 at 10:07 pm)
I curse IE6 on a daily basis, so I can’t say I’m interested in seeing it stick around, but keep in mind that w3schools is a site for people like us: Developers using Firefox, Safari, or IE7 if forced to. I like to check these two sites for trends more typical of consumers:
http://www.w3counter.com/globalstats.php
http://www.thecounter.com/stats/2008/January/browser.php
Both of those track across embedded stats tools, and both, unfortunately, put IE6 in the 40s. Even the trend lines on w3schools seem to be slowly creeping through the 30s.
As for Firefox, I recall reading that Flock has far, far less memory issues, and doesn’t support extensions.
Eddie Welker (January 14, 2008 at 1:48 am)
Agree with Jonathan. Firefox leaks. So does IE, and I’ve heard about WebKit. If the people writing these (and other) apps are allowing leaks, it’s probably a good idea to discuss. I think you might be going on too short a time-frame.
I see your point, tho. Maybe a small section with a detailed online resource would do the trick. Describe how leaks are present in other languages, and how they are an aspect of programming in general. It’d probably go down easier if presented that way.
Thomas (January 14, 2008 at 3:20 am)
I believe leaks will not go away anytime soon, not until browser developers start to look into automated memory access checkers seriously. Write about the bad and the ugly, John, about how memory leaks can be detected systematically, why apps leak (or cause leaks), and the cures.
Alan Storm (January 14, 2008 at 5:43 am)
It seems likely that we’ll still be living with memory leaks in 2009. A few random observations
– I’m pessimistic about seeing IE8 betas by this summer. IE7 took around a year and a half from it’s announcement to final release date. If IE8 keeps the same schedule, that means a spring ’09 release.
– Will IE8 be Vista only? Will Vista have improved enough for corporate IT departments to feel comfortable leaving XP behind? These are big unknown right now which could significantly hamper IE8 adoption rates.
– How much will IE8 help the situation? There are certainly members of the team who are committed to tackling the problem, but whether they’ll have the time, resources and support to do so remains to be seen.
– Finally, even if leaks are taken care of, old code and patterns to deal with them are going to be around for a long time. Old code never dies, it just becomes the next programmers problem.
Tomasz Staniak (January 14, 2008 at 6:05 am)
I also think that we won’t see the end of memory leaks anytime soon and I agree that it should be covered. This kind of knowledge never hurts.
Andy Davies (January 14, 2008 at 6:26 am)
Firefox on Maemo (Nokia’s OS 2008) seems to leak like billy-o
Frank Thuerigen (January 14, 2008 at 9:09 am)
I tend to agree with John – as ES4 development seems to have stalled a bit for the time being, the pressure in implementing new features has decreased. On the other hand given todays scale of application code the main way of showing the customer that your browser is better than others is (1) increasing JS execution speed and (2) decreasing the mem leaks which will again result in better speed on a longer application usage timescale. I would not bet on it for IE since they probably have other goals to deal with first (visual-centric dev plan), but all other browser dev teams surely spend more time on these issues nowadays than they have done a year ago. Also it is a simple rule that the deeper an improvement is nested in the core of an application, the larger the benefit is. So I am really optimistic about memleak issues in the future too.
pd (January 14, 2008 at 9:16 am)
What the flip is that icon doing on your site!
I’ve felt unusual love towards IE since the ACID2 news however so far it’s just vaporware. Steady on with the fat MS logos John! You almost took my eye out with that thing.
Dusan Smolnikar (January 14, 2008 at 1:59 pm)
I don’t think memory leaks will ever be extinct. It’s a human error to leave a few in the code.
Justin (January 14, 2008 at 5:08 pm)
In response to the original question, I think topic might need some clarification. I assume you’re referring to JavaScript-specific memory leaks (resulting from rooted circular references). So, are you asking if circular leaks should be covered in light of Firefox 3’s cycle checker and similar functionality in IE 7? If so, then I’d suggest covering the concept and typical problem cases. After all, older software versions tend to live a lot longer than anyone expects.