探索メモ: wasm-gc の Wasm だけで、ブラウザーの tinymarkdown と el を動かす #

何を確かめたか #

MoonBit は JS にもビルドできるので、js ビルドならブラウザーでも Worker でも動くのは当たり前。それでもこのブログは、Wasm で動かすこと自体を目的にしている（Go から MoonBit への「ロマン」）。 なので、ここで確かめたのは **MoonBit が生成する JS を使わず、wasm-gc の .wasm 1 つで足りるか**だ。js ビルドはベースラインとして置いただけで、結論には使っていない。

問いと答えは次のとおり。どの問いも、確かめたのは wasm-gc ビルド（build/lib.wasm）。

結論 #

• **ブラウザーでは、wasm-gc の .wasm だけで足りる。** ページに要る JS は、Wasm をコンパイルし、render を呼び、戻り値を innerHTML に入れる十数行だけ。MoonBit が生成した JS は 1 行も読み込んでいない。
• **文字列はそのまま渡せる。** "use-js-builtin-string": true でビルドし、{ builtins: ["js-string"], importedStringConstants: "_" } を付けてコンパイルすれば、String を引数と戻り値にした関数をそのまま export すればよい。Workers 版のアダプター（wire 形式）は、workerd が builtins を使えないことへの回避策で、ブラウザーでは要らない。
• **Worker の中では、同じ .wasm はまだ動かない。** workerd は import した Wasm を builtins なしでコンパイルするので、文字列の import が解決されない（調査メモと同じ問題）。ブラウザー向けの .wasm とブログの Worker の .wasm（wire 形式の serve）は別のビルドになり、共有できるのは MoonBit のパッケージまで。

spike の形 #

moonbit/experiments/browser-render は、ほかの experiments と同じく独立したモジュールで、moon.work でブログのモジュール（../..）を読む。

• lib/lib.mbt: render(md : String) -> String。@tinymarkdown.parse で読み、picoel で要素を組み、@el.render_html で文字列にする。
• lib/moon.pkg: link 設定。wasm-gc は builtins を使う。js はベースライン。

options(
  link: {
    "js": { "exports": [ "render" ], "format": "esm" },
    "wasm-gc": { "exports": [ "render" ], "use-js-builtin-string": true },
  },
)

• index.html: 編集ページ。左の textarea に入力するたびに lib.wasm の render を呼び、右に表示する。読み込むのは lib.wasm だけ。
• baseline.html: index.html の lib.wasm を js ビルド（lib.mjs）に替えたもの。
• try.mjs: Node で lib.wasm を builtins なしとありでコンパイルして import を数え、render を呼ぶ。最後にベースラインと出力を比べる。
• worker.mjs、wrangler-worker.json: lib.wasm を Worker で import して呼ぶ（問い 4）。
• Makefile: build、try、serve、dev（Static Assets）、dev-worker、screenshot。

render はブログの render_blocks と render_inlines（moonbit/examples/blog/site/views.mbt）を小さく写したもの。見出しは h2 と h3 だけで、リンクの URL は検査しない。本文の文字はすべて @picoel.text を通るので、Markdown に書いた <b> はエスケープされ、出力を innerHTML に入れてよい。

問いごとの結果 #

const { instance } = await WebAssembly.instantiateStreaming(fetch("./build/lib.wasm"), {},
  { builtins: ["js-string"], importedStringConstants: "_" });
const { render } = instance.exports;
// ...
document.getElementById("out").innerHTML = render(src.value);

"GET / HTTP/1.1" 200
"GET /build/lib.wasm HTTP/1.1" 200
"GET /favicon.ico HTTP/1.1" 404

without builtins: 69 imports (63 from "_", 6 from "wasm:js-string")
with builtins: 0 imports
render: string: <article><section><h2>見出し</h2><p>本文 <code>code</code> と <a href="https://example.com">リンク</a> &lt;b&gt;esc&lt;/b&gt;</p><ul><li>a</li><li>b</li></ul></section></article>
baseline (js) gives the same HTML: true

{"imports":69,"error":"TypeError: WebAssembly.Instance(): Import #0 \"_\": module is not an object or function","baseline":"<article><section><h2>見出し</h2></section></article>"}

サイズ #

moon build --release の出力そのまま（wasm-opt なし）。

確かめられなかったこと #

• **Safari と Firefox。** 確かめたのは Chrome だけ。js-string builtins に対応していないブラウザーでは、問い 1 と 2 の答えが変わる。
• **入力しながらの更新。** headless の Chrome で見たのは、ページを開いたときの最初の描画だけ。入力のたびに呼ぶ update は同じ関数だが、キー入力を送って確かめてはいない。
• **workerd の互換性フラグ wasm_esm_integration_builtins**（workerd PR #7685、2026-10-12 マージ）。問い 4 の答えが変わるかもしれないが、今回の wrangler の workerd はマージより前のもので、試していない。
• **大きな文章での速さ。** 試したのは数行の Markdown だけ。

次の一歩 #

1. 編集ページを作るなら、ブログの site.css を当てて、見た目もブログに合わせる。 2. Worker の中でも同じ .wasm を使いたくなったら、wasm_esm_integration_builtins を試す。