探索メモ: 素直に Workers で書くと、どれだけ楽か #

何を確かめたか #

結論 #

• **楽になった。** JS と Wasm の境界にまつわる仕事（アダプター、ABI、wasm-opt、埋め込みのシェルスクリプト、Makefile）が丸ごと要らなくなった。Vite の構成では、記事を埋め込むスクリプトも要らない。Workers との糊は、vite.config.ts（16 行）、wrangler.jsonc（14 行）、import.meta.glob で記事と文書を読む sources.ts（25 行）だけ。
• **自分で書く必要が残ったのは、ブログ固有のところだけ。** Markdown の解析（独自の小さな方言なので、既存のライブラリでは置き換えにくい）、記事の検査、リンクの解決、ページの見た目。
• **大きさは Wasm 版より小さくはないが、困るほどでもない。** 大きさのほとんどは埋め込んだ文章で、コードは数十 KB。
• **起動時間は MoonBit 版より長いが、それは解析を起動時にしているから。** Startup Time の数字だけを小さくするなら、解析を最初のリクエストに回せばよい。ただしそうすると、新しい isolate に当たったリクエストの CPU 時間が 18〜43 ms に増える。起動時に済ませておくほうが、リクエストの CPU 時間は小さい。

Go 版との差 #

ts 版と Go 版（go run ./examples/blog）を、どちらも同じ BASE_URL で起動した。MoonBit 版の make compare で比べると、6 パスのうち 5 パスで本文が違った。違いはどれも HTML の書き方で、意味は同じ。

本文の違いをそろえてから（Content-Type は比べずに）、トップ、/docs/、そこからリンクされている全記事と全文書、.md のソース、404 のページを比べた（30 パス）。違ったのは /docs のリダイレクトだけで、ステータス（307）と行き先は同じ。Go の http.Redirect は短い HTML の本文を付けるが、Hono の c.redirect は付けない。wrangler だけの版でも、同じ比べ方で同じ結果だった。

ほかに、次の違いがある。

• Go 版は //posts/hello のような重なったスラッシュを詰めてリダイレクトするが、ts 版は 404 を返す。.. を含むパスは workerd が先に正規化するので、Worker まで届かない（MoonBit の調査メモにもある挙動）。
• Go 版にある /favicon.svg という固定のパスがない。ページはハッシュ付きの URL を指すので表示は変わらないが、/favicon.svg を直接取ると 404 になる。
• site.css は Vite が minify するので、2,286 B が 722 B になった。

コードの量 #

テストを除いた行数。Go 版は -watch（livereload.go）と main.go を除いた、ページを返すところだけ。

ts 版のアプリが短いのは、ページを TSX でそのまま書けるので、picoel の関数を呼んで木を組み立てる分がないため。たとえば記事の一覧は、HTML の形がそのまま見える。

<article>
  <hgroup>
    <h2><a href={postPath(p)}><Inlines text={p.title} link={noLinks} /></a></h2>
    <p><time datetime={p.date}>{p.date}</time></p>
  </hgroup>
</article>

書かずに済んだもの #

• **ルーティング**：app.get("/posts/:slug", ...)、app.get("/docs/:path{.+}", ...) だけ。GET のルートは HEAD にも答え、ほかのメソッドは app.notFound の 404 になる。Go 版は TinyGo の net/http に合わせて手で振り分け、MoonBit 版は http の Router を自分で書いた。
• **共通のレイアウト**：jsxRenderer に一度書き、各ページは c.render(本文, メタ情報) で返す。メタ情報の型は ContextRenderer を拡張して付けた。
• **エスケープ**：hono/jsx が文字列をすべてエスケープするので、記事の中の <b> はテキストのまま出る（テストで確かめている）。
• **記事と文書の埋め込み**：import.meta.glob(["…/TODO.md", "…/docs/**/*.md"], { query: "?raw", eager: true }) で、ファイルの一覧と中身がそのまま手に入る。Go 版の go generate によるコピー、MoonBit 版の embed.sh に当たるものがない。
• **静的ファイル**：site.css と favicon.svg は ?url で import するだけで、Vite がハッシュ付きの名前で dist/client/assets/ に出し、Workers の Static Assets になる。Worker が動く前に返されるので、ルートも要らない。長いキャッシュは public/_headers に書くだけで付いた。Go 版の site.css のハッシュの計算もない。
• **JS と Wasm の受け渡し**：なし。BASE_URL は c.env から読むだけ。
• **開発サーバー**：vite が Worker を workerd で動かす。記事や TODO.md を書き換えると、次のリクエストから反映される（確かめた）。
• **ビルドとデプロイ**：vite build が Worker と静的ファイルを dist/ に出し、デプロイ用の wrangler.json も書く。wrangler deploy はそれを自動で見つける。wasm-opt も Makefile も要らない。
• **テスト**：Hono のガイドどおり app.request(path, init, env) で呼ぶだけ。vitest は Vite の上で動くので、import.meta.glob と ?url もテストの中でそのまま動く。Workers のランタイムを立ち上げずに、29 件のアプリのテストが 0.2 秒ほどで終わる。

