JavaScriptを単一のクロスプラットフォームコンパイルターゲットとして使うこともできるよね。何が違うの？

コンテナをWASIに置き換えない理由はないよ。コンテナって本当にひどいもので、VMにすべきだと思う（WASMの意味でね、「仮想X86でLinuxを動かす」って意味じゃなくて）。ツールがまだ整ってないんだよね。みんなDockerのサポートにまだ囚われてるし。

そうだね、問題は…「理論上」ってことは、WASMが本当に役に立たないなら誰も賭けないってことなんだ。人々はHTML、CSS、JavaScriptを使ってるけど、それはすごく役に立つって証明されてるから。WASMは無駄ではないけど、どうやって人々がそれに親しむことができるの？ほとんどの人にとっては異星のスタックみたいなもんだよ。

まだ見てないなら、[0]を観ることをおすすめするよ。JavaScriptの歴史について、たしか2035年まで説明してるから。 [0] https://www.destroyallsoftware.com/talks/the-birth-and-death...

30歳でママと住んでる天才児みたいに、いつかは潜在能力の話をやめて、結果の話をしなきゃいけない時が来るよね。この場合、理論と実践が合ってないし、WhatWGのボードにいる企業は、自分たちの儲かるアプリストアが、どんなアプリも同じように動かせるプラットフォームに脅かされないようにする利害関係があるって多くの人が指摘してるのを覚えてる。Native Clientが登場して、複雑なネイティブアプリをウェブにコンパイルして、ネイティブの95%の速度で動かせるようになった時のことを思い出す。あれは多くの点で洗練されていなかったけど、今のWebAssemblyよりもよく機能してた。WebAssemblyのもう一つのキラー機能は、ネイティブなウェブ統合だったはず。JSエンジンの仕組みは、JSクラスのインターフェースを説明するIDLがあって、それを使ってC++の実装にバインドするコードを生成するんだ。おそらくそれをWebAssemblyにもバインドできると思う。クロスプラットフォーム、つまりCPUアーキテクチャを越えることはあまり重要じゃないと思うけど、「すべてで動く」って意味なら同意するよ。それに、WebAssemblyの隠れた秘密は、実はJSより速くないってこと。

WASMは単一のクロスプラットフォームコンパイルターゲットになり得る、それはCSの聖杯みたいなものだね。JVMは1995年から「こんにちは！」と言ってるよ。

WebAssemblyがFigmaの一部を速く動かすのに役立つと言われるのは、ちょっとがっかりだね。Figmaのようなツールは、実際にはそれがなければ成り立たなかったから。

*純粋な潜在能力 = すぐに壊れそう

またJavaとJVMの話か。

もっと言うと、JavaScriptにはすでに大きな標準ライブラリが用意されてるからね。整数を印刷したり、JSONやUnicodeテーブルを解析するためのコードを送る必要がないんだ。

それは状況によるね。高水準のGC言語をWasmGCにコンパイルするなら、JSより大きくなる理由はほとんどないと思うよ。

WebAssembly自体は、ストレージに関してそんなに非効率ではないよ。主にバイナリに伴う通常の膨張が原因だから。例えば、Goのバイナリは、ガベージコレクションを含む完全なランタイムを提供しなきゃいけない。サイズが最優先なら、Cを使って非常に小さなバイナリを生成することもできる。プロジェクト[0]は、ハードウェア、BIOS、DOS互換を含むx86アーキテクチャをエミュレートしていて、圧縮されていないWebAssemblyのサイズは78kB、転送サイズは24kBになる。 [0] https://github.com/s-macke/FSHistory

これは完全に間違ってる。• WebAssemblyはそんなに大きくないよ。基本的にはJavaScriptよりも一般的に小さいけど、JavaScriptはもっと標準ライブラリやランタイムがあるから、比較が不公平になるんだ。Rustみたいな言語を使えば、基本的なオーバーヘッドを10kBくらいに抑えるのは難しくないし、大きなプロジェクトでも100kB以下にできるよ。ただし、UnicodeやCLDRテーブルが必要になると話は別だけどね。トランスポート圧縮を考慮すれば、一般的にJavaScriptと同じようにスケールするよ。Goや.NETを使うと、確かに重いランタイムがあって、1MBか2MBになるかもしれないし、Unicode/CLDRテーブルの必要性にもよるけど、その場合はJSがバンドルサイズや起動時間で圧倒的に勝つだろうね。• JavaScriptはダウンロード中に実行できない。理論的には、投機的パースや限られた投機的実行が可能だけど、そんなことを真剣に試したエンジンはないと思う。WebAssemblyに関しては、ストリーミング中にコンパイルしてインスタンス化できるから、ダウンロードするよりも早い速度で進むことが多いよ。結果的に、同じ条件で比較すると、WebAssemblyはJavaScriptよりも起動がかなり早いんだ。

