← All posts

April 25, 2026 · 3 min read

Why I chose Elysia over Express for Wooven's API

architectureelysiaexpressbuntypescriptdecision-log

The Hook

Express remains the default for Node.js APIs—usage and tutorials heavily tilt that way.

For Wooven's API layer I chose Elysia on Bun instead.

This post is a decision log, not a benchmark shootout. Where numbers matter, I point you to primary sources you can verify yourself.

Context

Wooven's API needs:

  • Strong type discipline at request boundaries (multi-tenant safety).
  • WebSockets for streaming build logs.
  • Bun as the runtime target for deployment simplicity.
  • Room for concurrent workloads without premature micro-optimization.

Option A: Express + TypeScript

Strengths

  • Universal familiarity and hiring surface area.
  • Huge middleware ecosystem.
  • Two decades of production lore.

Trade-offs

  • Validation and types are usually composed (e.g., Zod/OpenAPI) rather than inferred end-to-end by default.
  • Defaults reflect older HTTP ergonomics; modern alternatives emphasize typed handlers more centrally.

Option B: Elysia on Bun

Elysia is an MIT-licensed TypeScript framework designed around Bun. Bun's documentation lists Elysia in its ecosystem guides—that's first-party placement, not hype.

Strengths

  • Schema-first routes with end-to-end TypeScript inference as a design goal.
  • Validation integrated as a first-class concern—fewer hand-glued layers at the boundary.
  • WebSockets treated as part of the framework surface (not only bolt-on libraries).

Trade-offs

  • Smaller ecosystem than Express—npm download curves are not close if you compare packages directly (verify anytime on npm vs express).
  • You'll write more bespoke middleware glue than dropping in ubiquitous Express middleware stacks.

Verifiable ecosystem snapshot (check dates yourself)

Open-source signals change weekly—don't trust stale counts from any blog:

  • GitHub: elysiajs/elysia — stars/issues/releases are public.
  • npm: package elysia — weekly downloads and version history are public; express remains orders of magnitude larger on that axis.

That gap is the honest hiring and Stack Overflow penalty Elysia carries today.

Why I still chose Elysia

For a multi-tenant control plane, boundary correctness beats familiarity.

A handler that mishandles auth context or tenant scope can leak data across customers—I'd rather pay framework novelty cost than under-invest in typed boundaries.

This is engineering preference grounded in risk, not a claim that Express "can't" be made safe—it absolutely can, with discipline and tooling.

Risks I'm accepting

  • Onboarding friction: fewer engineers arrive knowing Elysia cold.
  • Ecosystem gaps: occasional custom middleware vs npm-install-and-go.
  • Runtime maturity: Bun moves fast—pin versions and read release notes.

What I've observed so far (ship log, not science)

  • Schema-first handlers caught real boundary mistakes early in development.
  • WebSocket log streaming matched product expectations without fighting the framework.
  • Performance hasn't been the bottleneck yet—correctness and clarity dominated.

If that changes, I'll instrument properly and write numbers with methodology—not vibes.

The question

Would you pick novel framework + stronger types, or Express + proven middleware stacks for a multi-tenant API in 2026?

If this kind of blunt trade-off logging resonates, wooven.dev has a waitlist.

Sources

  1. Bun documentation — Elysia ecosystem guide.
  2. Elysia — official site, GitHub repository.
  3. Express — npm package (compare adoption curves cautiously—applications vary).