AI News Hub Logo

AI News Hub

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

DEV Community
refaat Al Ktifan

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. Feature NestJS Hono ElysiaJS Runtime Node.js Node, Bun, Deno, Cloudflare Workers, Lambda, Vercel Bun (primarily) Architecture Opinionated (modules, controllers, providers) Minimal (routes, middleware) Minimal (routes, plugins) Type safety Decorators + runtime validation Middleware-based, manual Built-in validation (typebox) DI container Built-in (Angular-style) None (bring your own) None (plugins) Bundle size Large (~50MB node_modules) Tiny (~14KB core) Small (~2MB with Bun) Cold start Slow (2-5s on Lambda) Fast ( { 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; 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 })); 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 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); 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. 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. The framework choice is half the decision. The ORM choice is the other half. Feature Drizzle Prisma TypeORM Query style SQL-like (explicit) Client API (generated) Active Record or Data Mapper Type safety Excellent (inferred from schema) Excellent (generated client) Good (decorators) Migration SQL-based, manual control Auto-generated, managed Auto-generated or manual Performance Fast (thin wrapper over SQL) Good (query engine) Moderate (heavy abstraction) Raw SQL First-class (sql`` template) Possible but awkward Possible via query builder Edge/Serverless Works (lightweight) Needs Prisma Accelerate for edge Too heavy for edge Learning curve Low (if you know SQL) Low (API docs are excellent) Medium (decorators, relations) Bundle size Small (~500KB) Large (~15MB with engine) Medium (~5MB) Best with Hono, ElysiaJS Any framework NestJS, Vendure 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. `typescript 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. This is where the framework choice has the biggest practical impact. Deployment Target NestJS Hono ElysiaJS Docker/Kubernetes Works Works Works (Bun image) AWS Lambda Slow cold starts (2-5s) Fast (< 100ms) Not supported Cloudflare Workers Not supported Works natively Not supported Vercel Edge Not supported Works natively Not supported Deno Deploy Not supported Works natively Not supported Traditional VPS Works Works Works (needs Bun) Bun native Partial (most NestJS works on Bun) Works Native, optimized 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. 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. 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. 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. 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. 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. 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). 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.