[illumen]

Well, it did have a whole IE support paragraph... so it is about IE8 somewhat. I have been looking at basecamp over the last few days too. So for me, this was the most relevant part of the article. Unfortunately some customers still use IE8 (and even 7), so it would be silly of me to force a tool on them they can't use.

Back onto the main topic...

In my experience IE8 is the most important one to profile and speed up - since it is quite slower than other modern browsers. Spending time in the IE developer tools profiling can give some pretty good gains.

Moving expensive code into click handlers can have the drawback of making the user Touch Points, or where the user is doing interactivity slower. This is where users can often notice the slow down. But I'm guessing you managed to make it take less time than 200ms, and it's probably a little touched item anyway, so probably still worth it. The alternative is to spread the computation after load, so the user might not even notice it happen. Or if you're modifying the DOM, why not just do it before you send it to the user - and send them html which doesn't need a lot of javascript manipulation done.

It also brings up the point of testing and profiling. I noticed there was a bug report in your blog comments. It's really helpful to have tests before you start doing profiling, and especially once you have made your changes. Tools like speed.pypy.org are really nice for tracking performance regressions too. So, when a developer adds some new JS functionality into your app in 4 weeks time, you can see when the performance regression was added.

cya