webpackを使用する理由を理解するために、バンドラーが登場する前にWeb上でJavaScriptをどのように使用していたかをおさらいしましょう。
ブラウザでJavaScriptを実行するには2つの方法があります。1つ目は、機能ごとにスクリプトを含める方法です。このソリューションは、スクリプトが多すぎるとネットワークのボトルネックが発生する可能性があるため、スケーリングが困難です。2つ目のオプションは、プロジェクトコード全体を含む大きな `。js` ファイルを使用する方法ですが、これはスコープ、サイズ、可読性、保守性の問題につながります。
IIFEは大規模プロジェクトのスコープの問題を解決します。スクリプトファイルがIIFEでラップされている場合、スコープの衝突を心配することなく、ファイルを安全に連結または結合できます。
IIFEの使用により、Make、Gulp、Grunt、Broccoli、Brunchなどのツールが登場しました。これらのツールはタスクランナーと呼ばれ、すべてのプロジェクトファイルを連結します。
ただし、1つのファイルを変更すると、全体を再構築する必要があります。連結により、ファイル間でスクリプトを再利用しやすくなりますが、ビルドの最適化が難しくなります。コードが実際に使用されているかどうかをどのようにして見つけることができますか?
lodashの単一の関数しか使用しない場合でも、ライブラリ全体を追加してから圧縮する必要があります。コードの依存関係をどのようにツリーシェイクしますか?コードチャンクの遅延読み込みは大規模では難しく、開発者による多くの手作業が必要です。
Webpackは、ブラウザ環境外のコンピュータとサーバーで使用できるJavaScriptランタイムであるNode.js上で実行されます。
Node.jsがリリースされたとき、新しい時代が始まり、新たな課題が生まれました。JavaScriptがブラウザで実行されていない場合、Nodeアプリケーションはどのように新しいコードチャンクを読み込むのでしょうか?追加できるHTMLファイルとスクリプトタグはありません。
CommonJSが登場し、 `require` が導入されました。これにより、現在のファイルでモジュールを読み込んで使用できます。これは、必要なときに各モジュールをインポートすることにより、スコープの問題をすぐに解決しました。
JavaScriptは、言語、プラットフォーム、そして高速なアプリケーションを迅速に開発および作成する方法として、世界を席巻しています。
ただし、CommonJSのブラウザサポートはありません。ライブバインディングはありません。循環参照に問題があります。同期モジュールの解決と読み込みは遅いです。CommonJSはNode.jsプロジェクトに最適なソリューションでしたが、ブラウザはモジュールをサポートしていなかったため、Browserify、RequireJS、SystemJSなどのバンドラーとツールが作成され、ブラウザで実行されるCommonJSモジュールを作成できるようになりました。
Webプロジェクトにとって朗報は、モジュールがECMAScript標準の公式機能になりつつあることです。ただし、ブラウザのサポートは不完全であり、バンドリングの方が高速であり、これらの初期のモジュール実装よりも現在推奨されています。
従来のタスクランナーやGoogle Closure Compilerでさえ、すべての依存関係を事前に手動で宣言する必要があります。webpackなどのバンドラーは、インポートおよびエクスポートされる内容に基づいて依存関係グラフを自動的に構築および推測します。これは、他のプラグインやローダーと合わせて、優れた開発エクスペリエンスを実現します。
…モジュールを作成できるだけでなく、あらゆるモジュール形式(少なくともESMになるまで)をサポートし、リソースとアセットを同時に処理できるものがあればいいのにと思いませんか?
これがwebpackが存在する理由です。これは、JavaScriptアプリケーション(ESMとCommonJSの両方をサポート)をバンドルできるツールであり、画像、フォント、スタイルシートなど、さまざまなアセットをサポートするように拡張できます。
Webpackはパフォーマンスと読み込み時間に関心を持っています。非同期チャンク読み込みやプリフェッチなどの新機能を常に改善または追加して、プロジェクトとユーザーに可能な限り最高のエクスペリエンスを提供します。