Best Node.js frameworks in 2026: Express, Fastify, NestJS, Hono, and the call I make for clients

I rebuilt the same Node.js API five times last month — once on each of the major frameworks — to settle a question a client kept asking: “what should we use in 2026?” Same workload (a customer-orders REST API with auth, JSON responses, Postgres reads), same droplet, same autocannon command, the actual numbers and developer experience side by side. The answer to best Node.js frameworks 2026 isn’t one framework — it’s three, depending on what you’re building. Here’s the breakdown, the benchmarks, the npm download trend, and the call I’d make for a paying client tomorrow.

The shortlist

Five frameworks I consider serious in 2026, plus one runner-up:

1. Express 5 — the incumbent. The Express 5.1 release in late 2024 modernized the async story and bumped the security floor (qs, path-to-regexp, body-parser).
2. Fastify 5 — schema-driven, performance-first, fully TypeScript-friendly. v5.8.x dropped Node 18 support and tightened the plugin API.
3. NestJS 11 — opinionated, decorator-based, Angular-flavoured DI for big teams. v11 lined up with Express 5 and Fastify 5.
4. Hono 4 — ultra-light, edge-runtime-friendly, runs on Node, Bun, Deno, Cloudflare Workers, Vercel Edge.
5. Elysia — Bun-only, end-to-end type-safe, very fast on Bun’s runtime.
6. Encore.ts (runner-up) — TypeScript framework with a Rust runtime under the hood, declarative infrastructure (DBs, Pub/Sub, cron) right in code. Worth a serious look if you’re building distributed services.

I left out Koa (still works, ecosystem stalled), Sails (use NestJS instead), AdonisJS (good but niche), and Restify (legacy). H3 / Nitro is interesting if you’re already in the Nuxt/Vue world, but I haven’t shipped it in production.

The benchmark

4-vCPU / 8 GB DigitalOcean droplet, Node 24.14 LTS (or Bun 1.3 where applicable). API: GET /api/orders/:id reads from Postgres (with Prisma 7), validates the response shape, returns 4 KB of JSON. Load: autocannon 7.x, 200 concurrent connections, 60 seconds. Three back-to-back runs, median values.

The numbers are honest but they’re one workload. They tell you which framework will hit a ceiling first under raw load — they tell you nothing about how nice the code is to maintain, how easy it is to onboard a contractor, or how the framework holds up at year three of a project.

Adoption: what the npm download trend actually says

Weekly npm downloads, mid-April 2026:

Two things to read out of that table. First, Express’s 92M downloads is misleading — most of it is transitive (every create-react-app or scaffold that bundles a dev server pulls Express in, regardless of whether anyone writes a route). Stack Overflow’s 2025 developer survey shows Express ranking high in “have used” but dropping sharply in “want to use” — the metric that predicts future adoption. Less than 5% of new projects in 2026 reach for Express first. Second, Fastify and Hono are both growing 40%+ year over year against Express’s flat trend. The direction is unambiguous even if the absolute numbers favor the incumbent.

Express 5 — the boring choice that mostly still wins for legacy

Express has been the Node.js default since 2010. Express 5 shipped properly in 2024 and 5.1 followed in 2025; the async story is finally what it should have been a decade ago (handlers can throw, errors propagate to error middleware automatically — no more (req, res, next) dance with try/catch in every handler).

import express from "express";

const app = express();
app.use(express.json());

app.get("/api/orders/:id", async (req, res) => {
  const order = await db.order.findUnique({ where: { id: req.params.id } });
  if (!order) return res.status(404).json({ error: "not found" });
  res.json(order);
});

// Async errors propagate automatically in Express 5 — no express-async-errors needed
app.use((err, _req, res, _next) => {
  res.status(500).json({ error: err.message });
});

app.listen(3000);

Why I still ship Express on legacy projects:

• Hiring market. Every Node.js developer knows Express. Onboarding is zero.
• Middleware ecosystem. Helmet, CORS, rate limiting, body parsing, file uploads — everything has a maintained Express adapter, including OAuth strategies that Fastify still doesn’t have.
• Production track record. Express has run more APIs than any other Node framework. The sharp edges are documented; the bug fixes are landed.

What it costs:

• Slowest of the five at raw throughput. For most APIs that’s irrelevant — you’re bottlenecked on Postgres long before you’re bottlenecked on Express.
• No native schema validation. You wire up Zod or Joi separately.
• No first-class TypeScript story. @types/express works but isn’t tight; req.body is any until you cast it. The TypeScript Node.js setup guide covers the config that compensates.
• Express 5.1 does not change the core architecture. The async fix was the headline; missing TypeScript-first design and missing schema validation are still missing.

Fastify 5 — what I’d ship to a paying client today

If you’re building a new Node.js API in 2026 and the shape is “REST with JSON, talking to Postgres or similar,” Fastify is my default. The schema-driven serialization win is real — fast-json-stringify compiles your response schema once and uses it for every request. The result is the 5× throughput delta in the table.

