サーバーサイドpushはまあ現実的に使えるのか難しいよね、サーバーサイドpushに夢求めすぎてたよねっていうのは一度は誰もが経験するところではあって、みんな夢は覚めたと思うけど、場合によっては使えるかもねと思うケースは1つあります。起点となるhtmlの最終更新日を見てそれよりも新しいファイルがあれば一括で送りつける、というのは可能かもと思います。サーバ側でシーケンシャルな日付のリストを用意しておけば難しくないですし。ただ、ダウンロード失敗等を考えると、前回ダウンロードに成功したファイルの中の一番新しいファイルの更新日時を送ればより安全かなぁ、と思います。index.htmlがサーバで動的生成されるファイルだとまた話はややこしいのですが・・・まぁ、確実でムダのないサーバーサイドpushは難しいですよね。上記のブログに書かれている手法で本当に行けるのかな？と思うてんを列挙します。
ファイル一覧をダウンロードする方式でES6 Modules使えるのか？
上記のエントリーで上げられている、ファイル一覧をダウンロードしてそれを元にクライアントがダウンロードする、という方法って、ES 6 Modulesでロードできるのかなぁ、というのがわからないんですが、これってできるんですかねぇ？
考えられる手法としては、ファイルローダーのスクリプトだけが含まれた.jsを最初に読み込んで、そこで上記の作戦でXHRか何かでファイルを読みこんで一度キャッシュに入れて(入る？)、全ファイルがロードされたのを確認して、ES6 Modulesで各スクリプトを使うというアプリのメインの.jsをjsonp的に使う・・・とかですかねぇ。
HTTP/2のパイプライニングはそんなに良いのか？
デスクトップは良いとして、モバイルで運べるパケット数には時間当たりの上限は厳しいです。いくらヘッダが圧縮されるとはいえ、ファイルが多くなればなるほど、一度読み込んだファイルの更新日時を送信したり云々といったコストは増えます。
ファイル数30〜50ぐらいなら別にいいと思うんですが、今のnpmの使われ方を見ていると、ある便利ライブラリを1個ダウンロードすると、そこから10個-20個ぐらいの大量のモジュール群が利用されて・・・みたいな感じです。2-3個ライブラリを読み込むと似たような機能のモジュールを何個も読み込むとかあります。ソフトウェアの世界には「無限にOK」というのはないのですが、1アプリ作るのに必要なモジュール数が、数100個、数1000個とどのぐらいまで増えるのか、それによってどのように特性に影響するのかはこれからわかってくるのかな、と思っているところです。
今現在の状況だけを見て「これなら行ける！」と言っちゃうのは、プロのエンジニア失格です。時間変化(ムーアの法則等も含めて)を先読みしたデザインをするのがプロですよね(明後日の方を見ながら)。
結局concatはいらなくなるのか？
個人的にはいらなくならないと思います。サーバープッシュが夢の技術じゃない、というが分かった時点でラウンドトリップ問題は解決しないということになります。concatの欠点として、粒度がでかすぎる、というのがあげられています。逆に言えばそこさえ良くなればみんな納得するところかなと思います。
考えられるのは、1ファイルにconcatするのではなくて、変更の少ないライブラリ層、ページ単位(シングルページアプリケーションなら)、変更の多いライブラリ層と、1桁〜2桁前半個のモジュールにconcatするみたいなツールが出てきて、生成されるライブラリを全部htmlのscriptタグに入れておけば、ラウンドトリップもなく、並列で処理できて、ウマーとなるんじゃないですかね？
