# Express 5 is small HTTP tooling that refuses to pick your ORM or template engine

> Express is a minimalist Node web framework whose whole surface is routing, middleware and HTTP helpers. Version 5 is the current major, split-grew from 4 by a deprecation pass, and the repository leaves architecture, database and templating to you. That restraint is the point and also the cost.

**expressjs/express** — Fast, unopinionated, minimalist web framework for node. Express does not force you to use any specific ORM or template engine.

- Repository: https://github.com/expressjs/express
- Website: https://expressjs.com
- Stars: 69,478 · Forks: 25,065
- Language: JavaScript
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/expressjs-express

## The whole surface is app, router and a req/res pair

A complete Express server fits in nine lines: import express, create an app, register a route with app.get that hands a handler (req, res), and call app.listen on a port. The handler receives the request and the response and does the work, and Express itself is only the layer that decides which handler runs. There is no project layout, no service container, no decorator. The README calls Express a minimalist web framework for Node that does not force a specific ORM or template engine, and it names the job as small tooling for HTTP servers. Everything above that, from database access to session storage to rendering, is a layer you add and own. That restraint is the reason Express has stayed small and also why a new codebase built on it has no house structure until you write one.

## Middleware is the composition model, and order is the contract

Express composes behaviour as a chain of middleware functions, and the order they are registered in is the order they run, which is why two handlers for one route behave differently depending on which was added first. The feature list claims strong routing, HTTP helpers for redirection and caching, content negotiation, and a view system supporting 14+ template engines. Content negotiation is the clearest example of what the framework gives you that raw Node does not: it inspects the request headers and picks a response representation for you, and the repository even ships a runnable example, node examples/content-negotiation, so you can watch it choose. The consequence for a reader assembling a stack is that the framework is deliberately dumb about your domain, so the safety you expect from a higher-level framework, validation, error shapes, transaction boundaries, has to be written and ordered by hand.

## The dependency list is the real architecture

package.json is more instructive than the README. The runtime dependencies number more than thirty, and they are the parts Express has split out: body-parser, cookie, cookie-signature, serve-static, send, router, qs, mime-types, etag, fresh, vary, proxy-addr, accepts and others. Each is a small focused package, which is why the framework stays maintainable, and also why the transitive surface of a hello-world Express app is wide. Body parsing and static file serving are not built in as monoliths; they are dependencies Express wires for you, and you can reach for the same packages directly. For a security-minded team this cuts both ways. You get a small, auditable core and well-scoped dependencies, but you are also accepting the security posture of every one of those thirty packages on each upgrade, and the project has a security policy and policy page because of that exposure.

## Version 5 is a deprecation-driven rewrite, not a feature release

The release list shows the current line clearly: v5.2.1 and v5.2.0 landed in December 2025, and v4.22.2 followed in May 2026, so both majors are still receiving patches. The v5 change was mostly a subtraction. Express 4 deprecated a set of behaviours over several majors, and 5 removed them, which is why the README pushes a migration guide to v5 as a tip before anything else. The practical consequence is a codebase difference, not just a version number. Code written against Express 4 idioms, especially around removed callbacks and path patterns, can change behaviour or fail on 5, so the upgrade is a real task with a real test pass rather than a version bump. The homepage, expressjs.com, carries that guide, and the GitHub Discussions space is where the project says development and usage questions belong.

## Generating a project is a separate generator package you install globally

The quick-start path does not use the express module directly. It installs a separate executable, express-generator, and the README warns that the executable's major version must match Express's:

```bash
npm install -g express-generator@4
```

It then creates and enters a project, installs its dependencies, and starts it:

```bash
express /tmp/foo && cd /tmp/foo
npm install
npm start
```

The server then answers on localhost:3000. Two things are worth noticing. You install the generator globally, on the machine, separate from any project's own dependencies, which is a global mutable dependency in your toolchain. And the version coupling is manual: install the generator whose major matches the Express major you intend to use, or the scaffold and the framework drift apart. This generator is the fastest route to a running server, but it is a convenience that lives outside your project's lockfile, so a team that values reproducible installs will often start from the plain module and add express-generator only for throwaway prototypes.

## The template engine story is delegated to consolidate, not shipped

Express's stated philosophy is that it provides small, dependable tooling for HTTP servers and does not force a specific ORM or template engine, and it says you can craft your own framework on top. Template support goes through @ladjs/consolidate, which is what lets one codebase drive 14+ template engines rather than picking one. The feature list makes the same promise from the other side, promising a view system supporting 14+ template engines. The consequence is a split responsibility you have to own. Express resolves the view and hands you the data, but the engine, the layout, the escaping rules, and the asset pipeline all sit outside it. A team that expected a batteries-included view layer, the way Rails or Django provide one, will find that Express has given them a lookup table and left the rest to them, and that is by design rather than a gap.

## Contributing means the usual governance, security policy and test suite

The project runs a formal open-source process. The README welcomes contributions from code, documentation and tests to triaging issues, and points to a Contributing Guide and a Code of Conduct. Security vulnerabilities have their own path through the repository's security policy rather than the public issue tracker, which is the correct channel and worth knowing before you report anything. Running the test suite locally is documented in two steps, installing dependencies and then running the tests, both ordinary npm commands. Governance is published off the repository, in GOVERNANCE.md on the Discussions site, and the README credits the original author, TJ Holowaychuk, alongside a named technical committee and a broader triagers group. For a project this old and this depended on, that public process is part of the reason to trust it, and it is also why contributions and security reports have a defined route rather than a maintainer's inbox.

## Conclusion

Express is the right pick for a public HTTP API, a single-page app's backend, or a hybrid where you want routing and nothing else, and the 5.x line is the one to start on given the migration guide the README points at. Skip it when you need conventions handed to you, because the framework's stated position is that it does not force an ORM or a template engine and you assemble that layer yourself. The one thing to verify before committing is the middleware story: the 30-plus dependencies in package.json are the floor you inherit, and routing behaviour changed between 4 and 5, so read the v5 migration guide rather than copying 4-era snippets.

## FAQ

### What is Express used for?

Express is used as small, dependable HTTP tooling for Node.js servers, and the README names single page applications, websites, hybrids and public HTTP APIs as the fits. It is a minimalist web framework, not a full stack, so it supplies routing, middleware and HTTP helpers while you choose the ORM and template engine.

### How does Express work?

You create an app, register routes with methods like app.get that map a path to a handler receiving (req, res), and call app.listen on a port. Middleware functions compose in the order they are registered, and the framework decides which handler runs for each request.

### how to install express js

First install Node.js, which the README says must be version 18 or higher, and create a package.json with npm init if the project is new. Then install the module from npm with npm install express, or scaffold a whole app with the express-generator executable.

### how to install express in node js

Express is a Node.js module on the npm registry, so you install it inside a project that already has a package.json using npm install express. Node 18 or higher is required. The homepage at expressjs.com carries the full installing guide.

## Sources

- [Official documentation](https://expressjs.com)
- [Official README](https://github.com/expressjs/express#readme)
- [Project repository](https://github.com/expressjs/express)
- [Release notes](https://github.com/expressjs/express/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/expressjs-express