そういえばcjsとかmjsてなに？

CommonJSはそのままではブラウザで動かない。requireとか使う方。
ESMはES2015で策定されたものでimportとか使う方
https://de-milestones.com/what-is-cjs-umd-esm/

と言うことでESModuleからCommonJSのモジュールをimportできる。

ES Modules
新しい
ウェブブラウザがデフォルトで採用
Node.jsも最近のバージョンで対応済み
CommonJSで書かれたモジュールが呼べる
全てをES Modulesにしていくために今まさに色々進められている

CommnoJS については [CommonJS] に詳しく書く。一言で言うと Server Side JavaScript の仕様のこと。Server Side の仕様であるため、.js ファイルに分割して <script> タグで読み込む、といった前述の手法は利用できない。そのため、新たなモジュールのための API 仕様が必要となった。

グローバルオブジェクト、CommonJS、AMD、UMD と、ここまでで JavaScript のモジュールの記法が様々登場した。これは、JavaScript の言語仕様にモジュールに関する仕様がなかったために生じた問題である。
ES6 では、よやくモジュールの仕様が言語仕様に含まれるようになった。ES6 の記法では、export および import が記法としては用いられる。

なるほど

TypeScript では
トップレベルに import もしくは export をもったファイルは全てモジュールと考えられる
逆に、トップレベルに import もしくは export がないファイルは、グローバルなスコープで利用可能なスクリプトとして扱われる

あーなるほどなるほど

デモの環境ではHTTP/2でリソースが配信されているため、1つのコネクションで複数リクエストを扱えています。そのおかげで幾分悪くない速度にはなっていますが、1リクエストに対して1コネクションとなるHTTP/1.1の場合には問題になります。本番の製品開発ではこうした依存解決のリクエストだけで数百、数千の数に上ることが想像できます。

んーなるほど

「そっか、君は Create React App でプロジェクト生成したものをそのまま拡張するやり方しかやったことないから、JavaScript のモジュール周りのこととか全然知らないんだね。

ぼくやん

「CommonJS が提供したモジュールシステムによって、JavaScript でもやっとライブラリ作者が自分の開発したパッケージを他の開発者たちに手軽に使ってもらえる形で提供できるようになった。
　そしてパッケージ管理システムとしての npm とその公式リポジトリが構築され、たくさんのパッケージが公開され始めた。こうして CommonJS プロジェクト発足の目的は大成功といえるレベルで達成されたわけだね」

これおもろいよなー、アナロジーとして他にも転用できそうな

「この webpack の何がすごいかって ES Modules、CommonJS、AMD を含めたさまざまなモジュール構文をサポートしていて[2]、使われている構文を自動で検出し適切に解釈してくれるので、異なるモジュール構文が混在していてもおかまいなしに依存関係を解決してバンドルしてくれるのね」

「webpack を始めとする最新のモジュールバンドラがやっているのは、もはやネイティブアプリのビルドと遜色ない作業であって、ビルド先がバイナリコードかテキストコードかのちがいでしかない。
　そのターゲットが Android アプリなら ARM 系 CPU の上で動く Android OS なのと同様、モダンフロントエンド開発ではそれがネットワークの向こうにある V8[3] や Nitro[4] で動いてるブラウザというだけの話なんだよ」

卓越した視点

Webpackを理解せずに現代のフロントエンドを理解することはないということがわかった