IE終了により、webpackやbabelを使う必要がなくなるのか、フロントエンドからビルドステップを完全に消し去ることはできるのか。
そもそもなぜフロントエンドを「ビルド」していたのか
そもそもなぜwebpackやbabelを使ってJavaScriptをバンドル（1ファイルにまとめる）していたのか
1. HTTP/1.1とモジュールシステムの相性の悪さ
ブラウザにはES Moduleというモジュールシステムが導入されています。これはimport文で他のファイルを読み込むことができるシステムです。
HTTP/1.1については、ブラウザ側で同時接続数制限があります。これは、ファイルを多数読み込む必要があるES Modulesには不向きでした。
2. ブラウザのES Module対応率の低さ
ES ModulesはIE非対応です。開発するWebサイトがIEをターゲットにしたい場合、ES Moduleを使うことはできません。
また、JavaScriptフレームワークもシェアを獲得するにはIE対応しなければならず、これらを使っている限りブラウザ上でES Modulesを使うことはできませんでした。
3. 高機能なIDEサポートの欠如
TypeScriptなどの静的型付けAltJSを使用すれば高機能なIDEサポートを受けられます。一方、ブラウザで動くJavaScriptの構文では補完や診断などのIDE機能は利用できませんでした。
IE終了後はどうなるか
1. HTTP/2と<link rel="preload">
HTTP/1.1に代わってHTTP/2が普及したことにより、同時接続数制限が無くなりました。
また、<link rel="preload">が導入されたため、後からimportされるモジュールを全て先読みしておくことが可能になりました。
そのため、パフォーマンスの問題は存在しません。
少し試してみたところ「HTTP/1.1 + bundle」よりも「HTTP/2 + <link rel="preload">」のほうが高速でした。
ただし、高速化するためには深い場所（importしたファイルからさらにimportされるなど）にある依存関係も含めてpreloadする必要があります。
つまり、パフォーマンスを維持しながらwebpackやbabelを捨てるには「依存解析を解析し<link rel="preload">をまとめてHTMLに突っ込んでくれるライブラリorフレームワーク」が必要です。
更に、今後「103 Early Hints」が本格導入されると、さらにモジュールの先読みができるためもっと高速になります。
2. 全モダンブラウザがES Modulesに対応済み
2022年6月16日にIEが亡くなられたので、本番環境でES Modulesを使っても問題ないでしょう。
3. Denoによる高機能なIDEサポート
Denoはブラウザと同じURLベースのimport文を採用しています。そして、Deno組み込みのlanguage serverはブラウザで使われる構文に対して補完や診断を出すことができます。
つまり、エディタにDeno拡張機能をインストールすればブラウザ向けESMに対してIDE機能が使えます。
（Node.js向けのtsserverでもいいのですが、Denoを使うとHTTP経由で読み込んだモジュールにも補完が出ます。）
更にTypeScriptも使えます。
TypeScriptやJSXのトランスパイルもサーバー上で行うことができるライブラリがあるため、これを使えば完全にビルドステップを消し去ることができます。
https://github.com/ayame113/ts-serve
これをcloudflare workersやdeno deployなどのエッジコンピューティングサービスで動かすと、処理能力的にも読み込み速度的にも十分実用的です。
総合すると、フロントエンドのコードをbundleする意味は原理的にはほぼほぼ無くなっていると言えます。
現実的にビルドステップを廃止することは可能か
では既存のプロジェクトから今すぐwebpackやbabelを剥がしてビルドステップを消すことは現実的に可能でしょうか。
フレームワークを使っている場合
Next.jsやReactなどのフレームワークやミドルウェアやライブラリに縛られているため、バンドラーを今すぐ捨てるのは不可能だと思います。
そもそもnode_modulesをどうするかという問題もありますし。
ただし、最近はブラウザでnative ESMを使う思想のフレームワークも出てきているため、それらに乗り換えることで間接的にwebpackやbabelを捨てていけると思います。
フレームワークを使わない小規模なサイトの場合
依存関係が小さい場合、普通にブラウザで<script src="./main.js" type="module">のようにESMを読み込んでしまって問題ないと思います。
npmライブラリも、https://esm.sh/ 経由で読み込めば使えます。
フロントエンドでパフォーマンスを維持しながらESMを使うためには、1項で書いたように「深い依存関係を読み取って自動でHTMLに<link rel="preload">を挿入してくれるライブラリ」が必要です。
これをcloudflare workersやdeno deployで動かしながら効率よくトラフィックを捌いていくのが大事だと思うのですが、それも結局フレームワークを作っている側の内部実装の話になるので、ユーザーがすぐ切り替えてどうこうという話ではありません。
まとめ
- IE死んだのでそろそろバンドラー使う意味はないかも（理論上は）
- 結局のところフレームワークの内部実装をどうしていくかという話であって、今すぐwebpackとbabelをdependenciesから外そうという話ではない
- 小さいプロジェクトでは普通にESM使っていい（使っている）
今すぐbabel捨てるみたいな話にはならなくて、2年後3年後にbabeらないフレームワークが普通になってくるかもね、くらいの温度感です。
そもそもブラウザで動かすコードをブラウザで動かない構文（require('lodash')）で書いた上で1ファイルに結合して使う、というのは言語として不健全極まりない形なので、書いたものがそのまま動く世界を実現したいところです。