これに加えて、Godotランタイムの後、ゲームアセット自体もダウンロードしなきゃいけないから、DLCや物理メディアでは意味があったZIPみたいなアーカイブ形式を使うことが多いけど、単一のスプライトにアクセスするために何GBもの大きなダウンロードが必要になるんだ。ブラウザのDOMレンダリングは、リソースを表示される順に優先することがほとんどだからね。それに、WASMゲームランタイムは冗長な2Dや3Dスタック、音声、フォント、harfbuzzなどをバンドルする必要があるのに、ブラウザがすでに持っているネイティブなテキストレンダリング機能を提供していないんだ。全体的に開発者の体験を優先していて、ユーザーの体験が犠牲になってる。

問題じゃないよ。LTO最適化を実行して、全てのシンボルを削除すると、そこそこ複雑なGPUアクセラレーションレンダリングで圧縮2MBが得られるよ（minfx.ai）。

WebAssemblyの標準設計はバイナリサイズの最適化を考慮している。フォーマット自体はかなりコンパクト。でも、ネイティブコードをWasmに移植すると、既存の大きなライブラリがたくさん含まれてしまって、バイナリが大きくなる。ネイティブエコシステムはバイナリサイズの最適化に注意を払ってこなかったけど、JSエコシステムは最初からコードサイズに気を使っていた。

平均的なフロントエンドのロジックをWebAssemblyでコンパイルするのはあまり意味がないよ。なんで？ .NET Blazorや他のものはすでにそれをやってるじゃん。私にとっては、これがWASMの全体的な盛り上がりだった。JSを置き換えること。ブラウザでnodeやjavaを動かすことに興味はないし、なんでそんなことをしたいのか分からない。ブラウザの外でそれらを動かせるからね。もちろん、何か使い道があるならそれはいいし、WASMがそれを可能にしてくれるのは嬉しいけど、ほとんどの開発者がそれに関心を持つ理由が本当に分からない。私たちはウェブをブラウジングしたり、ウェブサイトを表示するためにブラウザを使ってるんだ。私にとってブラウザはウェブサイトを表示するためのもので、私はウェブサイトを作るけど、JSは大嫌い。だから、JSなしでウェブサイトを作れるのは素晴らしいことだよ。

Firefoxでbrowsercraftが動かない理由って何かあるの？結局Braveで開いてめっちゃ楽しんだよね、ハハハ。CheerpJがここまで進化してるのはすごいよね。5年か10年前にこのパフォーマンスがあったら、ウェブプラットフォームのいろんなことが違った展開になってたかも。

ReactはJavaScriptのデファクトスタンダードなUIフレームワークだけど、たくさんのWebAssemblyコンポーネントがあるんだ。これ、単純に間違ってると思うんだけど、例はある？

あなたはCLIツールとReactを混同してるんじゃない？

それは、ノートパソコンにLinuxをインストールするようなものだね。ノートパソコンを買うとき、結局Windowsのためにお金を払うことになるから。

それが本当に不足しているのは、多くの人がWebアプリを作るためのJS+HTML+CSSの完全な置き換えになると予測していた点だね。私は、そんなことがすぐに起こらないことを願ってる。YouTubeやSpotifyは理論的には今すぐにWasmを使ってキャンバスに描画できるけど（かなりの開発努力が必要だけど）、それだと現在DOMのおかげでできること（スクレイピングや広告ブロッカーなど）が難しくなったり不可能になったりする。

私は、Wasmを使ってウェブアプリ全体を構築するのが有望なアプローチだとは思わなかった。DOMとインタラクションできるようにするだけじゃダメなんだ。こういうDOMインタラクションやアプリケーションロジックを行うための適切な高水準言語も必要だよ。JSはその目的には悪くないし、WASMにコンパイルされるものでJSよりもずっと良いものを見つけるのはかなり大変だと思う（tsやsvelteみたいにね）。JSなしのウェブアプリケーションの唯一の現実的な道は、ブラウザのレンダリングパスを完全に放棄して、すべてをキャンバスに描画することだろうね。デスクトップ向けに設計されたUIツールキットを使う実験もあるけど、それもニッチな解決策に過ぎないと思うし、広く使われることはないだろうね。HTML/CSS/JSはUI開発の共通語になっていて、デスクトップアプリケーションにも浸透してきてる。なんでその流れが逆転すると思う？

