ElysiaはなぜEncoreを上回る速度を目指したのか

速さだけではなく、型のつながりを作る

Elysiaは「Bunで速いWeb framework」という一言から始まる。

しかし現在の公式サイトが押し出すのは、runtime performanceだけではない。

TypeScriptの型をrouteからclientまでつなぎ、開発者がAPIの境界で迷わないことだ。出典

SaltyAomが選んだ出発点

創作者SaltyAomは、ElysiaをBun上のOSSとして育ててきた。

GitHub Sponsorsのプロフィールでも、自身をElysiaのmaintainerと説明し、スポンサーの支援でOSSを継続する姿勢を示している。

I will try to keep on working on my Open Source as much as I can namely, Elysia, and Niku.

ここでの出発点は、企業向けの巨大なplatformを先に作ることではない。

個人や小さなチームが、BunとTypeScriptでbackendを組み立てるときの摩擦を減らすことだった。

速さを機能ではなく構造にする

初期からElysiaは、schema validationや型推論を単なる補助機能として扱わなかった。

Sucroseという静的コード解析を使い、runtimeに必要な処理を先回りして生成する方向へ進んだ。

Elysia 1.0の公式記事では、type inferenceの改善、Eden Treaty 2、startup timeの改善をまとめて説明している。出典

この選択には苦労もある。

高性能な最適化は、内部実装を複雑にし、Bunやvalidatorとの結合を強める。

だからこそ、公式blogではversionごとにbreaking changeやbenchmark条件を説明し、速さの数字だけでなく仕組みを見せる必要があった。

Encoreとの比較で問い直した

転機はEncoreとのbenchmark比較だった。

公式記事によれば、2025年11月14日の検証で、Elysiaは同じbenchmark上でEncoreの2倍の速度になった。出典

ただし、これは単純な勝利宣言ではない。

Elysia側はproduction compile、Bunのnative routing、data normalizationの改善など、条件を見直した過程を公開した。

benchmarkを再現できる形にし、自分たちの以前の実装も検証対象にした点が重要だった。

AOTへ、そして次の現在地へ

2026年7月、Elysiaは2 betaでアーキテクチャを大きく書き直す方針を示した。

AOT compilationを含め、performance・memory usage・startup time・bundle sizeを改めて見直すためだ。出典

Elysiaの道のりは、速いrouterを一度出して終わる話ではない。

Bunの変化、TypeScriptの型システム、OSS communityの期待に合わせて、速さを生む境界そのものを組み替えてきた。

SaltyAomのスポンサー向け説明にある「OSSをできる限り続ける」という姿勢は、短期のbenchmarkより長い保守を重視する現在地を表している。出典

Bunで高速なbackendを作りたいTypeScript開発者に、runtime performanceだけでなく型安全なAPI開発体験を提供する。

Elysiaはroute・schema・handlerの型をつなぎ、Edenでclient側にも型を伝えるため、API境界の手書き同期を減らせる。

公式blogはSucroseやAOT compilationを速度と開発体験の両面の基盤として説明している。出典

一方で、Bunを前提にした最適化はNode.js中心の既存チームには導入判断を要求する。

Bun採用を許容でき、型の一貫性と低いoverheadを重視するチームほどPMFが強いと考えられる。

Sucrose、Eden、TypeBox/Standard Schema連携が作る一体型のdeveloper experienceがmoatになる。

単なるrouterなら代替できても、runtime最適化とend-to-end type safetyを同時に磨いた蓄積は短期で複製しにくい。出典

弱〜中。

利用者が増えるほどplugin・example・issue解決の知識は蓄積するが、APIを使う顧客同士が直接つながるnetwork effectではない。

GitHub starsやsponsorsはcommunityの健全性を示す補助指標に留まる。出典

Bunを採用できるTypeScriptチーム、型安全なAPIを小さなboilerplateで作りたい開発者、低latencyのbackendを運用するOSS志向のチーム。

Node.js専用middlewareに強く依存する組織や、managed supportを必須とする大企業には慎重な比較が必要。

第一に、Bunのnative runtimeを活かしつつWeb Standards互換のAPIを保ったこと。

第二に、SucroseのJIT静的解析やAOT compilationでschema・routing・型推論のoverheadを削ったこと。出典

第三に、公式blogとGitHubでbenchmarkの条件・コードを公開し、性能主張を追試可能にしたこと。

これはOSS frameworkの採用時に重要な信頼材料になる。

最大のリスクはBun依存とecosystemの相対的な狭さだ。

Node.js互換性や既存middlewareとの検証コストは、Express系からの移行障壁になり得る。

公式サイト自身もbenchmarkだけでframeworkを選ぶべきではなく、DX・ecosystem・communityも見るべきだと述べている。出典

また、性能比較はruntime・compile条件・payloadに左右される。

公式benchmarkは有力な材料だが、各社の本番ワークロードへそのまま一般化できない。

GitHubでOSSを配布し、公式docsとversioned blogで性能・型安全性の差分を伝えるdeveloper-ledな成長だ。

Bunの採用拡大が流入を作り、EdenやOpenAPIが実運用の導入理由を補強する。出典

トレードオフは、広いNode.js互換性よりBunでの体験を優先すること。

Encoreとのbenchmark比較も注目を集めるが、公式blogはbenchmark以外にDXやecosystemを見る必要があると明記している。出典

主要チャネル: github, blog, community, sponsors, social

性能を主張するだけでなく、compiler・schema・routingという遅くなりやすい境界を特定し、開発者が感じる待ち時間まで改善した点が示唆的だ。

Elysia 1.3はvalidation安全性を保ちながらExact Mirrorで処理を高速化したと説明する。出典

ただし、benchmarkは採用理由の一部に過ぎない。

runtime・ecosystem・移行コストを同じ表に載せて初めて、数字を意思決定へ翻訳できる。

日本ではBunやTypeScriptの新しいruntimeを試せるスタートアップ・個人開発から導入し、既存Node.js資産を一気に置き換えない段階移行が現実的だ。

公式docsを日本語化するだけでなく、Cloudflare WorkersなどWeb Standards系の実装例、observability、障害対応の知見を日本語で蓄積するとcommunityの入口を広げられる。