Archives for category: microsoft

In my first Ajax and REST article, I talked about how the Ajax web programming style and the REST architectural style work well together. While this is true in theory, there are quite a few technical limitations of browsers’ XmlHttpRequest implementations that make it challenging to take advantage of some very basic HTTP capabilities. Case in point, observe this little gem from the MSDN page on the XHR#open method:

Microsoft Internet Explorer caches the results of HTTP GET requests in the Temporary Internet Files (TIF) folder. In most cases, caching improves performance for data that will not change frequently. To guarantee that the results are not cached, use POST.

As Dr. Evil would say, “Riiiiiiiiiight”.

I expect (hope?) that one of these years all of the popular browsers will expose Javascript APIs that provide HTTP client functionality on par with the Apache HTTP Client, but we’ve got a ways to go.

In the meantime, I found this extremely useful and interesting page by Mark Nottingham that tests the correctness of your browsers’ XHR caching. Try it with a couple of different browsers and observe the differences.

This video must be seen to be believed.

From the poster’s description:

Microsoft sent this tape to retailers to explain the benefits of Windows 386. Boring until the 7 minute mark when the production is taken over by crack-smoking monkeys.

Via Josh.

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.

Browsers that have garbage collection bugs (IE6) and continue to retain those bugs in new versions (IE7) cause memory leaks.

Closures are an extremely powerful and useful programming technique. It’s unfortunate that you would recommend against their use simply because your browser has a bug that causes a memory leak.

A huge amount of time has been spent by the js community to detect, resolve, and work around these IE memory leaks. It’s too bad this was required, and will continue to be required as long as MS refuses to fix the problem.

Hopefully IE’s market share will continue to drop and we can begin to ignore these memory leaks because every other browser out there handles closures just fine.


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.