記事はWasmをアプリが構築されるフレームワークのように評価しているみたいだけど、実際にはそうじゃなくて、CPUの最適化やブラウザ内のネイティブコードの再利用を可能にする直交的な技術なんだ。その期待に反して、まだベアメタルレベルのパフォーマンスやエネルギー効率には達していないけど、大成功を収めているよ。例えば、C++ライブラリに基づいたブラウザ内のオーディオタイムストレッチ [1]。もしこれがJSで実装されていたら、(a) 同じパフォーマンスや (b) ネイティブアプリへのソースコードの移植性を提供することは不可能だっただろうね。[1] https://bungee.parabolaresearch.com/change-audio-speed-pitch

ウェブアプリ構築について: 「何年も前から重要な欠けている部分とされているDOMバインディングの不足が続いているのか、他に何かもっと根本的な問題があるのかもしれない。もっと根本的には、すべてのフロントエンド開発者がほぼ同じJS言語（Typescriptも含む）を使っていて、すべてのモジュールがほぼ相互運用可能なんだ。WASMはコンパイルターゲットだから、開発者は異なる言語やツール、ライブラリを使っているかもしれない。どれかがクリティカルマスに達しているかもしれないけど、すべてを影に隠す巨大な存在（JS）がある。ウェブアプリの特定の部分は他の言語で書けるけど、ユーザーとの間にはまだJSのフロントエンドがあって、GUIは大きなアプリになることもある。最適化を目指したシステムに見えるね。バックエンドについては、RustやWASMをターゲットにできる他のコンパイル言語で書くなら、WASMにコンパイルする理由は何なの？ネイティブコードにコンパイルしないの？」

言語によっては、.wasmファイルを生成するのも一苦労で、関数のインポート/エクスポートのセットを作る必要がある。単に「-arch=wasm」ってわけにはいかない。 「WASMコンポーネントモデル」がこれを解決するんじゃない？私はRustでWASMアプリランナーをハッキングしていて、基本的には「コンポーネント」にコンパイルされた小さなアプリを読み込むもので、使ったり作ったりするのは結構簡単そうに思えるんだけど。

これに賛成。ツールは10年経ってもまだ整ってない。 - 既存のCコードベースをWebAssemblyにコンパイルするための主なツールチェーンはEmscripten。まだ技術デモの起源から抜け出せてなくて、コンパイラフラグやジャンクなポリフィルの巣窟になってる。全ての実装が半分完成した状態で少なくとも3つある。セマンティックバージョニングに従ってないから、ポイントリリースごとに壊れる変更が出やすい。 - 「モダン」なツールチェーンであるwasi-sdkは、もっとベアボーンな状態。使えるレベルにはなってきてるけど、プリコンパイルされたlibcとlibc++が-O3を使っているから、自分では使えない。Emscriptenはsysrootを再コンパイルしてキャッシュして、-Ozを使うように指示できるから。これでコードサイズが増えてしまう。すでにかなり大きいのに。 - LLVMは最適化されたWebAssemblyバイトコードを出力するのがまだまだ苦手。 - エンジンもWebAssemblyバイトコードを最適化された機械コードにコンパイルするのがあまり得意じゃない。 - デバッグ情報は、あなたが言ったように、完全に混乱してる。 - RustのWebAssemblyツールは今や生死の境をさまよってる。rustwasmのGitHub組織は、数年間の活動停止の後、2025年中頃に「日没」される予定。 - 2026年の今、JavaScriptからWebAssemblyモジュールをクロスプラットフォームでインポートする公式な方法はまだない。ブラウザにデプロイしてViteや生のESモジュールを使う場合、WebAssembly.instantiateStreaming(fetch(new URL('./foo.wasm', import.meta.url)))を使ってトップレベルのawaitを食べることができる。Viteはnew URL('...', import.meta.url)パターンを認識して、ビルド出力にアセットを含めるけど、他のバンドラー（例えばRollupやesbuild）はそうじゃない。Node上ではこれができない。なぜなら、fetchがローカルファイルには使えないから。ほとんどの人は諦めて、WebAssemblyバイナリを巨大なBase64文字列として埋め込むことになる。これでファイルサイズが33%増えて、圧縮率も大幅に下がる。 - マルチスレッドのWebAssemblyが欲しいなら、SharedArrayBufferにアクセスするためにCOOP/COEPヘッダーを設定する必要がある。GitHub Pagesはこれを許可していないけど、これは3番目に多くのアップボートを受けている機能リクエストだ。サービスワーカーをインストールするジャンクな回避策があるけど、その回避策がPWAとどう絡むかは全く不明。WebAssemblyが初めて出荷されてからの8年間で、ツールの状況が「技術デモ」を超えて進化していれば、もっと多くの人が使っていただろう。