As I explained to a colleague the other day, Missouri is the "show me" state. And when it comes to javascript timings, it is really easy to show me.
Performance arguments are the bane of javascript programmers. I mean, javascript is slow, in absolute terms. I get that. I'm okay with it. For more than 40 years, programmers have been making rational choices to trade runtime speed for development speed.
But languages that optimize for development speed have to fight an ongoing rear-guard action against runtime speed. I have great hopes that improved javascript VMs are going to make this all beside the point. But we have a few more years yet to fight.
For now, we are stuck with tedious suggestions about tiny optimizations. For example, should you pre-determine the length of an array in a for loop? IOW, which is better, this:
for (var i=0; i<foo.length; i++) {
or:
for (var i=0, l=foo.length; i<l; i++) {
???
This actually came up at the day job. I wrote a test that shows that after 10,000 iterations, the second example was 16 milliseconds faster than the first. After 100,000 iterations, the second example is 200 milliseconds faster than the first. For more typical iterations of a a few hundred, the difference is about 2 milliseconds.
This presents you with an opportunity to "lie with statistics". Example one is idiomatic. But example two is "X" percent faster. Except the actual difference is actually measured in milliseconds, and no human user is likely to notice the difference, at least for typical data sets.
Idioms are, I guess, kinda flexible. So your company could establish an idiom in which you always fix the length, as in example two. Then you win both ways. Yay for you.
The thing is, I never hear my java programmer colleagues arguing about the best way to declare a "for" loop. Possibly because the java VM is so fast, it doesn't matter anymore. Or maybe the java VM (or compiler) has turned this into a "solved problem". Either way, I pine for the day that we can stop discussing this for javascript. But, more to the point, I think think the day is upon us.
The for loop optimization is just one of many that the au-courant javascript programmer is asked to make. I die a little every time these ideas are introduced. First, because new VMs will make these optimizations beside the point. And second, because the optimization usually flies in the face of a an idiom. Idioms are the glue that binds developers together, and allows us to read each others code.
I'm lucky enough to own a copy of "Literate Programming", a collection of essays by Donald Knuth. I contend that using idioms in your code is a form of literate programing. Not it in the way Knuth hoped, but in the practical, modern sense. Various efforts to undermine javascript idioms are met with hostility from me.