Originally Posted by felgall
how is "use strict" in ES5 any more recent than ES5 itself? that doesn't make sense. eval, with, arguments.callee, Function, etc, those are all defined in the same spec as "use strict".
what "oold scripts would break in modern browsers" if "use strict" were not added? i can't think of any that work "using strict" that would work without it.
can you provide an example of what you mean? this is bordering on McCarthyism...
there is nothing inherently newer or more modern about "use strict" compared to ES5, other than newly limiting your options compared to pre-911 JS.
don't take our word for it, listen to mdn (updated 2/9/2013)
Strict mode in browsers
Browsers don't reliably implement strict mode yet, so don't blindly depend on it. Strict mode changes semantics. Relying on those changes will cause mistakes and errors in browsers which don't implement strict mode. Exercise caution in using strict mode, and back up reliance on strict mode with feature tests that check whether relevant parts of strict mode are implemented. Finally, make sure to test your code in browsers that do and don't support strict mode. If you test only in browsers that don't support strict mode, you're very likely to have problems in browsers that do, and vice versa.
that sounds like a whole lot of work for relatively little payoff.
what if the payoff of strict?
1. potentially performance - not yet, some things are actually slower with strict, and V8/FF optimizes things they used to think couldn't be optimized (like with), negating many future gains strict might have someday provided when drafted.
2. security - maybe, although viewing a function's source doesn't mean you can probe privates, even if you can see their names. At any rate a function can be safely written in strict or normal using the right semantics.
3. preventing code mistakes. probably the best use of "use strict". Not as comprehensive as JSLint/JSHint, but not a bad thing in dev environments.
avoiding implicit globals is a win, but im guess that folks who worry about implementing "use strict" are not making such easily-detectable errors. Since the other lint tools are better, this usage of strict is limited in benefits.
4. future compat -or "someday JS might remove with(obj)". "use strict" doesn't let you do anything you can't do without it, or anything you can do in ES6. When future JS is out and uptake is sufficient to use it on production, our code is going to need a lot of re-writing to use all the new features. It will not break code then it does arrive. given all that, this seems like premature optimization based on speculation.
so, all the advantages for "use strict" have yet to really pan out. If i saw a new client that only ran strict, or some impressive before-and-after benchmark numbers, or some V8 optimizations, i might be more inclined to recommend it.
i will concede that sometimes "use strict" is ok.
certain low-level utilities that work in strict or regular should probably go-ahead and add "use strict". It won't hurt anything, doesn't take up a lot of space, and maybe one day it will actually run your function faster. In a tightly-controlled environment designed for low-power devices, a global use-strict help prevent some performance killer and memory hogs, but you better have every bit unit tested and freshly coded if that's how your'e gonna roll.
lastly, one really annoying about all this:
A lot of newcomers to JS seem to think "use strict" is cool, so if you use it you are cooler in their eyes. It's the new HTML validation. If it validates, then your code is awesome right? It's handy to point to a tiny thing anyone can do and say "it makes it better/ok", but if you look at the costs/benfits of "use strict", it's not a no-brainer.