h3 vs polka vs koa HTTP Frameworks 2026

TL;DR

h3 is the UnJS HTTP framework — minimal, event-based, works on Node.js, Deno, Bun, Cloudflare Workers, and edge runtimes, powers Nitro and Nuxt server routes. polka is the Express alternative — same API as Express but 33% faster, tiny footprint, drop-in middleware compatibility. koa is the next-generation Express — created by the Express team, async/await-first with ctx context pattern, cascading middleware. In 2026: h3 for edge-first and UnJS ecosystem, polka for Express-compatible lightweight servers, koa for elegant async middleware patterns.

Quick Comparison

Key Takeaways

• h3: ~5M weekly downloads — UnJS, edge-ready, event-based, powers Nitro/Nuxt
• polka: ~3M weekly downloads — Express-compatible, 33% faster, same middleware
• koa: ~2M weekly downloads — async/await, ctx pattern, created by Express team
• All three are minimal alternatives to Express with lower overhead
• h3 is the only one designed for edge runtimes (Workers, Deno Deploy)
• polka is the easiest migration from Express (same API)

h3

h3 — minimal HTTP framework for any runtime:

Basic server

import { createApp, createRouter, eventHandler, toNodeListener } from "h3"
import { createServer } from "node:http"

const app = createApp()
const router = createRouter()

router.get("/", eventHandler(() => {
  return { message: "Hello from h3!" }
}))

router.get("/api/packages/:name", eventHandler((event) => {
  const name = getRouterParam(event, "name")
  return { package: name }
}))

app.use(router)

createServer(toNodeListener(app)).listen(3000)

Event handlers

import {
  createApp, createRouter, eventHandler,
  readBody, getQuery, getRouterParam,
  setResponseStatus, setResponseHeader,
  createError,
} from "h3"

const router = createRouter()

// GET with query parameters:
router.get("/api/packages", eventHandler(async (event) => {
  const { page, limit } = getQuery(event)
  const packages = await db.query("SELECT * FROM packages LIMIT $1 OFFSET $2", [
    limit ?? 20,
    ((page ?? 1) - 1) * (limit ?? 20),
  ])
  return { data: packages, page, limit }
}))

// POST with body:
router.post("/api/packages", eventHandler(async (event) => {
  const body = await readBody(event)
  if (!body.name) {
    throw createError({ statusCode: 400, message: "Name is required" })
  }
  const pkg = await db.insert("packages", body)
  setResponseStatus(event, 201)
  return pkg
}))

Edge runtime support

// h3 works on Cloudflare Workers, Deno, Bun — same code:

// Cloudflare Workers:
import { createApp, createRouter, eventHandler, toWebHandler } from "h3"

const app = createApp()
const router = createRouter()
router.get("/", eventHandler(() => ({ hello: "from the edge" })))
app.use(router)

export default { fetch: toWebHandler(app) }

// Deno:
import { serve } from "https://deno.land/std/http/server.ts"
serve(toWebHandler(app), { port: 3000 })

How Nuxt uses h3

// Nuxt server routes are h3 event handlers:

// server/api/packages.get.ts
export default eventHandler(async (event) => {
  const query = getQuery(event)
  return await fetchPackages(query)
})

// server/middleware/auth.ts
export default eventHandler((event) => {
  event.context.auth = validateSession(event)
})

polka

polka — Express alternative:

Basic server

import polka from "polka"

polka()
  .get("/", (req, res) => {
    res.end("Hello from polka!")
  })
  .get("/api/packages/:name", (req, res) => {
    res.end(JSON.stringify({ package: req.params.name }))
  })
  .listen(3000, () => {
    console.log("Running on port 3000")
  })

Express middleware compatibility

import polka from "polka"
import cors from "cors"
import helmet from "helmet"
import { json } from "@polka/parse"

// Express middleware works directly:
polka()
  .use(cors())
  .use(helmet())
  .use(json())
  .get("/api/packages", (req, res) => {
    res.setHeader("Content-Type", "application/json")
    res.end(JSON.stringify({ packages: [] }))
  })
  .post("/api/packages", (req, res) => {
    const { name } = req.body
    res.setHeader("Content-Type", "application/json")
    res.end(JSON.stringify({ created: name }))
  })
  .listen(3000)

