★ 69,157JavaScriptMITupdated Jun 2026
best for the default choice — biggest middleware ecosystem and what most other Node frameworks still build on
Express is still the one everyone knows, and that's the actual pitch — the biggest middleware ecosystem in Node, a six-file core you can read in an afternoon, and v5 finally fixing async error handling so a throw inside a route handler reaches your error middleware instead of vanishing into a rejected promise nobody awaited.
The catch: v5 isn't what's running in most production apps yet. On v4, still the majority install, an uncaught rejection in an async handler just hangs the request — you wrap every handler yourself or pull in a package to do it for you. Express also has zero opinion on project structure, TypeScript, or validation, which is fine until three engineers each build the same app a different way.
Our full take →GitHub ↗
★ 75,812TypeScriptMITupdated Jun 2026
best for teams building large APIs who want Angular-style structure, dependency injection and TypeScript enforced from day one
NestJS is what you reach for when you want Angular's structure on the backend — real dependency injection, a module system that keeps a big codebase navigable, and first-party Guards, Interceptors, and Pipes that compose in a documented order instead of middleware spaghetti.
The cost shows up in how much ceremony a simple route takes — stack enough decorators for auth, validation, and logging and a one-line handler becomes six. It runs on Express by default, so you inherit Express's synchronous middleware model underneath the abstraction, and switching to Fastify later means auditing everything you've added. Circular dependencies get patched with forwardRef rather than designed around, a smell the framework tolerates more than it should in a large module graph.
Our full take →GitHub ↗
★ 37,205JavaScriptMITupdated Sep 2026
best for teams who want Express's shape but need real throughput, with schema validation built in
Fastify keeps Express's general shape — routes, middleware-like hooks — but fixes the performance ceiling with schema-based serialization that compiles your JSON Schema into a fast serializer ahead of time, plus a plugin encapsulation model that actually scopes decorators instead of dumping everything into one global namespace.
The hook lifecycle (onRequest, preValidation, preHandler, onSend, and so on) is what trips people up — a decorator not being visible in a handler because of encapsulation rules is a rite of passage. TypeScript is layered on through type providers rather than built in from the schema up, so you'll fight generic inference on anything beyond simple routes, and community plugin quality varies enough that you should check the last publish date before depending on one.
Our full take →GitHub ↗
★ 30,946TypeScriptMITupdated Jun 2026
best for projects targeting edge runtimes like Cloudflare Workers, Deno or Bun, or anyone wanting a tiny dependency-light core
Hono is the pick if you're not actually targeting a long-lived Node server — it runs on Cloudflare Workers, Deno, Bun, and Lambda off the same Web Standards API, stays under 12kB, and its router benchmarks faster than Express, Koa, and Fastify. The typed RPC client generates request functions straight from your route definitions, which is end-to-end type safety without bolting on tRPC.
What you give up is maturity everywhere else. The middleware ecosystem is a fraction of Express or Fastify's, so anything past basic auth and CORS you're writing yourself. There's no built-in validation — pick zod or valibot and wire it by hand — and type inference visibly slows once a route file gets large, which the project tracks as an open problem rather than a solved one. The JSX runtime also isn't React; it's a different reconciler wearing React's syntax, and that catches people who assume otherwise.
Our full take →GitHub ↗
★ 35,682JavaScriptMITupdated Oct 2026
best for developers who want raw async middleware control without Express's legacy callback baggage
Koa is Express's own team rebuilding it around async/await instead of callbacks — a roughly 570-line core, onion-model middleware (await next()) that makes logging and error-handling easy to reason about, and ctx delegation that doesn't monkey-patch Node's request/response objects.
It ships with nothing else, though — no router, no body parser, no static file serving. You're assembling the same stack Express gives you out of the box, except from koa-* packages of inconsistent upkeep, vetted against an unofficial wiki list instead of anything resembling a maintained registry. If the appeal is a thin core you add to yourself, Hono does the same thing with a typed client and multi-runtime support thrown in, for about the same amount of assembly required.
Our full take →GitHub ↗
★ 18,977TypeScriptMITupdated Jun 2026
best for teams who want a Laravel-style all-in-one framework — ORM, auth, validation — out of the box
AdonisJS is the Laravel move — an IoC container with DI that actually works at runtime, VineJS validation with error messages people can read, and CLI generators for controllers, validators, and middleware that cover more of the app than Nest's scaffolding does.
The tradeoff is depth versus coverage: the official packages (auth, session, Lucid ORM) are solid, but there isn't much past them, and you'll hit a gap fast if you step off the documented path — nowhere near Nest's ecosystem for plugging in a random third-party need. Lucid's Active Record pattern also leaks database concerns straight into your models, making testing harder than it should be. And the project has effectively one person driving meaningful commits, worth weighing if you're betting on it for the next five years.
Our full take →GitHub ↗
★ 15,248TypeScriptMITupdated Jun 2026
best for apps that need REST and realtime websocket APIs from the same service definitions
Feathers solves a problem none of the others on this list do: define a service once — find, get, create, update, patch, remove — and it works over REST and socket.io with no separate code path. If your app genuinely needs realtime sync alongside a normal API, nothing here gets you there faster.
If you don't need that, the rest of the design doesn't carry its weight. The real-time channel system for deciding what gets pushed to which socket is powerful but confusing enough that most teams end up with one 'authenticated' channel and never touch the rest of it. The v5 rewrite was a big breaking change and plenty of third-party adapters never caught up, so going off the happy path risks an unmaintained package. The query syntax for filtering is also its own invention — not SQL, not Mongo — one more thing to learn that doesn't transfer anywhere else. At 15k stars after ten-plus years, it's not dying, but it's not growing either, which matters if you're picking a framework to still be maintained in 2030.
Our full take →GitHub ↗
// questions people ask
Before you choose
Is Express still the right default in 2026?
For most new projects, yes — it has the biggest middleware ecosystem and almost every other framework on this list either runs on it (NestJS) or defines itself against it (Fastify, Koa). The catch is you're inheriting its decisions by default too: no TypeScript, no structure, and in v4 installs, no safe async error handling without wrapping every handler yourself.
Fastify or Hono for a new API?
Fastify if you're deploying to a long-lived Node server and want schema validation with real plugin isolation. Hono if you're targeting Cloudflare Workers, Deno, or Bun, or just want the smallest possible footprint — its router benchmarks faster than both, but the middleware ecosystem is much thinner.
NestJS or AdonisJS for a big TypeScript backend?
NestJS if your team already thinks in Angular-style modules and DI, and you want the bigger ecosystem backing you up when you need a package. AdonisJS if you want Laravel's conventions and are fine with a thinner set of official packages and effectively one maintainer driving the project.
Does Koa replace Express?
Not really — it fixes Express's callback-era API with async/await and a cleaner middleware model, but it ships without a router, body parser, or static file serving, so you're assembling the same stack from third-party koa-* packages instead. If you want that minimalism with more included by default, Hono is the newer version of this idea.
None of these is wrong, they just assume different things about how much you want decided for you. Pick based on what you're shipping, not the star count — and if you want more picks like these in your inbox every week, that's the whole premise of the email.