import Fastify from "fastify";
import { TypeBoxTypeProvider } from "@fastify/type-provider-typebox";
import { Type } from "@sinclair/typebox";

const app = Fastify({ logger: true })
  .withTypeProvider<TypeBoxTypeProvider>();

app.get("/api/orders/:id", {
  schema: {
    params: Type.Object({ id: Type.String() }),
    response: {
      200: Type.Object({
        id: Type.String(),
        customerId: Type.String(),
        total: Type.Number(),
        status: Type.String(),
      }),
    },
  },
}, async (req) => {
  // req.params.id is typed as string — no cast
  return db.order.findUnique({ where: { id: req.params.id } });
});

await app.listen({ port: 3000 });

Why Fastify wins for a senior team:

• Schema validation and response serialization are first-class — no plugin assembly required.
• Built-in pino logger. Best-in-class structured logging, no setup. Async transport via worker thread keeps logging off the event loop.
• Plugin system is genuinely modular. Encapsulation by default; fastify-plugin when you need to break it intentionally.
• TypeScript types are tighter than Express’s; type generics on routes give you typed params, query, and body from the schema automatically with TypeBox.
• v5.8.4 shipped two weeks before this article; Express’s last commit was months ago. The maintenance gradient matters over a 5-year project.

What it costs:

• Smaller community than Express. The middleware ecosystem is mature but not as wide — OAuth strategy coverage in particular lags Passport.js by years.
• The schema-first API is a real learning curve coming from Express. Expect a week of adjustment.
• Plugin encapsulation surprises Express developers — a plugin registered inside a fastify.register() scope isn’t available outside it. Use fastify-plugin when you need shared decorators.

Full Fastify-vs-Express benchmark and migration guide in the Express vs Fastify piece.

NestJS — the right answer for 8+ developer teams

NestJS is the framework I’d reach for when the question stops being “how fast is the request handler” and becomes “how do four teams collaborate on the same backend without stepping on each other.” The Angular-flavoured DI, the modules, the explicit boundaries — they’re overhead at small scale and a lifesaver at large.

import { Controller, Get, Param, NotFoundException } from "@nestjs/common";
import { OrdersService } from "./orders.service";

@Controller("orders")
export class OrdersController {
  constructor(private readonly ordersService: OrdersService) {}

  @Get(":id")
  async getOrder(@Param("id") id: string) {
    const order = await this.ordersService.findOne(id);
    if (!order) throw new NotFoundException();
    return order;
  }
}

What you get:

• Explicit dependency injection. Testing services in isolation is mechanical, not creative.
• Modules for explicit ownership boundaries. “This is the billing module; here’s its public API.”
• First-class GraphQL, microservices, queues, scheduling — all official packages, not bolt-ons. NestJS’s GraphQL module wraps Apollo Server — see the GraphQL with Apollo Server guide for the underlying API.
• Choice of HTTP adapter — Express by default, Fastify if you want the throughput. Switching is one line of bootstrap code and gives you 4× throughput without changing application code.
• ValidationPipe with class-validator gives type-safe DTO validation per route.

What you pay:

• Boilerplate. A simple endpoint is a controller, a service, a module, and a DTO. Worth it on a team of 10; overkill on a team of 2.
• Decorator metadata. The TypeScript compiler dance for emitDecoratorMetadata adds friction in some build setups (esbuild, swc need explicit plugins).
• You learn NestJS in addition to Node. The ecosystem is somewhat parallel — Nest’s @nestjs/jwt is not jsonwebtoken, etc.
• Bundle size (~150 kB) is significantly larger than Fastify or Hono. Matters for Lambda cold starts; doesn’t matter for long-lived containers.

If you’ve used Angular professionally, NestJS will feel obvious. If you haven’t, it’ll feel like a lot of indirection at first. Past 8 engineers on the same backend, the indirection is the point.

Hono — the modern choice if you can target modern runtimes

Hono is the framework that made me stop sneering at “edge-first” frameworks. It runs on Node, Bun, Deno, Cloudflare Workers, and Vercel Edge with the same code. The API feels like Express stripped of legacy and tightened up in TypeScript.

import { Hono } from "hono";
import { zValidator } from "@hono/zod-validator";
import { z } from "zod";

const app = new Hono();

app.get(
  "/api/orders/:id",
  zValidator("param", z.object({ id: z.string().uuid() })),
  async (c) => {
    const { id } = c.req.valid("param"); // typed!
    const order = await db.order.findUnique({ where: { id } });
    if (!order) return c.json({ error: "not found" }, 404);
    return c.json(order);
  }
);

export default app;
// Same code runs on Cloudflare Workers, Bun, Deno, and Node 24

Why I’m reaching for Hono more often:

