In the past maintainers of the major JS runtimes (v8, etc) have stated they avoid documenting performance and optimization tips, because people build code around them and as a result the engine maintainers can't make fundamental changes without regressing performance of those apps. With how widely some JS libraries get distributed, you can imagine how this becomes a problem. It's a nasty situation.
If the difference between a game running at 30fps and 60fps is using weird optimizations to compensate for quirks in v8 and spidermonkey, you better believe I'm going to optimize for them. But then script runtime changes later make my performance tank when other (originally slower) pieces of code speed up.
One thing I've noticed is that in the past, performance advice was given for specific engines (e.g. V8/crankshaft). Nowadays, if any performance advice is given, it's applicable to all major JavaScript engines, and in general the advice is for developers to write "idiomatic JavaScript", leaving the optimization to the engines.
I have a feeling those optimizations apply to all engines because they applied to V8, and maintainers of the other engines attempted to match their performance since so many were coding for performance on V8 only.
When coding JS, I've always tried to optimize based on my experience with multiple languages ... the usual culprits, like keeping the operations inside loops to a minimum, using native functions whenever possible, etc.
So I assume that the 'universal' speed tips apply to JS as well. So far - when I've refactored for speed gains - they have.
If the difference between a game running at 30fps and 60fps is using weird optimizations to compensate for quirks in v8 and spidermonkey, you better believe I'm going to optimize for them. But then script runtime changes later make my performance tank when other (originally slower) pieces of code speed up.