Modern TypeScript Backends: Hono, ElysiaJS, and What Comes After NestJS

Why We Stopped Starting New Projects with NestJS

NestJS is a great framework. We've built enterprise systems on it (Vendure is NestJS under the hood, and we love Vendure). But for new standalone backend services, we've moved to Hono. Not because NestJS is bad. Because Hono is better for the way we work now.

The shift happened gradually. We started a new API service, considered NestJS, and asked ourselves: do we need decorators, modules, providers, and the Angular-inspired dependency injection container for a 15-endpoint API? The answer was no. We needed a fast HTTP framework that runs on any runtime, has good TypeScript support, and doesn't prescribe an architecture.

Hono delivered that. Then we tried ElysiaJS on Bun for a performance-critical service. That delivered something different. This article is an honest comparison from someone who runs all three in production.

For broader context on how we approach software engineering, that guide covers our principles. For how these frameworks fit into commerce architecture, see our Vendure production guide.

The Three Frameworks

Hono: The Framework That Runs Everywhere

Hono is a web framework built for the edge. It runs on Node.js, Bun, Deno, Cloudflare Workers, AWS Lambda, Vercel Edge, and Fastly. The same code deploys to any runtime without changes.

import { Hono } from 'hono';
import { cors } from 'hono/cors';
import { jwt } from 'hono/jwt';
import { logger } from 'hono/logger';

const app = new Hono();

// Middleware
app.use('*', logger());
app.use('*', cors({ origin: ['https://app.example.com'] }));
app.use('/api/*', jwt({ secret: process.env.JWT_SECRET! }));

// Routes
app.get('/api/products', async (c) => {
    const products = await productService.findAll();
    return c.json({ data: products });
});

app.get('/api/products/:id', async (c) => {
    const product = await productService.findById(c.req.param('id'));
    if (!product) return c.json({ error: 'Not found' }, 404);
    return c.json({ data: product });
});

app.post('/api/products', async (c) => {
    const body = await c.req.json();
    const product = await productService.create(body);
    return c.json({ data: product }, 201);
});

export default app;

Why We Like It

Runtime portability. We deploy the same Hono codebase to Lambda (API Gateway), Bun (container), and Cloudflare Workers (edge). No code changes between runtimes. This is Hono's unique strength. No other framework can do this.

14KB core. Cold starts on Lambda are under 100ms. NestJS cold starts are 2-5 seconds. For serverless deployments, this difference is the entire user experience.

No opinions on architecture. Hono gives you routing, middleware, and context. You decide how to structure services, repositories, and business logic. For small to medium APIs (5-50 endpoints), this is exactly right. You don't need a module system for 20 routes.

tRPC integration. We use Hono + tRPC for TypeScript-only stacks. End-to-end type safety from server to client without GraphQL:

import { trpcServer } from '@hono/trpc-server';
import { appRouter } from './trpc/router';

app.use('/trpc/*', trpcServer({ router: appRouter }));

Where It Falls Short

No built-in DI. For large applications with 50+ services and complex dependency graphs, you need to bring your own DI container (tsyringe, inversify) or wire dependencies manually. This is fine for small services. It becomes tedious for large ones.

Smaller middleware ecosystem. NestJS has passport, class-validator, class-transformer, swagger, and hundreds of community packages. Hono's ecosystem is growing but not there yet. You'll write more custom middleware.

No conventions for large apps. NestJS modules give you a structure that scales to 100+ files. Hono doesn't prescribe structure. For teams with junior developers, the lack of conventions can lead to inconsistent codebases.

ElysiaJS: When Bun Performance Matters

ElysiaJS is built specifically for Bun. It takes advantage of Bun's native APIs, FFI bindings, and optimized HTTP server to achieve performance that Node.js frameworks can't match.

import { Elysia, t } from 'elysia';
import { swagger } from '@elysiajs/swagger';
import { jwt } from '@elysiajs/jwt';

const app = new Elysia()
    .use(swagger())
    .use(jwt({ name: 'jwt', secret: process.env.JWT_SECRET! }))
    .get('/products', async () => {
        return productService.findAll();
    })
    .post('/products', async ({ body }) => {
        return productService.create(body);
    }, {
        body: t.Object({
            name: t.String(),
            price: t.Number({ minimum: 0 }),
            description: t.Optional(t.String()),
        }),
    })
    .listen(3000);

Why It's Interesting

Built-in validation with TypeBox. Schemas defined inline, automatically generate OpenAPI docs. No separate validation library needed. The types flow from schema to handler to response.

Bun-native performance. ElysiaJS on Bun handles 2-3x more requests per second than Express on Node.js for simple JSON APIs. For compute-light, I/O-heavy workloads (most APIs), the difference is less dramatic but still measurable.

