ES(ECMA Script)仕様にJSX は入るのか？
上の記事を読んで、思ったことを書いてみます。
結論から先に書くと、JSXがES仕様に入る可能性はゼロです。
何故かには、幾つか理由があります。
EC39のMtrix Roomのスレッドにも書かれています。
１つめ
HTML/XML に関連する提案はEC39(ES仕様の標準化の委員会)にて
十中八九却下されてきたからです。
HTML/XML の(関連)仕様として、WHATWG/W3Cにて策定/標準化されるべき
であり、EC39で議論すべきことではない、ということでしょう。
２つめ
JSXに HTML/XML 以外でのユースケースがないからです。
JSXは HTML/XML と密接に関連しているようにみえます。
HTML/XML 以外でのユースケースがない(HTML/XML 限定の)
仕様(案)は ES仕様としてどうなの？というハナシです。
３つめ
JSXが曖昧な仕様であり、ES仕様に含まれるには複雑
すぎるからです。
JSXは現状、サーバーサイドJSの実行環境で、JSX→JSへの変換
処理時にJSX内のHTML/XMLを関数呼び出しに変換する処理を行いま
す、どのような関数に変換するかに汎用的なルールはなく、(ライブラリの)
実装依存です。
ReactやVue.jsのJSXは、それぞれのvDOM(仮想DOM)の関数に
変換、Solid.jsのJSXは、Solid.jsの(DOM操作の)関数に変換、
HonoのJSXは、HonoのJSXの関数に変換しています。
JSXの仕様を標準化するためには、実装依存となっているJSXでの
HTML/XML→関数の変換ルールを汎用的なルールとして明文化し
APIを定義する必要があると思います。
JSXの記法も、ES仕様に含まれるには複雑すぎます。
(ES仕様のテンプレートリテラルの構文をみると
変数の展開のみサポートしています。)
JSXの仕様は、ES仕様とは別の場所で標準化すべきであり、
ES仕様の一部として標準化する内容ではないです。
４つめ
JSXでの変換処理がES仕様として策定するには高コスト
だからです。
もしJSXがES仕様の一部になれば、ブラウザetcにJSXが
ネイティブで実装されるので、JSX→JSの変換処理が不要になり、
JSXの処理が高速にはなりますが、ただ、それだけです、他に
メリットはありません。
JSXの処理が高速になるとはいっても、JSの他の機能と
較べると低速で高コストです。
メリットがJSXの処理の高速化だけでは、JSXのES仕様化が成る
ことはないでしょう。
WEBアプリにおけるビルドステップの省略
JSX→JSの変換処理を必要とするWEBアプリでのビルドステップの省略
を考えるのなら、JSXのES仕様化ではなく、他のアプローチを考える
べきです。
WHAT WG でのJSXの標準仕様化を目指すのも、アプローチの１つかも
しれませんが、JSXのES仕様化と同じく現実的ではありません。
(JSXのES仕様化よりもまだ現実的なアプローチのような気はします
が。。。)
現在、JSX→JSの変換処理がブラウザでの実行前にビルドステップで
行われているのは、JSX→JSの変換処理のコストが１ファイルでは
それほど問題にならなくても何十何百ファイルに対して行われた場合、
それなりに高コストだからです、ビルドステップとして分離すること
でブラウザでのWEBアプリの実行時のパフォーマンスに影響を与えない
ようにしています。
現在、JSで実装されているJS→JSXの変換処理を Rust etcで実装
して Web Assembly化 すれば、JSの実行環境にネイティブで実装
した場合ほどではないにしても 高速化できるはずです。
ビルドステップとして分離しなくても実用できるかもしれません。
サーバーサイドであれば、JS→JSXの変換処理をRust etcでネイティブ
実装すれば、高速化できます。
(もしサーバーサイドでのJS→JSXの変換処理のネイティブ実装で
ビルドステップとして分離しなくても実用できるだけの
パフォーマンスが出なければ、ブラウザにJSXがネイティブ実装
されたとしてもビルドステップとして分離しなければ実用できません。)
ブラウザ(クライアントサイド)でJSX→JSの変換処理(React)を行う
JSX Loaderの実装は既に存在するので、(JSXがブラウザにネイティブ
に実装されていなくても)ビルドステップなしでJSX→JSの変換処理を
行えることは実証されています。
...推敲中？
Discussion