Sub-applications

import polka from "polka"

const api = polka()
  .get("/packages", (req, res) => {
    res.end(JSON.stringify({ packages: [] }))
  })
  .get("/packages/:name", (req, res) => {
    res.end(JSON.stringify({ name: req.params.name }))
  })

polka()
  .use("/api", api)
  .get("/", (req, res) => {
    res.end("Homepage")
  })
  .listen(3000)

Performance numbers

Benchmark (requests/sec, simple JSON response):

  polka:    ~48,000 req/sec
  Express:  ~36,000 req/sec  (33% slower)
  Node.js:  ~52,000 req/sec  (raw http)

  polka gets ~92% of raw Node.js performance
  Express gets ~69% of raw Node.js performance

koa

koa — async/await middleware framework:

Basic server

import Koa from "koa"

const app = new Koa()

app.use(async (ctx) => {
  ctx.body = { message: "Hello from Koa!" }
})

app.listen(3000)

Context pattern

import Koa from "koa"
import Router from "@koa/router"

const app = new Koa()
const router = new Router()

router.get("/api/packages", async (ctx) => {
  const { page, limit } = ctx.query
  const packages = await db.query("SELECT * FROM packages")
  ctx.body = { data: packages, page, limit }
})

router.post("/api/packages", async (ctx) => {
  const body = ctx.request.body
  const pkg = await db.insert("packages", body)
  ctx.status = 201
  ctx.body = pkg
})

app.use(router.routes())
app.use(router.allowedMethods())
app.listen(3000)

Cascading middleware

import Koa from "koa"

const app = new Koa()

// Logger middleware — cascading (runs before AND after):
app.use(async (ctx, next) => {
  const start = Date.now()
  await next()  // Wait for downstream middleware
  const ms = Date.now() - start
  console.log(`${ctx.method} ${ctx.url} - ${ms}ms - ${ctx.status}`)
})

// Error handler:
app.use(async (ctx, next) => {
  try {
    await next()
  } catch (err) {
    ctx.status = err.status || 500
    ctx.body = { error: err.message }
    ctx.app.emit("error", err, ctx)
  }
})

Feature Comparison

The Node.js HTTP Framework Landscape in 2026

To understand where h3, polka, and koa fit, it helps to map the full landscape. At the top by downloads: Express (~30M weekly) remains the most installed HTTP framework in npm, used in millions of production applications despite its age. Fastify (~4M weekly) is the performance-first alternative with a schema-based request/response model and plugin ecosystem. Hono (~2M weekly) is the newest entrant — Web Standards-based, runs everywhere, excellent TypeScript, and growing fast.

h3, polka, and koa occupy a specific region of this landscape: they are lighter and more minimal than Express or Fastify, with different trade-off profiles. polka is Express with the overhead stripped out — if you already know Express, polka costs nothing to learn. koa is Express rethought around async/await — same concepts, cleaner composition. h3 is the framework that treats edge runtime portability as a first-class requirement, not an afterthought.

The comparison that matters most in 2026 is h3 vs Hono, not h3 vs polka. Both target the same use case — edge-capable, runtime-agnostic HTTP frameworks — and both power real production traffic. h3 is the better choice if you are in the UnJS ecosystem (Nuxt, Nitro, Vinxi) where it is the native framework. Hono is the better choice for standalone edge APIs where you want maximum performance and the cleanest TypeScript experience without the UnJS dependencies. Polka and koa remain strong choices for pure Node.js servers where edge portability is not a requirement, and where the Express ecosystem or async middleware patterns are important.

Performance Benchmarks

Raw throughput benchmarks for HTTP frameworks measure the overhead the framework adds on top of the Node.js http module. Raw Node.js — no framework, just the built-in HTTP server — handles approximately 50,000–55,000 simple JSON requests per second on modern hardware.

