ES Modulesを導入した場合の課題

ES Modulesを採用し、JSファイルを細かく分けた場合、ウェブサーバーから転送すべきファイルの数が増える傾向があります。

みなさんもご存知の通り、HTTP/1.1プロトコルでは同時接続数が限られるため多くのファイルを転送するのが苦手です。ウェブ制作の現場ではCSSスプライトやJSファイルの結合などの手法でファイルを一つに結合し、転送ファイルの数を減らしますよね。

転送ファイルが増えることの解決には、HTTP/2に対応したウェブサーバーへ移行するのが適した手段の一つです。ES ModulesでJSファイルの数が増えても、HTTP/2プロトコルでは支障にならないでしょう。

それどころか、HTTP/2環境下ではウェブサイトの読み込みでメリットがあります。ウェブサイト内の共通JSやベンダーJSはブラウザのキャッシュに任せて(キャッシュヒット率を高めて)、ページ固有のJSファイルだけ転送する形としたとします。そうすると、ページごとに必要な差分JSしか読み込みが発生しなくなるはずです。

モジュールバンドラーとの比較

規模のあるJavaScriptの開発ではモジュールの仕組みは必須です。昨今のフロントエンドの開発ではwebpackやRollupなどのツールを使ってモジュールのJS開発をしている方がほとんどでしょう。

これらのツールは現行ブラウザでもモジュールの仕組みを利用できるように、ES Modulesを使ったコードをES5互換のJSファイルへと変換します。

ES Modulesがブラウザで標準で使えるようになった場合、このワークフローは変わっていくのでしょうか。

モジュールバンドラーは不要になる?

都内の勉強会に参加すると、「ES Modulesが普及すると、バンドルツールは不要となる」といった意見をよく聞きます。その時代にはきっとES2015の全機能はブラウザ標準で使えるようになっているでしょう。わざわざNode.jsでBrowserifyやBabelなどの環境構築をする必要がなくなるかもしれません。ネイティブにそのままブラウザで確認できる利便性は大きな利点です。

モジュールバンドラーが必要な場面はある

ただし、パッケージマネージャーnpmで管理するJSライブラリをバンドルするにはwebpackなどのツールが必要で、JSXTypeScriptなどのコンパイラも必須なのは変わらないはずです。高度なSPA開発では引き続きこの手のツールは使われるはずです。

ES Modulesが現状のフロントエンドの作り方を破壊するのではなく、組み合わせることで様々な課題にアプローチできるようになると考える方が望ましいでしょう。

まとめ

ES ModulesはこれまではJavaScriptの開発スタイルに変化をもたらす大きな機能です。すでにモジュールバンドラーの利用者はES Modulesに親しんできたかもしれませんが、これからはブラウザネイティブで利用できる時代となっていくでしょう。

今回は、ES Modulesの概要を紹介しただけでしたが、続編記事ではES Modulesのさまざまな記述方法・使い方を解説します。この記事で解説したサンプルはGitHubにて公開しています。