Elysia vs Hono vs Express: Bun-Native Backend Frameworks

Bun is no longer the scrappy upstart. As of mid-2029, it has crossed the threshold from "interesting experiment" to "legitimate production runtime." Bun 1.2+ ships native S3 support, a built-in Postgres client, and sub-10ms cold starts that make serverless viable without the usual cold-start tax. Once the runtime is fast enough, the framework you put on top of it becomes the critical decision.

Three frameworks dominate the Bun conversation right now. Elysia was built from scratch for Bun, optimized at every layer to squeeze maximum performance from the runtime. Hono was built for the Web Standards era, running on Bun, Cloudflare Workers, Deno, Vercel Edge, and Node.js with zero adapter friction. Express is the legacy incumbent that, thanks to Bun's Node.js compatibility layer, still works on Bun without any code changes.

Each represents a distinct philosophy. Elysia bets that deep runtime integration and end-to-end type safety are worth the lock-in. Hono bets that portability and Web Standards compliance matter more than raw speed. Express bets that the largest ecosystem and lowest learning curve trump everything else. All three run on Bun. None of them are wrong.

This guide breaks down the real tradeoffs: benchmarks with context, TypeScript DX in practice, middleware maturity, validation and OpenAPI generation, deployment flexibility, and the migration paths that actually work. If you are picking a framework for a new Bun project or considering a move from Express, this is the comparison you need.

Before diving into benchmarks and features, it helps to understand what each framework is actually optimizing for. The design philosophy shapes every downstream decision.

Elysia: Bun-Native, Type-Safe, Opinionated

Elysia was created by SaltyAom specifically for Bun. It uses Bun's native APIs at every opportunity: Bun.serve for HTTP handling, Bun's FFI for performance-critical paths, and Bun's built-in features for file serving and WebSockets. Elysia's signature feature is end-to-end type safety through its "Eden Treaty" client, which generates a fully typed API client directly from your route definitions. You define a route with validation on the server, and the client gets autocomplete and compile-time checking for every parameter, header, and response shape. No codegen step, no schema export. It just works through TypeScript inference.

The trade-off is clear: Elysia only runs on Bun. If you ever need to deploy to Cloudflare Workers, Deno, or plain Node.js, you are rewriting your server. Elysia accepts this constraint because it allows optimizations that multi-runtime frameworks cannot make.

Hono: Web Standards, Run Anywhere

Hono, built by Yusuke Wada, takes the opposite approach. It is built entirely on Web Standard APIs (Request, Response, Headers, URL) with no runtime-specific dependencies in its core. Hono runs on Bun, Cloudflare Workers, Deno, Vercel Edge, Fastly Compute, AWS Lambda, and Node.js. Switching runtimes means changing a single-line adapter import. Your routes, middleware, and business logic stay identical.

Hono's core is extremely small (under 14KB minified), and its RegExpRouter compiles all routes into a single regex for near-zero-cost route matching. For teams that value deployment flexibility, or expect their infrastructure to evolve, Hono is the safer long-term bet. For a detailed breakdown of how Hono stacks up against Express and Fastify on Node.js, see our Hono vs Express vs Fastify comparison.

Express: Legacy Power, Minimal Learning Curve

Express needs no introduction. It is the most widely used Node.js framework, with 60,000+ GitHub stars and millions of weekly npm downloads. Bun's Node.js compatibility layer means Express runs on Bun without modifications. You get Bun's faster startup, faster package installs, and some performance improvements at the HTTP parsing layer, all without touching your Express code.

The catch is that Express was designed in 2010 for callback-based Node.js. It does not leverage Bun-specific optimizations. It carries 14 years of architectural decisions that predate TypeScript, edge computing, and modern validation patterns. Running Express on Bun is like putting a new engine in an old car: it goes faster, but the chassis is still the limiting factor.

Performance benchmarks are the most cited and most misunderstood part of any framework comparison. Here are the numbers, followed by the context you need to interpret them correctly.

Raw HTTP Throughput on Bun (Single Core, JSON Response)

