Express Is Dead, Long Live Express 2026

TL;DR

Express is simultaneously dying and immortal. Express 5.0 shipped after 10 years and immediately felt like a maintenance release, not a comeback. Fastify is 3-4x faster. Hono runs on the edge. But Express has 35M weekly downloads, runs half the internet's Node.js backends, and has documentation for every conceivable use case. It will be maintained forever because too many things depend on it. The question isn't "is Express dead?" — it's "should I start a new project with it?"

Key Takeaways

• Express 5.0 shipped after 9+ years — minimal new features, breaking changes fixed
• 35M weekly downloads — still the most-used Node.js framework by a wide margin
• Fastify is 3-4x faster on throughput benchmarks
• Hono is the right choice for edge/serverless and modern TypeScript APIs
• Express is still correct for: teams that know it, legacy systems, maximum ecosystem compatibility

The State of Express in 2026

Express timeline:
2010: Launched (TJ Holowaychuk)
2014: Passed to StrongLoop (IBM acquires 2015)
2016: Express 5.0 alpha published — never shipped
2017-2023: Version 4.x maintained, no major features
2024: Express 5.0 finally released (rc → stable)
2026: Express 5.x is "stable" — but competitors have lapped it

Express 5.0 "new features":
→ Async/await error propagation (finally!)
→ Route path matching improvements
→ Removed deprecated APIs (res.json() params, etc.)
→ Updated dependencies

What Express 5.0 did NOT add:
→ Native TypeScript support
→ Built-in validation
→ Schema-based routing
→ Performance improvements (still synchronous middleware)
→ WebSocket support
→ Native HTTP/2

Compare to Fastify (released 2016, active development):
→ JSON schema validation built in
→ Plugin architecture (not middleware)
→ TypeScript-first
→ Logging with Pino (built in)
→ 80K+ req/s vs Express's 20K+ req/s
→ Active community, regular releases

Why Express Still Has 35M Weekly Downloads

Express isn't growing — it's coasting on inertia:

1. 15+ years of ecosystem
   → Thousands of express-* middleware packages
   → Every tutorial: "npm install express"
   → Every bootcamp teaches Express
   → Millions of existing apps in production

2. It works fine for most use cases
   → A CRUD API handling 100 req/s doesn't need Fastify's performance
   → Express is predictable — developers know exactly what it does
   → Debugging Express is easy because everything is a middleware

3. The cost of switching is real
   → Middleware doesn't work in Fastify (different plugin API)
   → Hono's edge focus requires different architecture thinking
   → Migration risk > performance gain for most teams

4. Enterprise inertia
   → Companies with 500K LOC Express codebases won't migrate
   → DevOps teams comfortable with Express deploy patterns
   → Hiring: "we use Express" is universally understood

The 35M/week number is not "developers choosing Express" —
it's "developers who happen to be using Express" (legacy + inertia).
New project adoption is a different story:
→ State of JS 2025: Hono and Fastify satisfaction both higher than Express
→ New project starts: Express declining year-over-year
→ Among devs starting NEW projects: Hono and Fastify capture most of the market

The Performance Gap Is Real (But May Not Matter)

# Framework throughput benchmarks (typical, varies by machine):

# Hello world JSON endpoint:
# Express:   ~20K req/s
# Fastify:   ~75K req/s
# Hono:      ~100K+ req/s (edge runtime)
# Elysia:    ~150K+ req/s (Bun runtime)

# Database query + JSON response:
# Express (with pg):   ~5K req/s
# Fastify (with pg):   ~12K req/s

# But here's the thing:
# Your database is probably the bottleneck, not your framework.
# If your DB handles 3K queries/second, your API handles ~3K req/s.
# Whether your framework adds 0.1ms or 0.5ms overhead is irrelevant.

# When performance DOES matter:
# → Very high traffic (>50K simultaneous users)
# → Latency-sensitive applications (real-time, gaming, HFT)
# → Edge computing (cold start time matters — Hono shines here)
# → Serverless (every ms of execution costs money)