素直にいかなかったところ #

• **Vite は、既定ではプロジェクトの外のファイルを読まない。** 記事と文書と site.css はリポジトリのルートにあるので、server.fs.allow にリポジトリのルートを足した。
• **小さい favicon は data: URL になる。** Vite は 4 KB 未満のファイルをページに埋め込むので、build.assetsInlineLimit: 0 にした。
• **.tsx は Node で動かない。** Node 24 の型の除去は JSX を変換しないので、TSX を読み込むテストは node --test では走らない。Vite の構成では vitest を使うのが自然なので、困らない。tsconfig.json は allowImportingTsExtensions と erasableSyntaxOnly を有効にしたままにして、.ts は Node でも動く形にしている。
• **npm が esbuild と workerd の postinstall を止める。** npm install で警告が出るが、プラットフォームごとのバイナリは optional dependency として入るので、そのまま動いた。

wrangler だけの版（95bf1d5）では、ほかにも次のことがあった。どれも Vite の構成で消えた。

• 記事と文書を JSON に書き出すスクリプト（31 行）を、wrangler の build.command で走らせていた。build.command は wrangler を起動したディレクトリで走る（設定ファイルのディレクトリではない）。
• build.watch_dir はディレクトリしか指定できず、リポジトリのルートを見るとスクリプトの出力も見てしまうので、TODO.md の変更を拾えなかった。
• esbuild が JSON の中の日本語を \uXXXX に書き換えるので、273 KB の JSON がバンドルの中では 442 KB に膨らんだ。Vite（Rolldown）の出力は UTF-8 のままで、\uXXXX は 0 件。

大きさ #

記事 8 本と文書 14 本（TODO.md、docs/**/*.md）を埋め込んだ大きさ。

wrangler だけの版で esbuild の metafile を見ると、Hono（hono/jsx を含む）が 48 KB、アプリと tinymarkdown が 12 KB ほど。埋め込んだ文章を除いたコードは、minify 後で 59,814 B、gzip 後 23,102 B だった。

比べる相手として、MoonBit 版の記録（調査メモ）は 237.41 KiB（gzip 後 78.50 KiB）で、これは記事 4 本と文書 7 本のとき。埋め込んだ文章の量が違うので、そのままは比べられない。

デプロイ #

npm run deploy（vite build と wrangler deploy）で、blog-ts として https://blog-ts.podhmo.workers.dev にデプロイした。手順はこれだけで、ほかに準備は要らなかった。全ページが返り、/assets/ の静的ファイルには _headers の Cache-Control が付いた。

デプロイの直後に一度だけ、/docs/TODO.md が text/plain の 404 になった。数秒後には 200 に戻り、続けて 10 回取っても 200 だった。新しい版が行き渡る前のリクエストだったと考えている。

速さ #

wrangler だけの版を wrangler dev で動かし、curl で 20 回送った往復時間の中央値。参考に、ネイティブで動く Go 版（go run）も並べた。

ts 版は、記事と文書を isolate の起動時に一度だけ解析し、リクエストごとには TSX を文字列にするだけ。大きいページでも / との差は 0.5 ms 以内で、Workers の無料プランの CPU 時間の上限（10 ms）に比べて十分小さい。

この先に考えること #

• MoonBit 版も、記事と文書の解析を起動時に移すと、リクエストの CPU 時間が小さくなるかを確かめる。
• 文章を Worker のバンドルから外すなら、Static Assets に置いて env.ASSETS.fetch で読む。ts 版はハンドラーが非同期なので、MoonBit 版の TODO にある「文章を Wasm にどう渡すか」に当たる問題は起きない。