• Elysia: 160,000 to 190,000 requests/second. Elysia uses Bun.serve directly and optimizes serialization at the framework level. Static route analysis allows Elysia to skip middleware chains for routes that do not need them.
• Hono: 130,000 to 155,000 requests/second. Hono's RegExpRouter is extremely efficient, but the Web Standards abstraction layer (wrapping Bun's native response into a standard Response object) adds measurable overhead compared to Elysia's direct Bun.serve integration.
• Express on Bun: 35,000 to 50,000 requests/second. Bun's compatibility layer improves Express performance by roughly 2x compared to Node.js, but Express's linear route matching and middleware pipeline remain bottlenecks.

P99 Latency Under Load (10K Concurrent Connections)

• Elysia: 1.2ms to 2.5ms P99. Consistent and predictable, partly because Elysia avoids unnecessary object allocations in the hot path.
• Hono: 1.8ms to 3.5ms P99. Slightly higher tail latency due to the abstraction layer, but still excellent for production workloads.
• Express on Bun: 8ms to 18ms P99. The compatibility shim and Express's middleware execution model introduce variability under high concurrency.

Why These Numbers Are Misleading

In a real application, your route handler queries a database, calls external APIs, runs validation logic, and serializes a complex response. A benchmark with PostgreSQL queries, JWT validation, and response serialization shows all three frameworks converging: Elysia at 5,000 to 7,000 req/sec, Hono at 4,500 to 6,500 req/sec, and Express at 3,500 to 5,000 req/sec. The database query (2ms to 15ms) dominates the response time, making the framework's overhead a small fraction of total latency.

Where raw performance genuinely matters: high-throughput API gateways, WebSocket servers handling thousands of concurrent connections, real-time data streaming endpoints, and CPU-bound workloads like image processing or data transformation. If your API is I/O-bound (most CRUD APIs are), the performance difference between Elysia and Hono is unlikely to affect your users. The difference between Express and either modern framework, however, remains noticeable at scale. For background on how Bun's runtime performance compares to Node.js and Deno, see our Bun vs Node.js vs Deno breakdown.

TypeScript is table stakes for backend development in 2029. The question is not whether the framework supports TypeScript, but how deeply type safety is integrated into the request/response lifecycle.

Elysia: The Gold Standard for Type Inference

Elysia's type system is its most compelling feature. When you define a route with a validation schema (using Elysia's built-in TypeBox integration), the validated types automatically propagate to the handler function. Request body, query parameters, path parameters, headers, and response types are all inferred without manual annotations. Change a validation schema, and TypeScript immediately flags every handler and client call that breaks.

Eden Treaty takes this further. It generates a typed client from your Elysia server definition at the TypeScript level, with no build step or code generation. Your frontend code gets autocomplete for every API endpoint, including path parameters and response shapes. Calling an endpoint that does not exist or passing the wrong body type is a compile-time error. This is similar to tRPC but without requiring a monorepo or shared package. For teams that own both the API and the client, Eden Treaty eliminates integration bugs entirely.

Hono: Strong Inference, Slightly More Manual

Hono's TypeScript support is excellent but requires a bit more explicit setup. Hono's RPC client (similar to Eden Treaty) infers types from route definitions, giving you end-to-end type safety from server to client. Zod validation middleware integrates cleanly, and validated types flow into handlers. The difference from Elysia is marginal: Hono occasionally requires explicit type annotations where Elysia infers automatically, particularly with complex middleware chains.

Hono's validator middleware supports Zod, Valibot, and ArkType. You pick your preferred validation library, plug it in, and Hono infers the validated types. This flexibility is a strength if your team has strong preferences about validation libraries.

Express: Still Typing req.body as any

Express's TypeScript experience has not meaningfully improved. The @types/express definitions are community-maintained and often lag behind Express releases. Request bodies are typed as any unless you manually cast or extend the Request type through declaration merging. Middleware can mutate the request object in ways TypeScript cannot track, leading to runtime errors that the type system does not catch.

You can bolt validation onto Express with libraries like zod, joi, or yup, but the validated types do not flow into your route handlers automatically. You end up writing boilerplate to parse, validate, and cast request data in every handler. It works, but it is a step backward from what Elysia and Hono offer out of the box.