# When performance DOESN'T matter:
# → Internal APIs (10 concurrent users)
# → B2B SaaS (peaks of hundreds, not thousands)
# → Startup MVPs
# → Any app where your DB is the bottleneck

# For most apps: Express's performance is completely fine.

When to Still Use Express

Express is the right choice when:

1. You're inheriting or maintaining an Express codebase
   → Don't migrate just because Fastify exists
   → Migration cost > performance gain for stable apps
   → Learn Express deeply instead of jumping to the new thing

2. You need maximum middleware ecosystem compatibility
   → express-rate-limit, passport, helmet, morgan, multer
   → These are designed for Express's middleware signature
   → Adapters exist for Fastify but add complexity

3. Your team knows Express and doesn't have bandwidth to learn a new framework
   → Shipping code > using the perfect tool
   → A team that knows Express ships faster than one learning Fastify

4. You're teaching Node.js backend development
   → Express is simpler to explain: "everything is middleware"
   → More tutorials, more Stack Overflow answers, more resources
   → Learn the simple thing first

5. You need a quick API with no performance requirements
   → 3 routes, internal use, 100 req/day
   → Express in 20 lines vs Fastify in 35 lines

Express is NOT the right choice when:
→ Starting a new production API with TypeScript requirements → Fastify
→ Building for edge runtime or serverless → Hono
→ Your app will handle massive traffic → Fastify or Hono
→ You want built-in validation + schema → Fastify

What Actually Replaced Express (For Different Use Cases)

# Use case: REST API, TypeScript, production Node.js
# → Fastify
npm install fastify @fastify/cors @fastify/helmet

# Fastify advantages over Express:
# - TypeScript built-in
# - Plugin system (not middleware) is more predictable
# - Built-in JSON schema validation (auto-generates TypeScript types)
# - Pino logging included
# - Same concepts, better defaults

# Use case: Edge runtime, Cloudflare Workers, Deno Deploy
# → Hono
npm install hono

# Hono advantages:
# - Runs in any JS runtime (Node, Bun, Deno, Cloudflare Workers)
# - Ultra-lightweight (14KB gzipped)
# - JSX built-in
# - Fast by design

# Use case: Full-stack, server components, SSR
# → Next.js API routes or Remix loaders
# These render the "need an Express API" moot

# Use case: tRPC (type-safe API)
# → tRPC adapter (works with Express AND Fastify AND Next.js)
npm install @trpc/server @trpc/client

# Express with tRPC is a valid modern stack:
# Express handles routing/middleware
# tRPC handles API type safety
# Best of both worlds for Express teams

The Verdict

Is Express dead? Technically: no.
Is Express the best choice for new projects? Also no.

Express will exist for 20+ more years.
Too many packages depend on it. Too many apps use it.
It will be maintained in the same way jQuery is maintained:
→ Security patches applied
→ Breaking changes avoided at all costs
→ No major new features
→ Kept running for the ecosystem that depends on it

The right mental model:
Express = jQuery of backend frameworks
→ Everywhere, battle-tested, slightly dated, works fine
→ New projects have better options
→ Existing projects: no urgent reason to migrate

The community's verdict (State of JS 2025):
→ Express: high usage (1st), lower satisfaction (4th)
→ Fastify: growing usage, high satisfaction (2nd)
→ Hono: low usage, highest satisfaction (1st)
→ Elysia: tiny but growing, excellent satisfaction

Translation:
People using Express are mostly doing so because they have to.
People who have chosen recently are choosing Fastify or Hono.
Express is the old reliable — not the exciting new thing.
And that's fine. Not everything needs to be exciting.

The Migration Decision: When to Leave Express

The question isn't whether Express is worse than Fastify or Hono on benchmarks — it clearly is. The question is whether the improvement is worth the migration cost for your specific situation. Most teams get this wrong in both directions: they either stay on Express out of pure inertia when they'd genuinely benefit from switching, or they migrate a working production service to chase performance gains that won't change their user experience.

