Является ли JavaScript (ECMAScript5) строгим режимом, обеспечивающим значительные преимущества в производительности, чтобы заслужить широкое использование?

Я немного читаю об использовании Strict Mode для JavaScript и кажется, что, вообще говоря, идея состоит в том, чтобы заставить более жесткий набор правил кодеру обеспечить, чтобы JS-движок мог лучше оптимизировать код. Это почти похоже на эквивалент JavaScript "Option Explicit" в Visual Basic.

Если это в основном чистый эффект применения строкового режима к моему коду, будет ли разница в производительности такой, что стоило бы использовать привычку, а не в каждом конкретном случае? Существуют ли другие преимущества помимо стабильности кода, которые можно было бы рассмотреть?

Каковы некоторые из основных причин, по которым я хотел бы применить Strict Mode к моим скриптам?

Ответ 1

Ну, строгий режим кода, безусловно, может работать лучше, потому что он устраняет проблемы, которые затруднили оптимизацию, например, с моей головы:

Оператор with был удален (действительно сложно - не невозможно - оптимизировать).
Не более необъявленных назначений и других запретов, например. (delete varName;)
eval не вводит объявления переменной/функции в локальную область.
arguments.callee был удален (трудно оптимизировать (например, встраивание функций))
Объектные индексы с индексом объекта arguments уже не динамически сопоставляются с указанными формальными параметрами.

Ответ 2

Я думаю, что причины его использования были хорошо прописаны Джоном Ресигом, 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, может быть основанием не использовать его, и для меня не будет иметь неназванных анонимных функций, но что-нибудь, что может помочь уменьшить ошибки, может быть стоит.

Ответ 3

Я не знаю, будет ли производительность достойной, но я думаю, что ваши результаты могут отличаться. Я полагаю, это зависит от вашего script. Но это не значит, что это главное, но сокращение времени на поддержание вашего кода. Итак, все, что позволяет сэкономить ваше время (и деньги), поддерживая ваш код, и делает его быстрее, является золотым.

Я был исправлен и, к сожалению, он не включает сильную типизацию. Исследователи использовали много лет для принудительного ввода текста для обнаружения ошибок во время компиляции, и теперь нам нужно доверять тому, что мы хорошо разбираемся в коде или проверяем его вручную или модульным тестированием. IMHO, время, затрачиваемое на модульное тестирование, обычно бывает скудным во многих местах, и его нельзя тратить на то, что может сделать компилятор.