koa vs elysia vs express vs hapi
Backend Frameworks for Frontend Developers
koaelysiaexpresshapiSimilar Packages:

Backend Frameworks for Frontend Developers

express, koa, hapi, and elysia are all server-side frameworks for building APIs and web services in JavaScript and TypeScript. express is the industry standard with a massive ecosystem, using a request-response middleware model. koa is created by the same team but focuses on async/await and a cleaner context object. hapi emphasizes configuration over code with strong validation built-in. elysia is a modern, TypeScript-first framework optimized for the Bun runtime but compatible with Node, focusing on speed and type safety.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
koa5,694,89635,74565 kB2815 days agoMIT
elysia017,5902.23 MB26611 days agoMIT
express068,94775.4 kB1893 months agoMIT
hapi014,779-587 years agoBSD-3-Clause

Express vs Koa vs Hapi vs Elysia: Architecture and DX Compared

Both express and koa are established Node.js frameworks, while hapi offers a configuration-heavy alternative, and elysia brings modern TypeScript features to the table. All four help you build servers, but they handle requests, errors, and types in very different ways. Let's compare how they tackle common engineering problems.

πŸ› οΈ Request Handling Model

express uses the classic req and res objects passed through middleware.

  • You modify req to add data and res to send responses.
  • Middleware chains using next() to pass control.
// express: Classic req/res
app.use((req, res, next) => {
  req.user = { id: 1 };
  next();
});

app.get('/', (req, res) => {
  res.send(`Hello ${req.user.id}`);
});

koa uses a single ctx (context) object instead of separate req/res.

  • Properties like ctx.request and ctx.body live on one object.
  • Async/await is built-in, so no next() callback needed.
// koa: Context object
app.use(async (ctx, next) => {
  ctx.state.user = { id: 1 };
  await next();
});

app.use(async (ctx) => {
  ctx.body = `Hello ${ctx.state.user.id}`;
});

hapi separates the request object and the h response toolkit.

  • Handlers receive both as arguments.
  • You return values instead of calling send methods.
// hapi: Request and toolkit
server.route({
  method: 'GET',
  path: '/',
  handler: (request, h) => {
    return `Hello ${request.auth.credentials.id}`;
  }
});

elysia uses a single context object similar to Koa but with types.

  • You destructure what you need directly in the handler.
  • Returns data directly; the framework handles the response.
// elysia: Typed context
app.get('/', ({ user }) => {
  return `Hello ${user.id}`;
});

πŸ—ΊοΈ Routing and Validation

express requires external packages for validation (like joi or zod).

  • Routes are defined directly on the app instance.
  • Validation logic is manual middleware.
// express: Manual validation
app.post('/user', (req, res, next) => {
  if (!req.body.name) return res.status(400).send('Missing name');
  res.send('OK');
});

koa also needs external routers and validation libraries.

  • Typically uses @koa/router for path handling.
  • Validation is added as middleware layers.
// koa: External router
router.post('/user', async (ctx) => {
  if (!ctx.request.body.name) {
    ctx.status = 400;
    return;
  }
  ctx.body = 'OK';
});

hapi has validation built into the route configuration.

  • You define schemas for params, query, and payload.
  • Requests are rejected automatically if validation fails.
// hapi: Built-in validation
server.route({
  method: 'POST',
  path: '/user',
  options: {
    validate: {
      payload: Joi.object({ name: Joi.string().required() })
    }
  },
  handler: (request) => 'OK'
});

elysia uses TypeScript types and plugins for validation.

  • Schemas are defined inline with the route.
  • Types are inferred automatically for end-to-end safety.
// elysia: Type-safe validation
app.post('/user', ({ body }) => 'OK', {
  body: t.Object({
    name: t.String()
  })
});

🚨 Error Handling

express uses a special middleware function with four arguments.

  • You pass errors to next(err) to trigger it.
  • Easy to forget, leading to unhandled promises.
// express: Error middleware
app.use((err, req, res, next) => {
  res.status(500).send(err.message);
});

koa relies on standard try/catch blocks in async functions.

  • Errors bubble up automatically through the middleware chain.
  • More natural for modern JavaScript developers.
// koa: Try/catch
app.use(async (ctx, next) => {
  try {
    await next();
  } catch (err) {
    ctx.status = 500;
    ctx.body = err.message;
  }
});

hapi uses the boom library for HTTP errors.

  • You throw errors, and the framework maps them to status codes.
  • Consistent error response structure.
// hapi: Boom errors
handler: (request, h) => {
  throw Boom.badRequest('Invalid input');
}

elysia has dedicated error handling hooks.

  • You can catch specific error types globally.
  • Returns JSON errors by default.
// elysia: Error hook
app.onError(({ code, error }) => {
  return { message: error.message };
});

