Express 5 keeps the HTTP layer small
Express gives Node.js applications routing, middleware composition, response helpers, content negotiation, and view rendering without dictating the rest of the stack. The README says it supports more than 14 template engines and requires Node.js 18 or newer. A basic server is a short import, route, and listen call. That directness still makes Express easy to inspect when a request takes the wrong path.
The same restraint creates work outside the framework. Express does not choose an ORM or template engine, and it does not claim to supply authentication, request schemas, or a deployment platform. You choose those pieces and decide how they fail together. For a team with established conventions, that freedom is useful. For a new service without such conventions, a minimal framework can turn every ordinary application concern into a fresh design decision.
The quick start names generator 4 beside Express 5.2.1
The current README points newcomers to express-generator@4, while GitHub lists v5.2.1 as the latest release. The page also says the generator's major version will match Express. Those details do not line up cleanly, so anyone starting a version 5 application should check the generated dependency and read the linked migration guide before treating the scaffold as current guidance.
You can avoid that ambiguity by starting from the small inline example, then adding only the middleware your application needs. The repository also includes runnable examples for content negotiation and other features. That route takes more deliberate setup, but it keeps the runtime version visible in package.json and makes each added package an explicit choice rather than inherited starter baggage. The generator may still save typing on a conventional website. It should not decide the version or structure silently, especially when the surrounding README presents 2 different major numbers in one quick-start path.
What happened when we ran it
Our sandbox installed Express at commit 9a34acf in 20 seconds. Npm added 351 packages and occupied 66 MB on disk. The repository had 214 files, about 21,633 lines of source, and a 0.7 MB checkout. There was no build script or target, so we skipped the build step instead of inventing one.
The Mocha suite completed in 4 seconds with 1,256 passed and 0 failed out of 1,256 tests. Npm audit reported 0 known vulnerabilities across every severity level. Under our test method, that is a clean result for repository mechanics. It does not measure application throughput, production latency, or the security of middleware you add later.
Our checkout contained 5 CI workflow files and a tests directory, but no Dockerfile. The missing container recipe is reasonable for a framework used in many environments, though it leaves base image selection, non-root execution, health checks, shutdown handling, and reverse-proxy settings to each adopter. Those decisions deserve their own deployment test because the passing suite covers Express itself, not your assembled service.
Version 5 deserves a migration review before deployment
The README calls out the migration guide rather than presenting version 5 as a drop-in upgrade. Release v5.2.1 also carries a useful maintenance record: it reverted an erroneous breaking change from v5.2.0 involving the extended query parser. The release notes say the associated CVE was rejected and that no security vulnerability existed. That correction is reassuring, but it also shows why teams should test their own query and middleware behavior across upgrades.
Express remains deliberately close to HTTP without filling every protocol gap. Issue 2414, updated in September 2026, still asks for route() to handle HTTP 405 Method Not Allowed. If your API contract requires automatic method reporting, confirm the behavior and add middleware or routing policy rather than assuming the framework will emit it. The same rule applies to validation and error bodies: define them at the application boundary.
Current activity supports adoption, not hands-off architecture
GitHub showed 69,490 stars and 235 open issues and pull requests when fetched. The last repository push was September 15, 2026, while the combined issue and pull request list had updates through September 24. That pairing matters more than the older v5.2.1 release date because it shows current work around releases, dependencies, documentation, response handling, and performance.
Express is the conservative pick when familiarity, a broad middleware ecosystem, and a passing 1,256-test run outweigh the appeal of stronger framework opinions. Its cost is architectural ownership. Before choosing it, write down who owns schemas, authentication, errors, observability, and deployment. If those answers already exist, Express stays out of the way. If they do not, Fastify or hapi may give the project a firmer starting shape.