The middleware ecosystem determines how quickly you go from "hello world" to a production API with authentication, rate limiting, CORS, logging, and documentation.

Express Middleware: Quantity Over Modernity

Express has the largest middleware ecosystem by far. Passport.js (authentication with 500+ strategies), helmet (security headers), morgan (logging), express-rate-limit, multer (file uploads), cors, and thousands more. When a SaaS company ships a server SDK, Express is almost always the first integration. This ecosystem is 14 years deep and represents Express's strongest argument against migration.

The downside is that many popular Express middlewares are unmaintained or use patterns that predate async/await. Error handling in Express middleware chains is still callback-based, and unhandled promise rejections can crash your server if you forget to wrap async handlers. Express 5 partially addresses this, but the middleware ecosystem has not fully caught up.

Hono Middleware: Built-In Essentials, Web Standards Based

Hono ships built-in middleware for CORS, JWT authentication, Bearer Auth, Basic Auth, ETag, caching, request logging, security headers, and request timing. Because Hono middleware uses Web Standard APIs, every middleware works identically across all supported runtimes. Write a custom auth middleware for Bun, and it runs unchanged on Cloudflare Workers.

Hono's third-party ecosystem is growing quickly. Middleware for OpenAPI documentation (via @hono/zod-openapi), GraphQL, tRPC adapter, Swagger UI, and OAuth providers are all available. The ecosystem is younger than Express, so you may occasionally need to write custom middleware for niche requirements.

Elysia Middleware: Plugin-Based, Tightly Integrated

Elysia uses a plugin system rather than traditional middleware. Plugins can modify the Elysia instance, add routes, inject dependencies, and extend the type system. Official plugins cover Swagger/OpenAPI generation, JWT, CORS, static file serving, WebSocket handling, GraphQL (via GraphQL Yoga), and more. The plugin API is powerful: an authentication plugin can extend the type system so that protected route handlers have access to a typed user object automatically.

Validation Approaches

Elysia uses TypeBox by default for validation and schema definition. TypeBox schemas are JSON Schema compatible, which means they double as OpenAPI schema definitions. Elysia's Swagger plugin generates OpenAPI 3.0 documentation automatically from your route definitions and TypeBox schemas, with zero additional configuration.

Hono supports Zod, Valibot, and ArkType through its validator middleware. The @hono/zod-openapi package generates OpenAPI documentation from Zod schemas. It requires slightly more setup than Elysia's approach but gives you flexibility in choosing your validation library.

Express has no built-in validation. You install a third-party library (zod, joi, yup, express-validator), write validation logic in each route, and generate OpenAPI docs separately with swagger-jsdoc or tsoa. It works, but the pieces are disconnected, and keeping your validation schemas in sync with your OpenAPI docs is a manual process prone to drift.

Choosing a framework is not just about the code you write today. It is about where you can deploy it, how you test it, and whether the community behind it will still be active in three years.

Deployment Options

Elysia deploys anywhere Bun runs: bare metal, Docker, AWS EC2/ECS, Fly.io, Railway, and Render. It does not run on edge runtimes like Cloudflare Workers or Deno Deploy, and it does not run on Node.js. If your infrastructure strategy is "Bun everywhere," this is fine. If you foresee needing edge deployment or Node.js fallback, Elysia locks you out.

Hono deploys to every major platform: Bun, Node.js, Cloudflare Workers, Deno Deploy, Vercel Edge, Fastly Compute, AWS Lambda, and more. This is the broadest deployment surface of any JavaScript framework. You can start on Bun and move to Cloudflare Workers later, or run different parts of your API on different runtimes without rewriting business logic.

Express on Bun deploys wherever Bun runs, with the same limitations as Elysia. You also retain the option to fall back to Node.js if needed, since Express runs natively on Node.js. This dual-runtime flexibility is a genuine advantage for risk-averse teams.

Testing Tooling

Elysia has first-class testing support through its Eden Treaty client. You can write integration tests that call your API with full type safety, without starting an HTTP server. The test client uses the same typed interface as the production client, so your tests validate both behavior and types simultaneously. Bun's built-in test runner (bun test) pairs naturally with Elysia.

