javascript - JavaScript (ECMAScript5) 严格模式是否提供了显着的性能优势以值得广泛使用？

Question

我正在阅读一些关于使用 JavaScript 的严格模式的内容，一般来说，这个想法似乎是将一组更严格的规则强加给编码器，以确保 JS 引擎可以更好地优化代码。它几乎感觉就像是 Visual Basic 中“Option Explicit”的 JavaScript 等价物。

如果这基本上是将严格模式应用于我的代码的净效果，那么性能差异是否值得出于习惯而不是逐案应用？除了代码稳定性之外，还有其他值得考虑的优势吗？

我希望将严格模式应用于我的脚本的一些关键原因是什么？

Answer 1

好吧，严格模式代码当然可以表现得更好，因为它消除了使优化更难的问题，例如，从我的脑海中：

• 该with语句被删除（真的很难 - 如果不是不可能的话 - 优化）。
• 不再有未声明的分配和其他禁令，例如 ( delete varName;)
• eval不会将变量/函数声明引入本地范围。
• arguments.callee被删除，（难以优化（例如函数内联））
• arguments对象索引命名属性不再动态映射到命名形式参数。

Answer 2

我认为 John Resig 很好地说明了使用它的原因，http ://ejohn.org/blog/ecmascript-5-strict-mode-json-and-more/，看来 Firefox 会支持它，http ://whereswalden.com/2010/09/08/new-es5-strict-mode-support-now-with-poison-pills/，因此至少对于图书馆而言，查看它可能很有用。

但是，基本上，它是为了帮助防止一些常见的编程错误，但对于一些人来说eval可能是不使用它的原因，而且对我来说没有未命名的匿名函数会很困难，但是，任何可以帮助减少错误的东西都可能是值得。

Answer 3

我不知道性能是否值得，但我想你的结果可能会有所不同。我想这取决于你的脚本。但这并不意味着要成为重点，而是减少您维护代码的时间。因此，任何可以节省您维护代码的时间（和金钱）并使其更快的东西都是黄金。

我已得到纠正，遗憾的是，它不包括强类型。研究人员花了很多年时间来强制键入以在编译时检测错误，现在我们必须相信我们的代码是好的，或者通过手动或单元测试来验证它。恕我直言，在许多地方花费在单元测试上的时间通常很少，不应该花在编译器可以完成的事情上。