The cases where migration is worth it: if you're building a new microservice where throughput matters, Fastify or Hono will handle two to four times more requests per second on the same hardware. For a new service, there's no migration cost — you're just making a greenfield choice. If your team is TypeScript-first and the community-maintained type definitions for Express are creating friction in your IDE or CI pipeline, Fastify and Hono both have first-class TypeScript support with better inference and no separate @types package required. If you're building for edge runtime — Cloudflare Workers, Deno Deploy, Bun — Express simply doesn't run in V8 isolates without significant modification. Hono was built for this environment from day one.

The cases where staying on Express makes sense: if you have a large existing Express codebase that works correctly and handles its traffic without strain, the migration risk and engineering cost almost certainly outweighs any performance improvement. The time spent rewriting middleware to Fastify plugins is time not spent shipping product. If your team's collective Express knowledge is deep — they know how to debug it, how to structure it, what the footguns are — that institutional knowledge has real value. And if your bottleneck is database queries, not framework overhead, a framework migration won't move any metric your users care about.

The honest assessment: Express is stable, thoroughly documented, and surrounded by a mature ecosystem. The reasons to leave are specific and technical — performance at scale, TypeScript DX, edge compatibility — not because Express is broken or unsupported.

Fastify and Hono: The Replacements Worth Knowing

The Express replacement market has largely consolidated around two frameworks for different use cases. Understanding which one fits your context is more useful than benchmarking them against each other.

Fastify, currently around 5 million weekly downloads, is the Node.js-native Express replacement. It ships with JSON schema validation via ajv built in, a plugin architecture that's more structured than Express's middleware chain, and throughput benchmarks two to four times higher than Express in controlled conditions. TypeScript support is first-class through @fastify/type-provider-typebox or @fastify/type-provider-json-schema-to-ts, which infer request and response types directly from the JSON schema definitions you're already writing for validation. The migration from Express to Fastify is largely mechanical — routing concepts map directly, middleware becomes plugins, req/res become request/reply. Teams that have made the switch generally report the transition taking a few days for a mid-sized codebase.

Hono, at around 2 million weekly downloads but with the fastest growth trajectory in the Node.js framework space, is a different kind of project. At roughly 14KB gzipped, it was designed from the ground up for edge computing and Cloudflare Workers, but it runs identically on Node.js, Bun, and Deno. It ships with a JSX renderer for server-side components, TypeScript-first routing, and an RPC-style client generator (hc) that generates a type-safe client from your server routes — a pattern that otherwise requires tRPC to achieve.

The 2026 recommendation: for a pure Node.js server migrating from Express, use Fastify. The mental model is familiar, the ecosystem overlap is high, and the performance gains are real. For edge-first architectures, multi-runtime support, or any new project where portability across runtimes is a requirement, use Hono. Both are actively maintained, well-documented, and represent genuine improvements over Express for their respective use cases.

Express 5: What Actually Changed After Ten Years

Express 5.0 landed in stable after a decade in alpha and release candidate status. For a version number that implied a significant generational leap, the actual changeset was more modest — and understanding exactly what changed clarifies why the release felt anticlimactic to most of the ecosystem.

The most substantive change in Express 5 is automatic error propagation for async route handlers. In Express 4, an unhandled Promise rejection inside a route handler would silently hang the request or crash the process — it would not reach the registered error-handling middleware. Developers worked around this with a wrapper utility (asyncHandler or express-async-errors) that monkey-patched the route methods to catch promise rejections and forward them to next(). Express 5 makes this behavior built-in: rejected promises in route handlers automatically flow to the next error handler. This alone eliminates a large category of production bugs and a dependency that many Express 4 projects carried.

The routing changes in Express 5 are also meaningful. Express 5 adopts the path-to-regexp v8 library for route pattern matching, which is more correct than the v0.1.7 version Express 4 used — specifically around named parameters, optional groups, and wildcard semantics. This is a breaking change: some route patterns that worked in Express 4 do not match the same inputs in Express 5, which is why the migration guide explicitly calls out route patterns as an area requiring manual review.

