AponiaJS vs Hono
Hono runs the same code on Workers, Deno, Bun, Node, and Lambda. AponiaJS runs only on Bun and spends what it saves on structure.
Hono's defining decision is portability: one application object that runs on
Cloudflare Workers, Deno, Bun, Node, and Lambda, built on Web standard
Request and Response. AponiaJS made the opposite decision and targets one
runtime.
At a glance
Runtime
No. Bun only
Yes. Workers, Deno, Bun, Node, Lambda, others
Maturity
No. Alpha
Yes. Stable
Size
Partial. Framework plus Elysia
Yes. Very small
Composition
Module graph with imports and exports
app.route() and middleware
Dependency injection
Yes. Constructor injection with a container
No. c.set and c.get, or your own
Validation
Yes. Route schemas rejected before the handler
Yes. Validator middleware, commonly with Zod
Typed client
Partial. Eden Treaty, native routes only
Yes. Hono RPC
Error format
Yes. RFC 9457 Problem Details built in
Partial. HTTPException, shaped by you
Edge deployment
No. Not possible
Yes. The primary use case
Portability is the whole comparison
If any of these are true, the decision is already made and it is not AponiaJS:
- you deploy to Cloudflare Workers, Deno Deploy, or Lambda;
- the same handlers must run in more than one runtime;
- cold start time dominates your latency budget;
- you want the smallest dependency footprint you can get.
Hono is built for that. AponiaJS depends on Bun and on Elysia, and neither is optional.
What you get for giving that up
// Hono
const app = new Hono();
app.get("/users/:id", (c) => c.json({ id: c.req.param("id") }));// AponiaJS
@Controller("users")
class UserController {
constructor(private readonly users: UserService) {}
@Get(":id")
find(@Param("id") id: string) {
return this.users.find(id);
}
}For one route, Hono is obviously better. The AponiaJS version starts paying off when there are forty routes, a dozen services, and more than one team touching them — modules declare boundaries, providers are constructed once at startup, and the graph is validated before the server listens.
Hono can be organised well; app.route() and per-file routers get you a long
way. It just does not have an opinion about how, and it has no container.
Typed clients, two routes to the same place
Neither framework generates code. Hono RPC infers a client from the app type; Eden Treaty infers one from the composed Elysia routes. The AponiaJS caveat is worth knowing before you plan around it: decorator-wide Eden inference is not implemented, so full client types come from statically composed native routes. It is in current limitations.
Which one to pick
Choose Hono when
- you deploy to the edge, or to more than one runtime;
- you want the smallest, fastest-to-start framework available;
- middleware composition is enough structure for your application;
- you are shipping to production now.
Choose AponiaJS when
- Bun is the only deployment target and that will not change;
- you want modules, controllers, and constructor injection rather than assembling a convention;
- Elysia is already the server;
- alpha software is acceptable for this codebase.
Frequently asked questions
- Can AponiaJS run on Cloudflare Workers or Deno?
- No. AponiaJS requires Bun and the Elysia platform package. If you need to deploy to Workers, Deno, or Lambda from one codebase, Hono is the framework designed for that and AponiaJS is not a candidate.
- How does Eden Treaty compare to Hono RPC?
- Both infer a typed client from the server's route types with no code generation step. Hono RPC infers from the chained app type; Eden Treaty infers from the composed Elysia routes, which in AponiaJS means the statically registered native routes rather than every decorated route.
- Is Hono smaller than AponiaJS?
- Considerably. Hono is a deliberately tiny router and middleware layer. AponiaJS adds a module graph, a container, decorator metadata, and the Elysia runtime underneath it.