Hono provides a test client (app.request) that lets you send requests to your Hono app without a running server. Combined with Bun's test runner or Vitest, testing is straightforward. Hono's runtime portability means you can test on Bun locally and deploy to Cloudflare Workers with confidence that behavior is consistent.

Express testing uses supertest or direct HTTP calls. The patterns are well-established, and every testing tutorial on the internet covers Express. The tooling is mature but not type-safe.

Community Size and Momentum

Express has 65,000+ GitHub stars and is the most downloaded backend framework on npm. It is a mature project with slow, incremental development. The community is massive but not growing rapidly.

Hono has 25,000+ GitHub stars and is growing fast. It is backed by Cloudflare (Yusuke Wada works at Cloudflare), which gives it strong institutional support. The contributor community is active, and new middleware ships regularly.

Elysia has 12,000+ GitHub stars and a passionate community centered around the Bun ecosystem. SaltyAom is an active maintainer, and the framework evolves quickly. The community is smaller but highly engaged, and Elysia's Discord is one of the most active Bun-related communities.

All three are open source and actively maintained. Express is the safest bet for long-term maintenance (it has survived 14 years). Hono has strong corporate backing. Elysia has strong community momentum but is more dependent on a smaller team of maintainers.

Here are our specific recommendations, followed by practical migration advice for teams moving from Express.

Choose Elysia When:

• You are fully committed to Bun as your runtime and have no plans to deploy to edge runtimes or Node.js
• End-to-end type safety (server to client via Eden Treaty) is a priority, and you control both the API and the frontend
• Raw performance matters for your use case: high-throughput APIs, WebSocket servers, real-time applications
• You want automatic OpenAPI generation from your validation schemas with minimal configuration
• Your team is comfortable with a newer framework that has a smaller ecosystem and faster release cadence

Choose Hono When:

• You need deployment flexibility across multiple runtimes (Bun today, Cloudflare Workers tomorrow)
• You want a minimal, Web Standards-based framework that does not lock you into any single runtime
• Your team values a growing ecosystem with strong corporate backing (Cloudflare)
• You prefer choosing your own validation library (Zod, Valibot, ArkType) instead of a framework-mandated option
• You are building microservices or API gateways that may need to run on different infrastructure for different services

Choose Express on Bun When:

• You have an existing Express codebase and want Bun's performance benefits without a rewrite
• You depend heavily on Express-specific middleware (Passport.js strategies, niche integrations) with no equivalent in Elysia or Hono
• Your team's expertise is in Express, and the cost of learning a new framework outweighs the benefits
• You need a Node.js fallback path in case Bun does not meet your production requirements

Migration Paths from Express

If you are running Express on Node.js and considering a move to Bun, the lowest-risk step is simply running your existing Express app on Bun. No code changes required. You get faster startup, faster package installs, and a modest throughput improvement. This is a zero-effort win.

Migrating from Express to Hono requires rewriting route handlers to use the Web Standards API (c.req instead of req, c.json() instead of res.json()). The patterns map cleanly, and the migration is mostly mechanical. Budget 3 to 6 weeks for a medium-sized API (50 to 100 routes). The payoff is runtime portability and a modern middleware system. For a broader perspective on framework migration, see our Django vs FastAPI vs Express comparison.

Migrating from Express to Elysia is a larger undertaking because Elysia's plugin-based architecture and TypeBox validation require rethinking how you structure middleware and validation. Budget 4 to 8 weeks for a medium-sized API. The payoff is maximum Bun performance and end-to-end type safety through Eden Treaty.

For most teams building new projects on Bun in 2029, we recommend Hono as the default choice. It offers the best balance of performance, type safety, deployment flexibility, and ecosystem momentum. Choose Elysia if you are fully committed to Bun and want the absolute best TypeScript DX and performance. Keep Express only if you have a large existing codebase or hard dependencies on Express-specific middleware.

Whichever framework you pick, the important thing is to pick one and ship. The performance differences between Elysia and Hono are small enough that they should not delay your launch. If you need help evaluating frameworks or planning a migration for your project, book a free strategy call with our team.