Hono vs Express 比較

Web Standardsをベースに構築された、マルチランタイム対応の移植可能なマイクロフレームワーク

VS
Express

17年の実績を持つ、Node.jsの事実上の標準ミニマリストWebフレームワーク

14 分で読了Backend

クイック結論

状況に応じて判断してください:Cloudflare Workers、Bun、あるいはマルチランタイムの柔軟性を目指す新規サービスにはHonoが理にかなっています — Web Standardsを基盤としRPCモードが型安全性をもたらします。しかし、passportやmulterのような成熟したExpressミドルウェアに深く依存する稼働中のNode.jsコードベースを、移植性のためだけに書き直すことは、割に合うことはほとんどありません。GitHubで今なお2倍大きいコミュニティを持つExpressに留まる方が、ほとんどのチームにとってリスクが低いでしょう。

HonoExpress
結論をすべて読む

スコア比較

グラフを読み込み中...

詳細スコア

詳細スコア: Hono Express — カテゴリー別10点満点のスコア
カテゴリーHonoExpress
パフォーマンス
8/10
7/10
学習のしやすさ
7/10
9/10
エコシステム
6/10
10/10
コミュニティ
6/10
10/10
求人市場
5/10
9/10
将来性
9/10
6/10

長所と短所

Hono

長所

  • Web Standards の Request/Response をベースにしており、Cloudflare Workers、Bun、Deno、Node.js(アダプター経由)、AWS Lambda を含む公式マルチランタイムサポートを提供
  • `hono/tiny` は14KB未満・依存ゼロ — エッジ/サーバーレスのコールドスタートに有利
  • RPCモード(`hc<AppType>`)によりクライアント-サーバー間でエンドツーエンドのTypeScript型安全性を実現し、別途コード生成は不要
  • RFC 10008のHTTP QUERYメソッドを`app.query()`でファーストクラスサポート
  • 活発な開発ペース:60日間で4回のパッチリリース+迅速なセキュリティパッチ
  • 単一のコードベースでエッジと従来型サーバーの間を行き来できる
  • MITライセンス、honojs組織のもとで透明性のある開発

短所

  • 公式ミドルウェアカタログはExpressより狭い — passport/multer相当の公式パッケージが存在しない
  • 2021年発祥で、Expressの17年に比べるとプロダクション実績が短い
  • Node.jsでは`hono/node-server`アダプターが必須 — ネイティブのNode req/res APIに直接は触れない
  • 405 対応はオプトイン — `hono/method-not-allowed`(v4.13.0)を手動で組み込む必要があり、コア API 提案(PR #4637)は現在も未マージ
  • エンタープライズ向けのauth/セッション層はコミュニティパッケージへの依存がExpressより大きい

最適な用途

Cloudflare Workers/Fastly/Deno/Bunをターゲットとする新規サービスマルチランタイムの柔軟性を求めるマイクロサービスエンドツーエンドで型安全なTypeScript API(RPCモード)コールドスタートが重要なエッジ関数小〜中規模のグリーンフィールドなバックエンドプロジェクト

Express

長所

  • 2009年以来プロダクションで実証された成熟度と安定性
  • 豊富な公式+サードパーティ製ミドルウェアカタログ(body-parser、cors、multer、express-session、passport、helmet、morgan)
  • GitHubで69,467スター(2026-09-24) — Honoの約2倍で、最大のNode.jsフレームワークコミュニティ
  • 充実した学習リソース、膨大な量のStack Overflow/チュートリアル
  • Express 5.xではasyncルートハンドラーでのエラーが自動的にキャッチされる(自動的にnext(err)に渡る)
  • シンプルでミニマルなAPI — 学習曲線が緩やか

短所

  • Web StandardsのRequest/Responseにネイティブ対応していない — Cloudflare Workersでは`nodejs_compat`ブリッジ経由でのみ動作
  • パッケージにTypeScript型定義が同梱されていない — v4.22.3とv5.2.1は`types`フィールドを持たず、型は別パッケージの`@types/express`(DefinitelyTyped)から提供される
  • 公式のRPC/型生成ツールが存在しない — クライアント-サーバー間の型共有は手動またはサードパーティが必要
  • 4.x系の最新版はv4.22.3(2026年9月14日)、5.x系はv5.2.1(2025年12月1日) — イテレーション速度はHonoより遅い
  • `hono/tiny`と比較してバンドルサイズとコールドスタートのオーバーヘッドが大きい

最適な用途

Passport、multerなどの成熟したミドルウェアに依存する既存プロジェクト従来型のNode.jsサーバー/VM/コンテナデプロイ大規模チーム+充実したドキュメント/チュートリアルを必要とするエンタープライズプロジェクト迅速なプロトタイピング、シンプルなREST APINode.js専用マイクロサービス(エッジをターゲットとしない)

コード比較

Hono
// Hono - Node.jsでのRPCモード型安全API
import { Hono } from 'hono'
import { serve } from '@hono/node-server'
import { hc } from 'hono/client'

const app = new Hono()

const route = app
  .get('/users/:id', (c) => {
    const id = c.req.param('id')
    return c.json({ id, name: 'Ayşe' })
  })
  .post('/users', async (c) => {
    const body = await c.req.json<{ name: string }>()
    return c.json({ id: '42', name: body.name }, 201)
  })
  .query('/users/:id', (c) => {
    // RFC 10008 HTTP QUERY - ボディ付きの安全な読み取り
    return c.text('QUERY /users/:id')
  })

serve({ fetch: app.fetch, port: 3000 })

// クライアント側での型安全な呼び出し
export type AppType = typeof route
const client = hc<AppType>('http://localhost:3000')
const res = await client.users[':id'].$get({ param: { id: '42' } })
Express
// Express 5 - asyncルートハンドラー + エラーハンドリング
import express from 'express'

const app = express()
app.use(express.json())

app.get('/users/:id', async (req, res) => {
  const id = req.params.id
  res.json({ id, name: 'Ayşe' })
})

app.post('/users', async (req, res) => {
  const { name } = req.body
  if (!name) {
    res.status(400).json({ error: 'name は必須です' })
    return
  }
  res.status(201).json({ id: '42', name })
})

// Express 5: asyncハンドラーでスローされたエラーは自動的にnext(err)に渡る
app.use((err, req, res, next) => {
  res.status(500).json({ error: err.message })
})

app.listen(3000, () => console.log('Express がポート 3000 で起動'))

結論

状況に応じて判断してください:Cloudflare Workers、Bun、あるいはマルチランタイムの柔軟性を目指す新規サービスにはHonoが理にかなっています — Web Standardsを基盤としRPCモードが型安全性をもたらします。しかし、passportやmulterのような成熟したExpressミドルウェアに深く依存する稼働中のNode.jsコードベースを、移植性のためだけに書き直すことは、割に合うことはほとんどありません。GitHubで今なお2倍大きいコミュニティを持つExpressに留まる方が、ほとんどのチームにとってリスクが低いでしょう。

無料相談を受ける
FAQ

よくある質問

通常は不要です — passport、multer、エンタープライズ層などExpressのミドルウェアエコシステムに深く依存している場合、移行コストは高く、割に合うことはほとんどありません。新規サービスを構築していてエッジ/マルチランタイムをターゲットにしているならHonoは理にかなった選択です。稼働中のExpress APIを移植性だけのために書き直すことは、多くの場合そのリスクに見合いません。

関連ブログ記事

すべての記事を見る
すべての比較