polka reaches approximately 92% of raw Node.js performance: ~48,000 req/sec. It achieves this by doing very little — the routing overhead (trouter, a trie-based router) is minimal, and polka doesn't decorate the req or res objects with additional methods the way Express does. Express adds roughly 50 properties and methods to req and res on every request; polka adds only params for matched route parameters. This decoration overhead is the largest source of Express's performance gap.

koa measures at approximately 30,000–38,000 req/sec — slower than polka and roughly comparable to Express, despite being architecturally different. The async overhead of koa's cascading middleware and the ctx object creation add up. For applications where koa's middleware composition model is valuable — before/after hooks, clean error propagation — this performance level is more than adequate for typical API workloads.

h3 in Node.js mode benchmarks similarly to koa: the event handler model's overhead is comparable. h3's performance advantage over polka appears in edge runtimes, where it runs on the Web Fetch API natively while polka requires Node.js compatibility layers. At the edge, h3 consistently outperforms polka adapters because it has no emulation overhead.

For applications where raw Node.js performance matters above all else, Fastify (with its JSON schema-based serialization) significantly outperforms all three of these frameworks. Fastify reaches 70,000–80,000 req/sec in typical benchmarks, exceeding raw Node.js HTTP for JSON responses because its schema-based serialization is faster than JSON.stringify. If throughput is the primary constraint, Fastify is the right choice, not h3/polka/koa.

Deployment Patterns

Traditional Node.js servers (polka, koa, h3): All three frameworks run as standard Node.js processes. You deploy them the same way you'd deploy any Node.js server — on a VPS, in a Docker container, behind an nginx reverse proxy, or on a PaaS like Railway, Render, or Fly.io. Health check endpoints, graceful shutdown, and process management work identically across the three. For this deployment model, all three are equivalent from an operational perspective.

Serverless (AWS Lambda, Vercel Functions, Netlify Functions): polka and koa are Node.js-native and deploy to serverless environments that provide a Node.js runtime. Each function invocation starts a fresh Node.js process, and the framework initialization happens on every cold start. h3 also deploys to Node.js serverless environments with toNodeListener(). The cold start overhead for all three frameworks is minimal — the frameworks themselves are small enough that initialization time is dominated by your application code and dependencies.

Edge runtimes (Cloudflare Workers, Vercel Edge Functions, Deno Deploy): This is where the frameworks diverge sharply. h3 is the only one in this comparison designed for edge runtimes. polka and koa depend on Node.js APIs that are not available in edge runtimes — http.IncomingMessage, http.ServerResponse, and the Node.js event system. Deploying polka or koa to a Cloudflare Worker requires a compatibility layer that emulates these Node.js APIs, which adds overhead and may have edge cases where the emulation is incomplete.

h3's toWebHandler() adapter produces a standard fetch-compatible function that edge runtimes expect natively. There is no emulation layer. The same h3 route handlers that serve traffic on a Node.js development server also run on Cloudflare Workers without modification.

TypeScript Support Depth

TypeScript integration quality varies meaningfully across the three frameworks, and the differences affect both day-to-day development experience and the reliability of typed API contracts.

h3 has first-class TypeScript support designed into the framework. The eventHandler() wrapper is generic and can be typed with a return type. The getQuery(), readBody(), and getRouterParam() utilities return typed values. Request context is extensible with a typed interface:

declare module "h3" {
  interface H3EventContext {
    user?: { id: string; email: string }
  }
}

// event.context.user is now typed everywhere

koa has solid TypeScript support via the @types/koa package. The ctx object is typed, and the ctx.state property is designed as the generic extension point for request-scoped data. @koa/router ships its own types. The type experience is good but lags h3's first-class TypeScript slightly because the types are maintained separately from the library.

polka's TypeScript support is the weakest of the three. It has type definitions but they reflect polka's minimal nature — req.params is typed as Record<string, string>, but many Express-style properties that middleware adds to req are not in the type definitions. Teams using polka with TypeScript typically end up augmenting the request type with a module declaration to add custom properties, and the process is less ergonomic than h3's extension pattern.