⚑ Performance and Runtime

express runs on Node.js and is mature but slower than newer options.

  • Great stability but lacks modern runtime optimizations.
  • Works everywhere Node.js works.
// express: Node.js runtime
import express from 'express';
const app = express();
app.listen(3000);

koa runs on Node.js and is slightly lighter than Express.

  • No callback overhead improves performance slightly.
  • Still bound by Node.js event loop limits.
// koa: Node.js runtime
import Koa from 'koa';
const app = new Koa();
app.listen(3000);

hapi runs on Node.js with a focus on stability over speed.

  • Extra validation and abstraction layers add overhead.
  • Best for complex enterprise apps where speed is secondary.
// hapi: Node.js runtime
import { Server } from '@hapi/hapi';
const server = new Server({ port: 3000 });
await server.start();

elysia is optimized for Bun but supports Node.js.

  • Significantly faster on Bun due to runtime differences.
  • Best choice if you can deploy to Bun environments.
// elysia: Bun or Node runtime
import { Elysia } from 'elysia';
new Elysia().listen(3000);

🀝 Similarities: Shared Ground

While the differences are clear, all four frameworks share core concepts for building web servers.

1. 🌐 HTTP Server Abstraction

  • All wrap the native Node.js http module (or Bun equivalent).
  • Handle incoming requests and outgoing responses.
// All frameworks ultimately listen on a port
app.listen(3000); // express, koa, elysia
server.start();   // hapi

2. πŸ”Œ Middleware Architecture

  • All support middleware to intercept requests.
  • Used for logging, auth, and parsing bodies.
// express
app.use(logger);
// koa
app.use(logger);
// hapi
server.ext('onRequest', logger);
// elysia
app.use(logger());

3. πŸ”’ Security Extensions

  • All rely on plugins for CORS, Helmet, and rate limiting.
  • None ship with every security feature enabled by default.
// express
app.use(cors());
// koa
app.use(cors());
// hapi
server.register(require('@hapi/cors'));
// elysia
app.use(cors());

4. πŸ“¦ JSON Support

  • All parse JSON bodies automatically or via simple config.
  • Return JSON responses easily.
// express
app.use(express.json());
// koa
app.use(bodyparser.json());
// hapi
// Built-in payload parsing
// elysia
// Built-in JSON parsing

πŸ“Š Summary: Key Differences

Featureexpresskoahapielysia
Runtime🟒 Node.js🟒 Node.js🟒 Node.js🟣 Bun (Primary) / Node
StyleπŸ“ Callback/Promise⏳ Async/Awaitβš™οΈ ConfigurationπŸ›‘οΈ TypeScript First
ValidationπŸ”Œ ExternalπŸ”Œ Externalβœ… Built-inβœ… Built-in (Types)
ContextπŸ“¦ req + resπŸ“¦ ctxπŸ“¦ request + hπŸ“¦ Typed Context
Learning CurveπŸ“‰ LowπŸ“‰ LowπŸ“ˆ HighπŸ“‰ Low (for TS users)

πŸ“Š Summary: Key Similarities

FeatureShared by All Four
Core Goal🌐 Build HTTP APIs
MiddlewareπŸ”Œ Request interception
EcosystemπŸ“¦ NPM Plugins
LanguageπŸ’» JavaScript/TypeScript
Deployment☁️ Container/Serverless

πŸ’‘ The Big Picture

express is the reliable workhorse 🐴 β€” it runs everything, has a plugin for anything, and every host supports it. Ideal for legacy projects, quick prototypes, or teams that need maximum hiring pool compatibility.

koa is the modernized Express 🧹 β€” same team, cleaner code, no callback hell. Best for teams who want Express flexibility but prefer modern async/await syntax without the baggage.

hapi is the enterprise vault 🏦 β€” strict, configurable, and secure by default. Perfect for large organizations where configuration rules and validation matter more than setup speed.

elysia is the speed racer 🏎️ β€” built for today's TypeScript and Bun ecosystem. Choose this for new greenfield projects where performance and type safety are top priorities.

Final Thought: All four frameworks can build robust APIs. Your choice depends on whether you value ecosystem size (express), code cleanliness (koa), configuration strictness (hapi), or modern performance (elysia).

How to Choose: koa vs elysia vs express vs hapi

  • koa:

    Choose koa if you want a lighter foundation than Express with modern async/await support without the baggage of older patterns. It is ideal for teams that prefer building their own middleware stack from scratch rather than relying on a massive ecosystem.

  • elysia:

    Choose elysia if you are starting a new project and want the best TypeScript experience with high performance. It is perfect for teams adopting the Bun runtime or those who want end-to-end type safety without extra code generation tools.

  • express:

    Choose express if you need maximum compatibility with existing tutorials, plugins, and hosting providers. It is the safest bet for teams that want a vast library of middleware and don't mind managing callback-style middleware patterns.

  • hapi:

    Choose hapi if you need strict input validation and a configuration-driven architecture out of the box. It suits enterprise environments where security policies and detailed request schemas are more important than raw speed or minimal setup.

