"use strict"
プログラミングが終わったときにそれを含めて、JavaScriptドキュメントを誰にでも公開する必要があるのではないかと思います。うまくコーディングしたことを確認するために使用するのが好きです。
"use strict"
では、 JavaScriptファイルを公開するときに、使用を含めるか、単に削除する必要がありますか?
私が尋ねる理由は、JavaScriptファイルのスペースを節約するためです。
"use strict"
プログラミングが終わったときにそれを含めて、JavaScriptドキュメントを誰にでも公開する必要があるのではないかと思います。うまくコーディングしたことを確認するために使用するのが好きです。
"use strict"
では、 JavaScriptファイルを公開するときに、使用を含めるか、単に削除する必要がありますか?
私が尋ねる理由は、JavaScriptファイルのスペースを節約するためです。
strict mode
本番環境での使用について、次の 2 つの意見を見つけました。
プロダクション コードで「use strict」を出荷する理由はありません。パフォーマンスの向上はなく (V8 チームと Brendan で少し前に検証済み)、ユーザーの VM が追加のチェックを行う必要もありません。開発のみに留め、ビルド中に削除します。このようにして、参照している連結の問題も回避できます。
と:
パフォーマンスが向上しない場合もありますが、パフォーマンスが低下することもありません。本番環境では、開発環境よりもさらに、エラーに確実に気付く必要があります。コードの開発バージョンと本番バージョンの間の変更を最小限に抑えることは、問題を迅速かつ効率的にデバッグできるようにするための鍵です。はい、開発中に役立ちますが、製品コードから引き出す理由はありません。
そしてもちろん、その12b
重"use strict"
さは何も変わりません。
この行"use strict";
は、ファイルの 13 バイトを構成します。これがファイル サイズの 1% に近づく可能性は低いと思います。
帯域幅が気になる場合は、サーバー側での gzip 圧縮と一緒にファイル サイズを縮小するために、多くのミニファイヤーの 1 つを使用してください。手動で 13 バイトを削除するのは、経済的ではありません。
どのミニファイアーが正確にコードに依存するかは、コードによって異なりますが、ここにいくつかの提案があります。
確かにこれはマイクロ最適化ですが、JS モジュールを (たとえば 25 個) 連結すると、突然 250 バイトになります。
1 分あたり 1000 ヒットなど、トラフィックの多いアプリケーションで本番環境にデプロイすると、ビルドで'use strict';
s
AWSで数ドル節約できると確信しています...
時間の価値がないこと以外に、それを本番環境に維持するための説得力のある議論を見たことがありません。おそらくそうではありませんが、既にビルド システムを持っていて、最小限の労力でこれを実現するノウハウがあるのであれば、なぜでしょうか?
現在、本番用のコードでは「use strict」を削除することをお勧めします (デバッグで使用するだけです)。
ただし、ファイルを小さくするためだけに削除することはしません。私がそれを削除する理由は、現在のところ、実行時に JavaScript の実際のパフォーマンスに悪影響を及ぼしているように見えるためです。これが最終的に変更されることを願っていますが、現時点ではパフォーマンス上の理由から省略します。