The title should be "Writing JavaScript code that turns out to be fast and memory-efficient in the 2012 editions of JS engines".
When discussing the efficiency of a language, especially an interpreted language, one must always take into account the peculiarities of the used VM. And be sure that today's optimisations may be "pessimizations" in the future (see the many Linux optimisations that are being removed in the last years).
I would kind of like to read an article specifically about tuning performance in various IEs. (It would be, unfortunately, a very practical and useful article for me.)
A while back I wanted to put a JSON information string and a fairly sizable 3D model in the same request response, and then pull the JSON off without nailing the browser if the model was big. I keep meaning to test how well it works in different browsers as well.
Although it is possible that virtual machines change more rapidly than physical machines, isn't this also true for languages more directly targeting a physical machine, e.g. C?
I suppose what you're really getting at is that in JS we are subject to the whims of BOTH the compiler and the VM on the target browser?
I can personally attest from first hand experience that "code rot" due to not taking advantage of the peculiarities of the current JS VM (and yesterday's "techniques" no longer being suitable) are far more commonplace than in any other programming environment I've dealt with.
Also of note -- with C you make your product, compile it, ship it and largely forget about it. Its rare that PC games get slower, even if compilers change, because you don't keep recompiling it. However, if you make a JS game, that thing is interpreted from scratch every time its loaded. So if I make a JS game and ship it, the performance characteristics have a higher chance of changing in unexpected ways on me long after I've moved on.
(Note: This is simply a response to this particular aspect of performance tuning JS, I am obviously not getting into the benefits of interpretation which may very well outweigh these costs.)
When discussing the efficiency of a language, especially an interpreted language, one must always take into account the peculiarities of the used VM. And be sure that today's optimisations may be "pessimizations" in the future (see the many Linux optimisations that are being removed in the last years).