ここから先はミラーです。
上の記事を読んで、思ったことを書いてみます。
結論から先に書くと、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)を行う自体は、babel-standaloneをブラウザ上で動作させて、(Babel上でReactのBabelプラグイン?を動作させることで)ビルドステップ
なしで行えます。
(ブラウザ上でJSX→JSの変換処理を行えるJSX Loaderの実装も存在します。)
...推敲中？