Plugin and Middleware Ecosystem

polka: The entire Express middleware ecosystem is polka's ecosystem. cors, helmet, morgan, express-rate-limit, passport, multer, express-validator — all of these work with polka without modification because polka uses the same (req, res, next) function signature. This is polka's single most important advantage over h3 and koa: you are not starting over. Years of Express middleware investment transfers completely.

koa: The koa middleware ecosystem is substantial and well-maintained. koa-body, @koa/cors, @koa/router, koa-helmet, koa-compress, koa-session — the major utility middleware categories are all covered. koa middleware uses the (ctx, next) signature and is not directly compatible with Express middleware. For Express middleware that doesn't have a koa equivalent, adapters like koa-connect can bridge the gap, but it's an additional complexity compared to polka's native compatibility.

h3: h3 has its own growing ecosystem of utilities within the UnJS organization — nitropack, unenv, ofetch, defu, and others. For HTTP-specific middleware, h3 provides many built-in utilities (CORS, body parsing, cookie handling) that would require separate packages in polka or koa. h3 does not have Express middleware compatibility, which means the rich Express ecosystem is not available without wrapping. For teams already in the UnJS ecosystem, this is a non-issue. For teams migrating from Express, the incompatibility is a real migration cost.

Migrating from Express to polka

Migrating from Express to polka is the easiest framework migration in the Node.js ecosystem. The API is intentionally compatible:

// Express:
import express from "express"
const app = express()
app.use(express.json())
app.get("/api/users", (req, res) => {
  res.json({ users: [] })
})
app.listen(3000)

// polka — change 3 lines:
import polka from "polka"
import { json } from "@polka/parse"  // Replace express.json()
const app = polka()
app.use(json())
app.get("/api/users", (req, res) => {
  res.json({ users: [] })  // Note: res.json() doesn't exist in polka!
})
app.listen(3000)

The main incompatibility to be aware of: polka does not add Express's response helper methods (res.json(), res.send(), res.redirect(), etc.) to the response object. You must use raw Node.js res methods: res.setHeader("Content-Type", "application/json"); res.end(JSON.stringify(data)). The @polka/send package adds some of these helpers back, but they must be imported explicitly.

Express middleware — anything using (req, res, next) — works without modification. cors, helmet, morgan, compression, express-rate-limit all transfer directly. The only middleware that won't work are those that depend on Express's added response helpers or properties.

The migration effort for a medium-sized Express API is typically two to four hours: replacing express() with polka(), updating response methods, and running tests. For applications where Express performance was a bottleneck, the improvement is immediate and meaningful.

Migrating from Express to koa

Migrating from Express to koa is a more substantial effort than migrating to polka. The API surface is different enough that it's effectively a rewrite of route handlers, even if the business logic remains the same.

The key differences to internalize:

Context instead of req/res. Every (req, res) handler becomes async (ctx). Request data comes from ctx.request (or ctx.query, ctx.params directly). Responses are set on ctx.body and ctx.status instead of calling res.json() or res.send().

Async-first. Every middleware is async (ctx, next). This is actually an improvement — you can await async operations without callback nesting or the subtle bugs that arise from forgetting to return next() in Express callbacks.

Body parsing. express.json() becomes koa-body. The koa-body package is well-maintained and handles JSON, form data, and file uploads.

Router. Express's built-in router becomes @koa/router. The API is similar but not identical — route definitions transfer with minor modifications.

Express middleware. This is the biggest migration cost. Express middleware using (req, res, next) doesn't work with koa directly. For popular middleware that has a koa equivalent, switch to the koa version. For middleware without a koa equivalent, koa-connect wraps Express-style middleware for use with koa, but it's a workaround rather than a solution.

A realistic estimate: migrating a 20-route Express API to koa takes one to two days. The patterns are learnable in a few hours, and the business logic transfers intact. The value you get in return is koa's more composable middleware model, which is genuinely better for complex middleware chains.

h3 vs Hono for Edge Deployments