• Genuinely fast on Node (128k req/s in this benchmark, 188k on Bun). On the same machine.
• Tiny dependency footprint. The whole framework is < 12 kB minified.
• Same code runs on Cloudflare Workers — handy when you want an edge-deployed read API in front of a slower origin.
• Type safety is excellent throughout. Validation via @hono/zod-validator or the built-in validator is one line per route.
• Web Standards-first: Request, Response, fetch-style handlers. Skills transfer to Workers, Deno, and the browser.

What’s still rough:

• Smaller ecosystem than Express or Fastify for Node-specific concerns. @fastify/multipart has more battle-tested file-upload support than Hono’s equivalent.
• If your hosting is locked to traditional Node, you don’t get the cross-runtime benefit — Fastify is the better Node-only default.
• Less middleware around enterprise auth (SAML, OIDC) than Express has via Passport.

Elysia — pick this when Bun is the platform

Elysia is Bun’s flagship framework. End-to-end type safety, very fast on Bun’s runtime, opinionated. If you’ve already committed to Bun for production, Elysia is the framework that takes the most advantage of it.

import { Elysia, t } from "elysia";

const app = new Elysia()
  .get("/api/orders/:id", async ({ params, set }) => {
    const order = await db.order.findUnique({ where: { id: params.id } });
    if (!order) { set.status = 404; return { error: "not found" }; }
    return order;
  }, {
    params: t.Object({ id: t.String() }),
  })
  .listen(3000);

The honest call: Elysia is exceptional on Bun. On Node it’s not really the point. And Bun in production in 2026 is still a “yes if your team is comfortable with it” call. The runtime is excellent for development; production support for tooling, observability, and managed hosting is improving but not yet at parity with Node. The full breakdown is in the Node.js vs Deno vs Bun piece.

The decision matrix: pick X when Y

When NOT to use each framework

• Don’t pick Fastify when: you have zero schema-first experience and a tight deadline (you’ll lose half the perf benefit and pick up a learning curve), you depend on Express-only middleware that isn’t ported (Passport’s full OAuth strategy zoo, some legacy webhook signature verification packages), or you ship to Cloudflare Workers (Fastify can’t run there at all).
• Don’t pick NestJS when: you’re solo or a team of 2 (the boilerplate slows you down before structure helps), you’re building a small API of < 10 routes, or your team has no Angular / Java / .NET background and dislikes decorators on principle.
• Don’t pick Hono when: you’re locked to Node-only hosting and need the Node-specific plugin ecosystem (Fastify is better), you need enterprise SSO or Passport-style auth strategies, or your team is allergic to the Web Streams API.
• Don’t pick Express for new projects when: you have any TypeScript ambitions (the type story will fight you), you need schema validation as a first-class concern, or you care about p99 latency under sustained load.
• Don’t pick Elysia when: you’re not committed to Bun for production. The framework is great; the runtime is the question.

Migration paths between the three

Express → Fastify: incremental via @fastify/express (full compat, higher overhead) or @fastify/middie (lighter, works for middleware that doesn’t call res.send()). Mount the legacy Express app as a sub-route, migrate one route at a time, decommission Express last. Two-day project for a 20-route API; multi-sprint for a 200-route one. The Express vs Fastify piece walks through the real migration recipe.

Express / Fastify → NestJS: don’t, unless team structure is the actual problem you’re solving. NestJS is a different abstraction (decorators, DI containers); the migration cost is high and the value is organizational, not technical. Better path: keep your existing framework, refactor to NestJS-style module boundaries first, then move when the abstraction earns its place.

NestJS Express adapter → NestJS Fastify adapter: one of the cheapest perf wins in the ecosystem. Single-line bootstrap change, 4× throughput gain on the same controllers. Worth doing the afternoon you decide it.

// NestJS swap from Express to Fastify adapter — application code unchanged
import { NestFactory } from "@nestjs/core";
import { FastifyAdapter, NestFastifyApplication } from "@nestjs/platform-fastify";
import { AppModule } from "./app.module";

async function bootstrap() {
  const app = await NestFactory.create<NestFastifyApplication>(
    AppModule,
    new FastifyAdapter({ logger: true })
  );
  await app.listen(3000, "0.0.0.0");
}
bootstrap();

When the framework choice doesn’t matter

For most APIs, the framework is the wrong place to optimize. Pick anything reasonable, ship it, profile when you have real load. Almost every real bottleneck I’ve debugged was the database, the cache, the JSON serialization, or the downstream HTTP call — not the framework’s request handling. Full performance breakdown in the Node.js performance optimization piece. Once you’ve picked a framework, the Jest vs Vitest API testing guide covers the test suite I run on top of any of them.

One specific case where the framework matters less than people think: serverless cold starts. NestJS’s 510 ms cold start sounds bad versus Hono’s 90 ms — but if your Lambda warms up after the first invocation and stays warm for 15 minutes, that 420 ms gap shows up exactly once per warm cycle. For a low-traffic Lambda the gap matters; for anything serving steady traffic the framework’s cold-start number is largely a vanity metric.

FAQ