Perhaps the problem I have is with this statement:
> "Eval is evil", or in other words, Eval is too slow and quirky to be considered useful.
That's misleading. While performance of eval is perhaps getting better, eval is still evil for a number of reasons that aren't related to performance at all.
[1] http://echo.nextapp.com/site/node/6097
[2] http://stackoverflow.com/questions/5368048/how-are-closures-...
[3] http://groups.google.com/group/closure-compiler-discuss/brow...
One of the tests included in the slides was to see if simply using `eval` in a method would disable optimizations: http://jsperf.com/eval-kills
Chris (@robodynamo) included the slide about `eval` because he found it performant/useful in his day job.
Eval has it's uses, for example it's used in json2.js as part of the JSON fallback.
The content can't be seen without signing in and it would appear that I've forgotten the password for my fake-details account, so I can't look at the code specifically.
But I can say that it is not unexpected that the results one person gets can diverge significantly when someone else tries the same test. A lot of code rearrangements that are intended to speed up Javascript execution are optimised for a particular browser (or, if people are being more thorough, a particular subset of browsers). What is optimal for Firefox's engine is not necessarily so for Chrome's, and performance metrics can vary significantly between different versions of the same browser as changes are made to optimisations within the code interpreter/compiler over time. Heck, even exactly the same version of Firefox may behave differently performance-wise on Linux than Windows.
You can never say that a given "trick" is an optimisation generally because there are many variables. Unless of course what you are actually doing is optimising your logic rather than rearranging it (i.e. changing from something that is akin to a linear search to something that has a logarithmic growth pattern) but that isn't optimising Javascript, it is optimising the algorithm you've implemented using the language.
> Also, saying that eval is not evil is evil.
There are very specific circumstances when eval() can be used with relative safety [i.e. when the only injection method is by direct code manipulation, and all client-side Javascript is susceptible to that with or without eval()]. Other than that I agree, and none of the cases where eval() is safe that spring to mind can't be implemented some other way (at least in modern browsers).
For an example, they link to http://jsperf.com/undefined-void0-perf to show that using void 0 instead of undefined is not a performance win. The data shows there's no browser in which void 0 is slower than undefined and several browsers in which is it faster, by as much as 50-60%.
In my real world case a change in loop mattered a lot for ie6 users (60% of our use base at the time, sadly). It was .5sec that we couldn't get from other means.
I've never heard someone say "Oh yeah, the bottleneck in our app was our use of `==`".
The loops slides were more about modern engines not IE6 :P
I've had mandated IE6 support before, and still support it in my personal JS libs, so I feel your pain.
Eval, with-statements, arguments.callee, the Function constructor, and the like aren't "evil". They are just tools for you to use-wisely or abuse.