How do their APIs compare?

Hono and Vite serve fundamentally different purposes, so their "APIs" are shaped around different problems — Hono around HTTP request routing/handling, Vite around dev-server/build tooling extensibility — but it's still useful to compare their design philosophies concretely.

Hono: a runtime HTTP routing/handler API

Hono's core API is a chainable, method-based router built directly on Web Standard Request/Response:

const app = new Hono().get('/search', (c) => c.json({ ok: true }))

Key characteristics visible in the data:

• Method-chaining builder pattern. .get(), .post(), .route(), .basePath() all return a (typed) instance, enabling composition like new Hono().basePath('/v1').route('/book', book) [src/client/client.test.ts:L688-L692].
• Context object (c) as the single handler argument. Handlers receive a Context (c) with .json(), .text(), .req, etc., rather than separate request/response objects — e.g. app.get('/api/foo', (c) => c.json({ datetime: new Date() })) [src/client/client.test.ts:L763-L766].
• Strong end-to-end type inference. The AppType pattern (type AppType = typeof app) feeds into the RPC client hc<AppType>(), so client calls like client.api.search.$get() are fully typed from the server route definitions, including response JSON shape [src/client/client.test.ts:L666-L674, L901-L919]. This is a distinctive Hono feature — the API contract is inferred, not hand-written.
• Adapters unify the API across runtimes. The same Hono app is wrapped by small adapter functions per platform, e.g. Cloudflare Pages' handle() just calls app.fetch(eventContext.request, ...) [src/adapter/cloudflare-pages/handler.ts:L31-L44], and AWS Lambda has per-event-type EventProcessor subclasses (EventV1Processor, LatticeV2Processor) that normalize different Lambda event shapes into the same Headers/method/path model consumed by the core app [src/adapter/aws-lambda/handler.ts:L443-L482, L584-L616].
• Helper functions are small, composable, pure functions rather than classes — e.g. accepts(c, options) for content negotiation [src/helper/accepts/accepts.ts:L29-L41], or getConnInfo(c) per-adapter for retrieving connection info [src/adapter/bun/conninfo.ts:L10-L21].
• WebSocket support via a declarative event-handler object (WSEvents with onOpen/onClose/onMessage) plumbed through a WSContext abstraction, again unifying behavior across Bun/Deno/Cloudflare [src/adapter/bun/websocket.ts:L31-L46, L74-L92].

Vite: a build/plugin extensibility API

Vite's public API is centered on configuration objects and a plugin hook system (a Rollup-compatible superset), not request routing:

• Config is declared via defineConfig, supporting plain objects, promises, or functions (sync/async) that return config — defineConfig({}), defineConfig(async () => ({})), defineConfig(() => ...) [packages/vite/src/node/tests_dts/config.ts:L13-L23]. This is a much flatter, declarative API compared to Hono's chained builder.
• Plugins are objects with named hooks (resolveId, load, transform, etc.), each optionally scoped with a filter for performance, e.g. optimizedDepsPlugin() implements resolveId(id) and load(id) hooks and gates itself with applyToEnvironment [packages/vite/src/node/plugins/optimizedDeps.ts:L20-L45]. Similarly htmlInlineProxyPlugin defines resolveId/load with a filter: { id: isHtmlProxyRE } shape [packages/vite/src/node/plugins/html.ts:L103-L120].
• Hooks operate on module IDs/content, not HTTP semantics. There's no equivalent of Hono's c.json()/c.text() — Vite hooks transform module code, resolve