End-to-end type inference. The request body type is inferred from the TypeBox schema. The response type is inferred from the handler. The client can use Eden (ElysiaJS's tRPC-like client) for type-safe API calls.

Where It Falls Short

Bun-only. If you need to deploy to Node.js, Lambda, or Cloudflare Workers, ElysiaJS is not an option. Bun is production-ready but not universally supported in all hosting environments.

Smaller ecosystem. Bun's package compatibility is good but not 100%. Some Node.js packages use native addons that Bun doesn't support. Database drivers, image processing libraries, and native crypto modules can be problematic.

Less battle-tested. Bun and ElysiaJS are newer. The community is smaller. When you hit an edge case, there are fewer Stack Overflow answers and fewer people who've solved the same problem.

Drizzle vs Prisma vs TypeORM: The ORM Reality

The framework choice is half the decision. The ORM choice is the other half.

Our Stack Choices

Hono + Drizzle + tRPC: For new TypeScript APIs. Lightweight, fast, type-safe end-to-end. Drizzle's SQL-like syntax gives us explicit control over queries without the abstraction overhead of TypeORM or the engine overhead of Prisma.

// Drizzle: SQL-like, explicit, type-safe
const products = await db
    .select()
    .from(productsTable)
    .where(and(
        eq(productsTable.tenantId, tenantId),
        eq(productsTable.status, 'active'),
        gt(productsTable.price, 1000),
    ))
    .orderBy(desc(productsTable.createdAt))
    .limit(20);

NestJS + TypeORM: For Vendure plugins and large enterprise applications where the module system and DI container justify their weight. TypeORM integrates deeply with NestJS and Vendure.

Prisma: When we need auto-generated migrations and the team values Prisma's documentation and developer experience over raw query control.

Deployment Flexibility

This is where the framework choice has the biggest practical impact.

If you deploy to containers only, all three work fine. If you deploy to serverless or edge, Hono is the only framework that gives you every option. ElysiaJS is Bun-only. NestJS is Node-only (practically).

For how we deploy services to cloud infrastructure including Kubernetes, Lambda, and edge functions, that page covers our approach.

When NestJS Is Still the Right Choice

Despite our preference for Hono on new projects, NestJS is the right choice when:

• You're building Vendure plugins. Vendure IS NestJS. The plugin system, services, resolvers, and guards all use NestJS patterns. Fighting the framework is worse than using it.
• Your team knows Angular. NestJS's module/provider/controller pattern mirrors Angular. If your team comes from Angular, the learning curve is near zero.
• You need a large middleware ecosystem. Passport strategies, class-validator, Swagger auto-generation, GraphQL code-first. NestJS has it all built or well-integrated.
• The application will grow to 100+ files. NestJS modules provide structure that scales. Without conventions (Hono, ElysiaJS), large teams need discipline to maintain consistency.
• You need WebSocket support. NestJS has built-in WebSocket gateways with the same decorator pattern. Hono's WebSocket support is more manual.

Common Pitfalls

1. Choosing Hono and then rebuilding NestJS. If you end up adding a DI container, decorator-based routing, module system, and guard pattern to Hono, you've just built a worse NestJS. Use NestJS.

2. Choosing ElysiaJS for production before evaluating Bun compatibility. Check that all your dependencies work on Bun. Native addons, specific database drivers, and some crypto libraries may not.

3. Ignoring cold start times on serverless. NestJS on Lambda is unusable for user-facing APIs without provisioned concurrency. Hono on Lambda is fast enough without it.

4. Using TypeORM with Hono. TypeORM is designed for NestJS's DI patterns. Without DI, managing TypeORM connections and repositories is awkward. Use Drizzle or Prisma with Hono.

5. Premature framework switching. If your NestJS app works and your team is productive, don't switch to Hono for the sake of being modern. Switch when you have a concrete reason (serverless deployment, edge functions, new standalone service).

6. No validation layer. Hono doesn't include request validation. Use Zod middleware or build your own. Shipping an API without input validation is a security vulnerability.

Key Takeaways

• Hono is the most versatile TypeScript backend framework. 14KB core, runs on every runtime, fast cold starts, no opinions on architecture. Our default for new standalone APIs.

• ElysiaJS delivers the best performance on Bun. Built-in validation, great DX, type-safe end-to-end. But Bun-only limits where you can deploy it.

• NestJS is still the right choice for large enterprise apps and Vendure. Modules, DI, guards, and a massive ecosystem. The learning curve pays off at scale.

• Drizzle is our preferred ORM with Hono. SQL-like syntax, explicit queries, lightweight bundle. Prisma for teams that prefer auto-generated clients. TypeORM for NestJS/Vendure.

• The deployment target drives the framework choice. Serverless and edge need Hono. Containers work with anything. Bun-native needs ElysiaJS.

• Don't switch frameworks without a reason. If NestJS is working, keep using it. Switch when you need serverless, edge, or a new standalone service where the lightweight approach is genuinely better.

We build TypeScript backends across all three frameworks as part of our web development and custom software practice. If you're evaluating frameworks for a new project, talk to our team or request a quote.