For teams choosing an edge-capable HTTP framework, the real comparison is h3 vs Hono, not h3 vs polka. Both are Web Standards-based, both support Cloudflare Workers and Deno Deploy natively, and both have first-class TypeScript.

Hono's advantages over h3 for standalone edge APIs: a cleaner TypeScript experience (Hono was TypeScript-first from day one), a JSX-based templating system, middleware composable from a central app.use() call, and a slightly simpler setup. Hono's hc typed client generates a type-safe fetch client from your route definitions — you define a route with typed input and output on the server, and the client TypeScript types automatically reflect the API contract. This is not available in h3.

h3's advantages: native integration with Nuxt and Nitro, the full UnJS ecosystem (ofetch, defu, unenv, unstorage), and a more mature plugin system for Nuxt-specific features. If your project is built on Nuxt or Nitro, h3 is the obvious choice — it is the underlying framework, and Nuxt's server routes are h3 event handlers with no abstraction layer.

The practical rule: if you're building a Nuxt application or using Nitro as a deployment toolkit, use h3 — it's already there. If you're building a standalone edge API from scratch, evaluate Hono first. Both are excellent; the choice comes down to ecosystem fit rather than technical capability.

Production Considerations

Error handling: All three frameworks need explicit error handling middleware. h3 uses createError() for throwing HTTP errors and the app.use() global handler for catching unhandled errors. koa's cascading middleware makes error handling elegant — a single try/catch around await next() catches all downstream errors. polka uses the same (err, req, res, next) four-argument middleware signature as Express for error handlers.

Logging: None of the three frameworks includes built-in structured logging. The standard pattern is to add a logging middleware using pino or winston. For koa, the before/after logging pattern is particularly clean. For polka, Morgan works without any changes. For h3, the event handler model makes it easy to add correlation IDs to the event context.

Health checks: All three frameworks handle health checks as simple route handlers returning a 200 status with application state. In h3, returning { status: "ok" } from a GET /health handler is sufficient. The differences emerge in graceful shutdown: when the Node.js process receives a SIGTERM, the server should stop accepting new connections and allow in-flight requests to complete. This is application code rather than framework code, but h3's toNodeListener() gives you access to the underlying http.Server for shutdown control.

Graceful shutdown pattern:

// Works with polka and h3 (toNodeListener):
const server = polka().use(/* ... */).listen(3000)

process.on("SIGTERM", () => {
  server.server.close(() => {
    console.log("Server closed")
    process.exit(0)
  })
})

// Koa:
const server = app.listen(3000)
process.on("SIGTERM", () => {
  server.close(() => process.exit(0))
})

The Post-Express Landscape in 2026

Express is one of the most downloaded npm packages in existence, yet the JavaScript ecosystem has largely moved past its architecture. h3, polka, and koa represent three different philosophies about what comes after Express. polka takes the most pragmatic path: same callback API, same req/res interface, same middleware compatibility, just faster routing and a smaller footprint. koa takes the async-first path: the Express team rebuilt their architecture around async/await with a cascading middleware model. h3 takes the most ambitious path: designed from scratch for a world where JavaScript runs outside Node.js.

Choosing between them depends on whether you're maintaining existing Express code or starting fresh, and whether edge runtime portability is a requirement.

When to Use Each

Use h3 if:

• Need edge runtime support (Cloudflare Workers, Deno Deploy)
• Building with Nuxt or Nitro (UnJS ecosystem)
• Want a runtime-agnostic HTTP framework
• Need built-in body parsing, routing, and error handling

Use polka if:

• Migrating from Express and want a faster alternative
• Need Express middleware compatibility (cors, helmet, etc.)
• Want the simplest possible upgrade path
• Building a Node.js-only server

Use koa if:

• Want elegant async/await middleware patterns
• Need cascading middleware (before + after hooks)
• Building apps with complex middleware chains
• Prefer the ctx context pattern over req/res

The Post-Express Landscape in 2026

