You Might Not Need Hono

今の紹介でプレッシャーが2倍になりましたが始めていきます。「You Don’t Need Hono」というタイトルを考えていましたが、“燃える”予感がしたので「You Might Not Need Hono」にしようと思います。

現在高校1年生で、Honoにコントリビュートしてきました。最近はあまりできておらず、今はユーザー目線で使っています。最近だと、「未踏ジュニア」というクリエイター育成プログラム^[1]で、LLMを用いた初心者でも簡単に画像加工ができるソフトウェアを3人のチームで作っています。もちろん、これもHonoを使っています。

Honoは遅いかもしれない

Honoは遅いかもしれません。こんなことを言っていいのかとyusukebeさんに聞いたのですが、快諾してくれました。

Webフレームワークの評価は速さだけで決まるわけではなく、使い心地など様々な要素がありますが、まずは速さに注目してみます。

クイズです。次のうち最も速いWebフレームワークは何でしょう？ Elysia on Bun、Hono on Bun、Fastify on Node、Express on Bun…どれだと思いますか？

大体、ElysiaとHonoに分かれていますね。正解はElysiaです。

ただ、自分はこんな話をしたいわけではなく、問題は「型の速さ」なんです。

問題は「型」の速さ

クイズです。次のうちRPCの型チェックが最も速いのは何でしょう？ 選択肢はElysia、Hono、oRPC、tRPCです。

これについては自分でベンチマークしました。正解は、oRPCが一番速く、Honoが一番遅いという結果が得られました。

これはクライアント側の型チェック時間を計測したものですが、HonoのRPCは遅いという結果になりました。遅いと何が問題かというと、VS Code上でのRPCの型補完が遅くなり、UXに影響します。

対処法として事前に型ファイルをビルドしておく手もありますが、それにも時間がかかり、HonoのTypeScript関連の処理がとても遅くなってしまっているため、Honoを使わないでください。

（会場の笑い声）

どうしてこんなことになっているのか、中身を見ていきます。

Honoのsrc/types.tsという、yusukebeさんが頑張って書いていらっしゃる、黒魔術的なファイルがあります。このファイルはTypeScript上でURLをパースしたりといったことをやっているので、とても複雑になっています。約4,000行あるファイルのほとんどがTypeScriptの型パズルのようなコードで、こういった理由から遅くなっています。

HonoはNot Easyかもしれない

“Simple vs Easy”という文脈があります。

この画像はHonoとElysiaの比較です^[2]。見てもらうと分かる通り、Elysiaはテキストを返すときにレスポンスオブジェクトを介さず直接値を返しています。“Simple”と“Easy”では、Elysiaに“Easy”側の軍配が上がると思います。

HonoはWeb標準を露出しているので、レスポンスを作成することに重点を置いています。それに対し、ElysiaはユーザーがAPIを簡単に扱えるようにしているので、初心者から見ると一見Elysiaの方が使いやすそうになっています。

続いてバリデーターの話です。これも同様に、HonoのバリデーターよりもElysiaのバリデーターの方が“Easy”寄りになっていて、コードがとても見やすくなるので、HonoはやめてElysiaにしましょう。

Honoは袋小路かもしれない

「Honoは袋小路かもしれない」という話です。あるデータをお見せします。Pull Requestのカウント推移なのですが、2023年のピークを過ぎて、今はだんだんと減少傾向にあります。

また、Issueも同様に緩やかに減少しています。さらに、Issueのラベルを分析してみると「bug」がとても減って、代わりにyusukebeさんが「バグではない」と断定した「not bug」が増えています。

新しい機能の追加がだんだん減っている一方で、triage（バグかもしれない）とnot bug（絶対バグではない）が増えており、開発の停滞寸前なんじゃないかと心配しているので、Honoは使うのはやめましょう。

Honoがやっていること

Honoがやっていることは、「コア」と「Helpers/Middleware」という2つの文脈に分けられると思っています。

コアはルーターそのもので、Helpers/MiddlewareはWebSocketやJSXなどが挙げられますが、これが主な開発の停滞の原因になってしまっていると思うんです。