What Express 5 did not address is longer and more consequential: no native TypeScript support, no built-in request validation, no schema-based API definition, no built-in structured logging, and no performance improvements in the core request/response pipeline. The middleware model is identical to Express 4 — the same (req, res, next) signature, the same synchronous execution model, the same lack of a structured plugin system. Express 5 is a cleaned-up Express 4, not a re-architecture.

The fact that the community's reaction to Express 5 was largely "nice, but too little too late" reflects a decade of ecosystem drift. Fastify (2016), Koa (2013), and Hono (2022) all emerged to address the architectural limitations that Express left unresolved, and they have had years to build their own ecosystems. Express 5 gives existing Express 4 projects a clear upgrade path and fixes genuine bugs, but it doesn't recapture the developers who left for better tools.

The Weight of Backwards Compatibility

The ten-year gap between Express 4 and Express 5 was not primarily a technical problem — it was a backwards compatibility problem. Every potential improvement to Express's core architecture collided with the constraint that millions of existing applications depended on Express's specific behaviors.

The middleware signature (req, res, next) is the most visible example. Changing this signature in any meaningful way would break every Express middleware package ever written — passport, helmet, morgan, multer, cors, express-rate-limit, and thousands of others. Any redesign of Express's routing, error handling, or plugin model that deviated from the established patterns would require the entire middleware ecosystem to update simultaneously, which is not achievable in practice. This is why Express 5's improvements are surgical and opt-in rather than architectural.

The backwards compatibility constraint is also what makes Express's download count misleading as a "popularity" signal. Express appears in the dependency trees of Sails.js, LoopBack, Feathers.js, and (historically) NestJS's default adapter. These frameworks used Express as their underlying HTTP server, inheriting its download count without representing developers who consciously chose Express for a new project. Every NestJS application running the Express adapter bumped the Express weekly download count. NestJS's default adapter switch to Fastify as the recommended option (while retaining Express compatibility) is one reason Express's download growth has flattened.

The practical implication for maintainers: large ecosystems are self-reinforcing but also self-limiting. The same properties that make Express impossible to kill — the middleware ecosystem, the documentation, the tutorial coverage — make it impossible to modernize. The backwards compatibility surface is the moat. But moats work in both directions: they also trap you inside.

Frameworks Built on Express (and What They Tell You)

A useful way to understand Express's role in the 2026 ecosystem is to look at the frameworks built on top of it: Sails.js, LoopBack, Feathers.js, and (via its optional adapter) NestJS. These frameworks chose Express as their HTTP foundation for specific reasons, and the evolution of those choices tells a clear story about where Express sits in the value chain.

NestJS is the most revealing case. NestJS adopted an adapter pattern that allows swapping the underlying HTTP framework — Express is the default, Fastify is the recommended alternative. The architecture acknowledges that Express's specific semantics are not essential to NestJS's value proposition (dependency injection, decorators, module system) and that a faster HTTP layer is a drop-in improvement. Teams migrating a NestJS application from Express to Fastify typically report modest throughput improvements and no functional changes. The adapter abstraction means NestJS is genuinely agnostic — but its choice to make Fastify the performance recommendation signals where the ecosystem's opinion has settled.

Sails.js is a different story. It uses Express as its HTTP foundation but has not maintained the same development velocity or ecosystem momentum as NestJS. In 2026, Sails represents a class of "Express-based full-stack framework" that had its moment in 2013–2016 but has seen declining adoption relative to the Node.js ecosystem as a whole. The underlying Express dependency is now more of a historical artifact than a deliberate choice.

The broader pattern: frameworks that chose Express as their foundation did so because Express was the stable, well-understood HTTP layer in Node.js at the time they were built. Express's stability — the same req/res/next API for over a decade — made it a reliable base. But as those frameworks matured, many have decoupled themselves from Express specifically to access better performance and TypeScript support. The direction of that movement is informative.