Express is one of the most downloaded npm packages in existence, yet the JavaScript ecosystem has largely moved past its architecture. Express was last major-versioned (v4) in 2014 and was built around a callback-based API that predates async/await. Express v5 was finally released after a decade in alpha, adding native async error handling, but it doesn't change Express's fundamental design: the req/res object model, the sequential middleware chain, or the tight coupling to Node.js's http module.

h3, polka, and koa represent three different philosophies about what comes after Express. polka takes the most pragmatic path: same callback API, same req/res interface, same middleware compatibility, just faster routing and a smaller footprint. If you have an Express app and want to reduce overhead without rewriting anything, polka is the path of least resistance — most Express middleware works without changes. koa takes the async-first path: the Express team themselves rebuilt their architecture around async/await with a cascading middleware model that's more composable than Express's linear stack. The ctx context pattern unifies request and response into a single object, and the await next() pattern makes before/after middleware hooks natural. h3 takes the most ambitious path: designed from scratch for a world where JavaScript runs outside Node.js, with a web-standards-aligned API that works on edge runtimes. The same h3 code that runs on a local Node.js server also runs on Cloudflare Workers.

Choosing between them depends on whether you're maintaining existing Express code or starting fresh, and whether edge runtime portability is a requirement now or a future consideration.

Edge Runtime Support: Why h3 is Different

The most significant architectural difference between h3 and its alternatives is runtime portability. Express, koa, and polka are all built on Node.js's http module — they use req and res objects that are Node.js-specific APIs. Deploying these frameworks to Cloudflare Workers, Deno Deploy, or Vercel's Edge Runtime requires adapters that emulate Node.js APIs, which adds overhead and sometimes fails for edge cases (literally — behavior at the edge).

h3 is built on the Web Fetch API (Request and Response), which is a universal web standard available in all modern JavaScript runtimes. The same h3 application code runs on Node.js, Deno, Bun, and Cloudflare Workers with zero runtime-specific changes. This matters most for applications built on the Nuxt/Nitro ecosystem, where the same server code may need to run across multiple deployment targets simultaneously: Vercel serverless functions, Cloudflare Workers for edge deployments, and a traditional Node.js server for local development. h3's runtime-agnostic architecture makes this possible without maintaining multiple server implementations.

The practical impact shows up in deployment flexibility. A team that starts with a Node.js h3 server can migrate to Cloudflare Workers later without rewriting their route handlers — only the entry point changes. This is increasingly valuable as edge deployment becomes a standard performance optimization. For polka and koa users who don't need edge deployment, the Node.js-only constraint is irrelevant. But for teams building Nuxt applications or planning edge deployments, h3 is the only option in this comparison that doesn't require an adapter.

Middleware Architecture: Express vs Koa vs h3

Express uses a linear middleware stack: each middleware calls next() to pass control forward to the next handler. Code after next() technically runs on the way back out, but Express doesn't guarantee this in a composable way — post-response hooks are awkward, usually implemented by listening to res.on("finish", ...) rather than writing cleanup code naturally after await next().

koa's cascading middleware model solves this cleanly. Each middleware is an async function: code before await next() runs on the way into the request, code after runs on the way out. Timing a request, catching errors from downstream handlers, adding response headers after the route handler completes — all of these are natural in koa's model and awkward in Express's. A koa request timer is three lines: record the start time, await next, log the elapsed time. The equivalent Express timer requires a res.on("finish") callback or a wrapping approach that's less readable.

h3's event handler model differs from both. Handlers return values instead of writing to a response object, making them easier to test in isolation: pass an event object, check the return value. The framework handles response serialization uniformly — returning a plain object sends JSON, returning a string sends text. Middleware in h3 is itself just an event handler that returns nothing when it wants to pass control forward. All three models are capable of expressing any HTTP server behavior; the choice largely depends on team preference, existing code patterns, and whether you need edge runtime portability.

Methodology

Download data from npm registry (weekly average, February 2026). Feature comparison based on h3 v1.x, polka v1.x, and koa v2.x.

Compare HTTP frameworks and server tooling on PkgPulse →

See also: Fastify vs Koa and Express vs Koa, better-sqlite3 vs libsql vs sql.js, and StyleX vs Tailwind CSS.