JVMをWebAssemblyの代わりに使用できないのはなぜですか？
私が理解している限り、JavaScriptは動的な性質を持つため、事前にコンパイルすることはできません。したがって、解釈とジャストインタイムのコンパイルは実行時に行われ、JavaScriptのパフォーマンスに影響します。したがって、WebAssemblyが登場します。言語は事前に中間形式（WASM）にコンパイルできます。実行時のオーバーヘッドが少ないため、これにより良好なパフォーマンスが得られます。
私の質問は、WebAssembly VMの代わりにJVMを使用できない理由です。 Java中間形式（バイトコード）にコンパイルされます。このバイトコードはブラウザに提供でき、JVMはそれを実行できます。JVMはJITもサポートしており、ネイティブに近いパフォーマンスを実現できます。
では、新しいWebAssemblyの必要性は何でしょうか。なぜJVMをブラウザに統合できず、既存の最も人気のあるJava言語を利用して高いパフォーマンスを実現できないのでしょうか。
JVMがWebAssemblyの代わりに適切なランタイムと見なされなかった理由はたくさんあります...
- WebAssemblyは、HTTP経由の配信とブラウザベースを念頭に置いて設計されました。そのため、ストリーミングコンパイルをサポートしています。つまり、ダウンロード中にコードのコンパイルを開始できます。
- WebAssemblyはコンパイル時間を短縮するように設計されており（その結果、Webページはすばやく読み込まれます）、これは、Java/JVM言語と比較して非常に単純な検証ルールを持つことでサポートされます。
- WebAssemblyは、「ホスト」環境、つまりブラウザのコンセプトで設計されました。
- WebAssemblyは安全でシンプルになるように設計されており、全体的な攻撃対象領域を最小限に抑えます。
- WebAssemblyは非常に多くの言語（C、C++、Rustなど）をサポートするように設計されていましたが、JVMは当初、単一言語のJava用に設計されていました。
一般的な観察として、WebAssemblyはWeb上の複数の言語をサポートするように設計されました。 JVMはデスクトップでJava=をサポートするように設計されています。より一般的な意味でどちらか一方を他方よりも優れたものにするわけではありません。
最後に、JVMはブラウザー（Javaアプレット）と統合されましたが、結局うまくいきませんでした！
WebAssemblyの High-Level Goals からの引用：
asm.jsとほぼ同じ機能を持つ標準の最小実行可能製品（MVP）。主にC/C++を目的としています。
したがって、元々の目標は、WebブラウザでC/C++プログラムを実行することでした。Javaコードを実行することではありません。
JS実行のほとんどの時間はサーバーからクライアントへのコードの送信に費やされます。バイトコードは背後にある実際のソースコードよりも大きくなる傾向があるため、バイトコードにコンパイルする必ずしも高速化する必要はありません。
JS自体はすでに十分な速度で実行されますほとんどの場合（JITコンパイルはJVMだけで行われるわけではありません）。これらのまれなケースでは、パフォーマンスが本当に重要でした（大規模なデータセットの操作、多くの計算（ゲームエンジンなど））。JSは動的な性質（つまり、ガベージコレクション、クロージャーなど）があるために遅くなります。これがまさにWASMが解決することであり、ガベージコレクションなしで実行されるため、これらの特定のケースでは大幅に高速化できます。
JVMは、ここでの仕事に適したツールではありません。