The JavaScript Backend Stack to Reach For in 2026

Spin up a new Node service today and the muscle memory says npm i express. That muscle memory is now slightly wrong. Express still works, still ships on millions of servers, and still pulls roughly 76 million downloads a week. But "what everyone installs by reflex" and "what you'd choose if you thought about it for ten minutes" have quietly stopped being the same thing.

The backend half of JavaScript got interesting again. Not because someone reinvented HTTP, but because the runtime stopped being a settled question and the framework choice now actually depends on where your code runs. Let me walk through who's eating whose lunch, and end with what I'd default to.

The runtime question came back from the dead

For a decade, "JavaScript on the server" meant Node. Done. Deno took a swing and mostly carved out a niche. Then Bun grew up.

The thing about Bun in 2026 is that it stopped being a benchmark toy. Bun 1.3, shipped in October 2025, folded a stack's worth of tooling into the runtime itself: a unified SQL client for Postgres, MySQL/MariaDB, and SQLite; a built-in Redis client; a full-stack dev server with hot module replacement; native cookie handling, YAML parsing, and CSRF helpers. The pitch isn't "JavaScript, but faster." It's "you don't need eleven dependencies to start."

Be careful with the speed claims, though. The headline numbers (4x this, 20x that) are mostly transpilation and bun install figures. Package installs really are several times faster than npm, and that genuinely shrinks CI time. But once you put a database and real business logic behind an endpoint, the gap collapses. Independent comparisons keep landing on the same uncomfortable truth: Node, Deno, and Bun all settle around 12,000 requests per second on a realistic app, and the dramatic spread only shows up in hello-world routes (Strapi's 2026 benchmark write-up is a level-headed look at this).

So where does Bun actually win? Greenfield projects, CLIs, and serverless functions where you own the dependency list. It's been adopted in production at real shops — Anthropic's Claude Code uses Bun's single-file executables, and Vercel wired it into native Next.js deploys. The honest enterprise pattern right now: use bun install and bun test in CI to cut pipeline time, keep Node as the production runtime if you've got native modules and compliance to worry about. You get most of the speed and skip the migration risk.

Express isn't dying, it's becoming infrastructure

Here's the nuance everyone skips: Express isn't losing users. It's losing new projects.

Express 5.0 finally shipped in October 2024 — the first major version in roughly ten years, after the v5 pull request sat open since 2014. That's the whole story in one fact. The release was real and useful (it dropped support for ancient Node, fixed long-standing path-matching footguns, improved error handling for async code), but a decade between majors tells you the project spent years in maintenance mode.

The download counts stay enormous because of inertia, not momentum. Express powers a generation of APIs that nobody wants to touch and that work fine, so they keep pulling the package on every install. That's healthy in the way a paved road is healthy. It's just not where the energy is. For a brand-new service in 2026, picking Express means picking the most-documented, most-StackOverflow'd, least-surprising option — which is a legitimate reason, just not an exciting one.

Hono won the edge, and the edge is spreading

If Bun is the runtime story, Hono is the framework story.

Hono is built on Web Standard APIs — Request, Response, fetch — instead of Node-specific objects. That one design decision is the whole pitch: the same code runs on Cloudflare Workers, Deno, Bun, Node, AWS Lambda, and Vercel without changes. You're not coding to a runtime, you're coding to the platform, and the platform is the web.

The numbers are real. Hono's router benchmarks at 402,820 ops/sec on Cloudflare Workers, ahead of the other Workers routers, and its framework benchmark on Deno hits 136,112 requests/sec, leading the pack there too. It ships around 14KB with zero dependencies, which matters a lot when cold-start time is your bill.

A minimal Hono service looks like this, and it's deliberately boring:

import { Hono } from "hono";
 
const app = new Hono();
 
app.get("/health", (c) => c.json({ ok: true }));
 
app.get("/users/:id", (c) => {
  const id = c.req.param("id");
  return c.json({ id, name: "Maya" });
});
 
export default app;

That same file deploys to Workers, Deno Deploy, or a Node server with a different entry shim and nothing else changed. Runtime portability sounds like a checkbox feature until you've been locked into one platform's request object and had to rewrite a layer to move. It compounds.

Fastify is still the answer when raw throughput is the point

Fastify doesn't chase the edge. It chases the number. If you're running a long-lived Node server and requests-per-second on a real workload is the metric your boss watches, Fastify's schema-based serialization and plugin architecture still make it the fast pick for that shape of problem. It sits at a few million weekly downloads — far below Express, well above the newcomers — which is roughly the right size for "the framework people choose on purpose, not by reflex."

Pick Fastify when you control the box, you're staying on Node, and you want speed without rewriting to Web Standards. It's the least fashionable choice on this list and that's a point in its favor.

NestJS owns the part nobody else wants: structure

Everything above optimizes for small and fast. NestJS optimizes for a team of fifteen who all need to find things in the same place six months from now.

It's opinionated Angular-style architecture for the backend — modules, dependency injection, decorators, the works. With north of 3 million weekly downloads, it's the default when an app is big enough that consistency beats cleverness. The boilerplate that feels like overkill on a side project is the entire point on a system where four squads ship to the same codebase. Nobody reaches for Nest to win a benchmark. They reach for it so the new hire can read any module and already know the shape.

So what do you actually pick?

Here's the honest decision table.

A flowchart, if you think better in arrows:

One more thing worth naming, because it's quietly shaping all of this: AI-assisted coding rewards whatever has the most training data. Ask an agent to scaffold a backend and it reaches for Express, because Express has fifteen years of examples on the internet. That's a real gravity well — the most-documented stack gets recommended, gets used, generates more documentation, and the loop tightens. It's a decent reason to know Express cold. It's a bad reason to start every new project there in 2026.

My actual recommendation

If I'm starting something new today, the default is Hono running on Bun. You get a Web-Standards framework that moves between runtimes, plus a toolkit that means fewer dependencies on day one. It's the combination that genuinely changed the math, not just the marketing.

The exceptions are clean. Big app, real team, long horizon: NestJS, because structure is the feature. Throughput-critical service you'll run on your own Node boxes for years: Fastify. Maintaining an existing system, or you simply want the most-trodden path with the least chance of a weird edge case: Express, still fine, no shame in it.

What's gone is the single reflexive answer. The good news is that knowing four tools instead of one is not a big ask — and if you're still shoring up the basics underneath all this, the JavaScript fundamentals series and the TypeScript track are the foundation every one of these frameworks assumes you already have. Deploying any of them also means living in a shell, so the command line series pays for itself fast.