HonoのコアはRequestオブジェクトを受け取り、高速にミドルウェアにルーティングしレスポンスを返す、という極めて単純な機能に徹しています。Helpers/Middlewareは、WebSocket、Basic Auth、JSXなどを提供しています。Honoのコアは、速くしたり小さくしたりというのをやるだけなので、開発の余地が少なくなっているのが停滞の原因として挙げられると思います。

ちなみに、これはHonoのコミット履歴からどの部分にコミットが行われたかを表したグラフです。

これを見るとコアのコントリビュートはとても減少していて、Helpers/Middlewareは一時多くなっていたのですが、現在はそれすらもだんだん減少しているという、まさに袋小路な状態です。

Honoは、「次どうすればいいのか」というステージに立っているのではないかと思います。

Honoは必要ないかもしれない

Honoは必要ない...かもしれないです。

「WinterCG（Community Group）」をご存知ですか？ サーバーサイドWebの標準化を目的としているコミュニティグループで、Deno、Cloudflare、Nodeなどが参加しています。

現在は「WinterTC（Technical Committee）」に活動が引き継がれました。この変更による大きな違いは、標準を策定する権限が得られたことです。WinterCGは議論を行うことが主でしたが、WinterTCはJavaScriptの標準を策定している機関と同じように、標準を策定・公開できるようになりました。^[3]

これが何に影響するかというと、WinterTCになることによって標準の策定スピードが速くなり、様々なランタイム間の互換性が向上することが期待されます。

昨年、僕が発表した時に「Honoはラッパーだ」と言いました。

Honoは統合されたコードの上でラッパーとして動いていて、異なるランタイム間の差を吸収する役割を果たしていると説明しました。ですが、先ほどのWinterTCが発展するとHonoの役割がなくなるかもしれず、Honoは必要なくなるかもしれません。

フルスタックSSR, SPA, MPA/SSG

Honoは必要ないかもしれません。

フルスタックSSRを使いたい方は、TanStack Start、Next.js、React Routerなどを使ってみましょう。これらは統合されたコードを提供しています。

これは、例えばServer ActionsやServer Functionsがフレームワークに統合されていて、HonoなどのRPCライブラリを使わなくても通信ができるということです。Honoを使うのをやめて、これらを使いましょう。

スライド右端から炎のイラストが出てくる

……なんか燃えてきましたが無視しましょう。

SPAの場合は、oRPCやtRPCを使った方がいいのではないでしょうか。先ほど見せた通り、型の速度がとても速くなります。

MPA/SSGについては、Astroなどの方が適していると思っています。専用に最適化されているので、わざわざJSXを書かなくてもレイアウトをよしなにやってくれます。TanStack Start、Next.js、React Router、oRPC、tRPC、AstroをHonoの代わりとして使いましょう。

さらにスライド上の炎イラストが大きくなり、会場の笑い声も大きくなる。

（スライド上の炎を見て）燃えてきましたね。

これではまずいので、逆に言えばHonoは必要かもしれないと解釈できます。

Honoは必要かもしれない

Honoでも良くないですか？

これは先日目にした記事なのですが、catnoseさんが作った翻訳サイト「Nani!?」に関する話です^[4]。Next.jsを採用している場合でも、部分的にServer ActionsやServer Functionsを使わずにHonoのRPCを使っているという内容です。

「Server Actionsを使ったりもしていますが、Server Actionsはオーバーヘッドがやや大きいため...」と書かれていました。このような部分にHonoを組み込むことで、うまく機能するのではないかと期待しています。

理由として挙げられるのが、先ほど話したServer Actionsのオーバーヘッドとマルチプラットフォームです。Server ActionsやtRPCと比較してみましょう。

RESTは共通言語です。TypeScript専用RPCの場合、モバイル対応が難しかったりすることが挙げられます。これはなぜ起こるかというと、oRPCやtRPCというのはTypeScriptやそのWebフレームワークにロックインしているため、TypeScript以外を書こうとするととても辛くなってくるんです。

でも、HonoならRESTという長い間使われてきたものの上に立っているので、TypeScript以外をクライアントとして書こうとする場合も問題ありません。

Honoであれば、TypeScriptによる優れたUXを手に入れることができます。モバイルや他のプラットフォームでもクライアントが書けて、外部に露出するAPIも書くことができます。例えば、SDKを公開する時、分散型SNSを構築する時、LLMがAPIを叩く時、特定のランタイムに依存したガラパゴスな形態を使っているとアクセスできないため、そういう側面でもHonoは役に立っているのではないかと思います。