The tRPC and Express Combination Worth Knowing

One underappreciated option for Express teams that want TypeScript type safety without a full framework migration is running tRPC on top of Express. This combination threads a needle: it preserves all existing Express middleware, routes, and operational patterns while adding end-to-end TypeScript type inference between the server and client — the primary DX advantage of purpose-built TypeScript frameworks.

tRPC works as an Express middleware adapter. You define your API as a set of typed procedures, mount the tRPC handler at an Express route, and the rest of your Express application continues unchanged. Your existing passport authentication middleware, rate limiting, request logging, and error handlers all still apply. The migration surface is limited to the API handlers you choose to migrate to tRPC procedures, which can happen incrementally alongside the existing REST routes.

The type safety model is the same as dedicated TypeScript frameworks: a server-side router defines procedure inputs and outputs, and a generated client on the frontend (or a separate Node.js service) receives those types automatically without any code generation step or OpenAPI schema. The @trpc/server and @trpc/client packages infer types across the network boundary through TypeScript's type system. If you change a procedure's input shape on the server, TypeScript will surface type errors in every calling client before any code reaches production.

This combination isn't an architectural ideal — you're layering a modern API abstraction on top of a legacy HTTP framework — but it is a pragmatic path for teams with large Express codebases that can't justify a full rewrite. The incremental adoption model means you can migrate one API surface at a time, validating the approach on low-risk endpoints before moving high-traffic routes. For Express teams, tRPC is the nearest thing to a TypeScript upgrade that doesn't require throwing away existing code.

The caveat worth noting: tRPC's RPC-over-HTTP model is not REST, and that distinction matters if your API has external consumers or is documented against an OpenAPI spec. tRPC generates its own client SDK and does not produce OpenAPI documentation without additional tooling. For purely internal APIs consumed by TypeScript clients you control, this is rarely a constraint. For public-facing APIs with multiple consumers or non-TypeScript clients, REST with Zod-validated request schemas and OpenAPI documentation (which Fastify handles natively through its JSON schema integration) is a cleaner long-term architecture.

What Express Actually Is in 2026

Framing Express as a "legacy" framework is accurate but incomplete. It obscures the specific roles that Express legitimately still serves, and conflating those roles leads to bad decisions in both directions — keeping it where you should move on, or abandoning it where it's still the right tool.

Express in 2026 is genuinely the right choice as a learning platform. The concepts it teaches — HTTP request/response cycles, middleware composition, routing, error handling — are foundational and transferable. A developer who learns backend JavaScript on Express has a solid mental model that transfers to Fastify, Koa, and Hono without significant relearning. The reverse is somewhat true but less clean: Express's specific patterns (middleware signature, res.json(), app.use()) are Express-specific enough that learning them as the primary model before broader concepts can create some mental debt. Despite this, the availability of Express learning resources is unmatched, and for someone new to Node.js backend development, starting with Express is still a defensible choice.

Express is also the right choice as a prototype environment. When the goal is to validate an API design quickly — get the routes up, test the business logic, see if the client can talk to the server — Express has the smallest ramp. No schema definitions required, no plugin registration, just app.get() and res.json(). The friction that Express's lack of conventions creates at scale is actually an asset at the prototype stage, where flexibility and speed matter more than architectural correctness.

Express as a legacy compatibility layer is its largest 2026 role, even if it is rarely described that way. Applications with thousands of lines of Express middleware — companies with production Node.js services that have been running on Express since 2015 — are not choosing Express so much as they are invested in it. The question for these teams is not "should we use Express?" but "what is the migration path and what do we get from it?" For most of them, the honest answer is "not enough to justify the cost right now," and Express as a maintained, stable, security-patched compatibility layer serves that need adequately.

Compare Express vs Fastify download trends and health scores at PkgPulse.

See also: Fastify vs Hono and Express vs Hono, Decline of Express: What Developers Are Switching To.