README for koa

Koa middleware framework for nodejs

gitter NPM version build status Test coverage OpenCollective Backers OpenCollective Sponsors PR's Welcome

Expressive HTTP middleware framework for node.js to make web applications and APIs more enjoyable to write. Koa's middleware stack flows in a stack-like manner, allowing you to perform actions downstream then filter and manipulate the response upstream.

Only methods that are common to nearly all HTTP servers are integrated directly into Koa's small ~570 SLOC codebase. This includes things like content negotiation, normalization of node inconsistencies, redirection, and a few others.

Koa is not bundled with any middleware.

Installation

Koa requires node v18.0.0 or higher for ES2015 and async function support.

npm install koa

Hello Koa

const Koa = require('koa');
const app = new Koa();

// response
app.use(ctx => {
  ctx.body = 'Hello Koa';
});

app.listen(3000);

Getting started

  • Kick-Off-Koa - An intro to Koa via a set of self-guided workshops.
  • Guide - Go straight to the docs.

Middleware

Koa is a middleware framework that can take two different kinds of functions as middleware:

  • async function
  • common function

Here is an example of logger middleware with each of the different functions:

async functions (node v7.6+)

app.use(async (ctx, next) => {
  const start = Date.now();
  await next();
  const ms = Date.now() - start;
  console.log(`${ctx.method} ${ctx.url} - ${ms}ms`);
});

Common function

// Middleware normally takes two parameters (ctx, next), ctx is the context for one request,
// next is a function that is invoked to execute the downstream middleware. It returns a Promise with a then function for running code after completion.

app.use((ctx, next) => {
  const start = Date.now();
  return next().then(() => {
    const ms = Date.now() - start;
    console.log(`${ctx.method} ${ctx.url} - ${ms}ms`);
  });
});

Koa v1.x Middleware Signature

The middleware signature changed between v1.x and v2.x. The older signature is deprecated.

Old signature middleware support has been removed in v3

Please see the Migration Guide from v2.x to v3.x for information on upgrading from v2.x to v3.x, and the Migration Guide from v1.x to v2.x for information on upgrading from v1.x to v2.x.

Context, Request and Response

Each middleware receives a Koa Context object that encapsulates an incoming http message and the corresponding response to that message. ctx is often used as the parameter name for the context object.

app.use(async (ctx, next) => { await next(); });

Koa provides a Request object as the request property of the Context. Koa's Request object provides helpful methods for working with http requests which delegate to an IncomingMessage from the node http module.

Here is an example of checking that a requesting client supports xml.

app.use(async (ctx, next) => {
  ctx.assert(ctx.request.accepts('xml'), 406);
  // equivalent to:
  // if (!ctx.request.accepts('xml')) ctx.throw(406);
  await next();
});

Koa provides a Response object as the response property of the Context. Koa's Response object provides helpful methods for working with http responses which delegate to a ServerResponse .

Koa's pattern of delegating to Node's request and response objects rather than extending them provides a cleaner interface and reduces conflicts between different middleware and with Node itself as well as providing better support for stream handling. The IncomingMessage can still be directly accessed as the req property on the Context and ServerResponse can be directly accessed as the res property on the Context.

Here is an example using Koa's Response object to stream a file as the response body.

app.use(async (ctx, next) => {
  await next();
  ctx.response.type = 'xml';
  ctx.response.body = fs.createReadStream('really_large.xml');
});

The Context object also provides shortcuts for methods on its request and response. In the prior examples, ctx.type can be used instead of ctx.response.type and ctx.accepts can be used instead of ctx.request.accepts.

For more information on Request, Response and Context, see the Request API Reference, Response API Reference and Context API Reference.

Koa Application

The object created when executing new Koa() is known as the Koa application object.

The application object is Koa's interface with node's http server and handles the registration of middleware, dispatching to the middleware from http, default error handling, as well as configuration of the context, request and response objects.

Learn more about the application object in the Application API Reference.

Documentation

Troubleshooting

Check the Troubleshooting Guide or Debugging Koa in the general Koa guide.

Running tests

$ npm test

Reporting vulnerabilities

To report a security vulnerability, please do not open an issue, as this notifies attackers of the vulnerability. Instead, please email dead_horse, jonathanong, and niftylettuce to disclose.

Authors

See AUTHORS.

Community

Job Board

Looking for a career upgrade?

Backers

Support us with a monthly donation and help us continue our activities.

Sponsors

Become a sponsor and get your logo on our README on Github with a link to your site.

License

MIT