他のプラットフォームで使用できる柔軟性を持っているのがHonoです。

Honoはプロトコルをつなぐ

また、Honoはプロトコルをつなぐ存在としても有効だと考えています。例えば、 @hono/mcp, @hono/orpc, @hono/trpcをHonoの下に置くことにより、以下のようにそれぞれのサーバーと繋げ、ルーティングできることが分かります。

• /mcp → Remote MCP Server
• /orpc → oRPC Server
• /trpc → tRPC Server

単体で使うことも可能なのですが、Honoがあれば様々なアプリケーションを統合するという橋渡しの役割になります。

また、Auth実装時も役に立ちます。例えばoRPCはAuth実装できますが、それ単体で実装するより、Honoのエコシステムを使って実装した方がとても使いやすく、楽になることが予想されます。

HonoはWeb標準につなぐためのアダプター

HonoはWeb標準につなぐためのアダプターです。

MCPはWeb標準なトランスポートがなかったと思いますが、@hono/mcpを作ることでHono側がWeb標準なトランスポートを提供してくれます。それにより、「Web標準」と「Web標準ではない」ものをつなぐアダプターとしてHonoは機能すると思います。

先ほど言ったように、様々なプロトコルをルーティングすることができるHonoは、 「フレームワークのフレームワーク」 ということができると思います。

例えば、AIフレームワーク「Mastra」は内部でHonoを使っています。フレームワーク側がHonoを採用することで、高速なルーティングを手に入れ、さらにHonoのエコシステムを利用できるようになります。

フレームワーク開発者が、フレームワークであるHonoを使うという点においても、Honoは必要なのかもしれません。

また、WinterTCになった今でも、サーバーサイドの標準策定にはまだまだ時間がかかると思います。WinterCGのFetch関連の仕様策定などが進んではいますが、かなり進捗が遅く、まだどれも未完成な状態です。これが完成するのはまだまだ先なので、先ほど言った通りHonoがアダプターとしての役割を果たすと思っています。その点でもHonoは必要だと思っています。

“Simple vs Easy”

“Simple vs Easy”の文脈を先ほど話しましたが、“Simple”を選びませんか？

「Simpleを選ばないか」という問いかけに対して会場では拍手が起こった

Honoは、ミドルウェアに分配するという極めてシンプルなルーティングの役割を果たしています。これがうまく機能として果たしているのがHonoです。

例えば、最初はルーターだけ置いておいて、後から必要になった時にミドルウェアを付け足すというシステムは、Cloudflare Workersのアップロードの上限が小さいことから生まれたものだと思っています。そういうミニマルな設計思想は、“Easy”ではないけど“Simple”だということが分かります。最初はcomplex（複雑）なのですが、後から楽になることが分かります。

Honoを使おう

Honoを使いましょう。

シンプルなシステムと豊富なエコシステムがあります。シンプルなシステムというのは、Honoは「コア」と「ミドルウェア」というシンプルな構造で成り立っている点です。

豊富なエコシステムというのは、この会場にこれだけの皆さんがいるように、Honoは急成長しているので、エコシステムやnpmを見るととても増加しており、環境が整っているというのがHonoの良いところだと思います。

また、先ほども話した通り、RESTという巨人の肩の上に立っているので、Honoを使っていることによって既存のクライアントなどとの相性が良くなることが考えられます。

そして、Web標準でどこでも動く。WinterTCになったとしても、Web標準のアダプターとしてHonoは機能すると思うのでここが重要になっています。

ちなみに夏休みに実験したのですが、「Moddable」というマイコン上でJavaScriptを動かすランタイムがあります。なんと、ESP32というマイコン上でHonoが動きました。これがWeb標準のいいところだと思っています。

honojs/middlewareというリポジトリには、Third-party Middlewareと言われる、いろんな人がコントリビュートして、いろんなライブラリに依存しているものがあります。そちらの開発は結構活発で、対してコアは安定フェーズに入っています。

Third-party Middlewareやコミュニティは発展中なので、コア以外の部分に重点を置くことが、今後のHonoの開発に大切になってくるのではないでしょうか。

Honoを使いましょう。以上です。ありがとうございます。

発表スライド