Peter Gurevich, Performance Product Manager for the Microsoft Internet Explorer web browser, just wrote the third part of a blog series on improving the performance of Javascript execution within IE. Peter’s trying hard to help developers, but he’s got a thankless job since many of the problems are the result of not so much developer coding errors as IE design and implementation problems. The situation is compounded by the bitterness many developers feel towards Microsoft for taking a long vacation from major IE enhancements after winning the browser wars though a combination of rapid innovation and monopolistic business practices.
So when I hear Peter say things like:
Closures (functions that refer to free variables in their lexical context) are both extremely powerful and extremely dangerous. There are certain programming techniques that demand their use and once you learn how to use them they can quickly become one of the most overused features of the JScript language. Currently the misuse of closures in connection with the IE DOM and various COM components are the number one cause of heightened memory usage within IE.
While this is all true, it’s frustrating to read since he advises to avoid idioms that are not necessarily incorrect or misguided from a language perspective, but rather they’re problematic in the context of IE’s rusty engine. It’s like calling to report a busted-up highway and being sent a map of the backroads.
So while these posts on care and feeding of IE provide useful information, I’d also like to see frequent transparent communication on what Microsoft are doing to address the most fundamental problems that their browser presents to web developers.
What is Microsoft doing to address IE’s problems? Though they say they’re working on it, they haven’t published any concrete goals or plans for IE vNext. More transparency is welcome. What should they do? Rewrite or replace the layout engine. And the Javascript implementation.
Once again I must stress that I applaud Peter for writing these articles, but Microsoft also needs to communicate (in detail) about how they’re addressing root causes.
[…] Related to yesterday’s post, I just caught up on the comments to Peter Gurevich’s (MS IE Performance PM) guidance to avoid using closures in IE. Matt Kruse had a perfect, concise response which I feel compelled to quote here verbatim: Closures don’t cause memory leaks. […]