I first tried Elysia because I wanted to know whether Bun could make a small TypeScript API feel simpler, not because I needed another framework to collect.
The short answer: the setup is genuinely quick, and the type inference is the interesting part. The longer answer is that a fast hello-world is not enough reason to move an existing backend.
Start with the smallest useful API
Create the project:
bun create elysia app
cd app
bun dev
A small route looks like this:
import { Elysia, t } from "elysia"
const app = new Elysia()
.get("/health", () => ({ ok: true }))
.post(
"/notes",
({ body }) => ({ id: crypto.randomUUID(), ...body }),
{
body: t.Object({
title: t.String({ minLength: 1 }),
body: t.Optional(t.String()),
}),
},
)
.listen(3000)
console.log(`Listening on http://localhost:${app.server?.port}`)
What I like here is that validation sits beside the route. The schema is useful at runtime, while TypeScript infers the body type for the handler. There is less distance between what the endpoint accepts and what the editor understands.
What felt good
- The initial project is small enough to read in one sitting.
- Route definitions are concise without hiding the HTTP model.
- Runtime validation and TypeScript inference work together.
- Bun starts the development server quickly.
That combination makes Elysia pleasant for prototypes, internal services, and focused APIs.
What I would check before using it at work
A framework choice is more than request throughput. I would also check:
- whether the libraries we need behave correctly on Bun;
- how the team will handle logging, tracing, migrations, and background jobs;
- whether deployment supports the runtime without special workarounds;
- how easy it will be for another engineer to maintain the service six months later.
If an existing Express or Fastify service is stable, a benchmark alone would not persuade me to rewrite it. Migration risk is real, and mature ecosystems are valuable.
My current take
Elysia is worth trying when Bun is already an acceptable runtime and end-to-end typing matters to the project. I would reach for it on a small new service before considering it for a large migration.
The framework made a strong first impression because it removes ceremony. The next test is not another hello-world; it is building one complete service with a database, authentication, tests, observability, and deployment. That is where a backend framework earns its place.
Top comments (0)