Compare Express 5 and Hono for an Express Project

The agent clones the repository into its own sandbox and reads what a port would have to carry. In an Express app like gothinkster/node-express-realworld-example-app, package.json pins express at ~4.18.1 with body-parser, cors and express-jwt, Prisma 4 against Postgres (src/prisma/schema.prisma), Jest 29 with ts-jest, and Nx 17 driving build, serve and test. The module the prompt names is the article routes: src/app/routes/article/article.controller.ts registers 11 handlers on one Router, from GET /articles with offset, limit, tag, author and favorited query parameters to the comment and favorite routes, and calls into the 652-line article.service.ts.

Before porting anything it records a baseline on the default branch. It starts Postgres in the sandbox, applies the migrations in src/prisma/migrations, runs the seed from src/prisma/seed.ts, and runs npx nx test. That suite matters for the comparison: the Jest tests in src/tests/services/ replace Prisma with jest-mock-extended and test the service functions, so they never touch the router. A port that breaks routing would still pass them. So the agent writes one set of HTTP tests against the running server for the article routes (list, feed, get by slug, create, update, delete, favorite, comments), runs them on the baseline, and uses the same file on both branches. It also notes that e2e/src/server/server.spec.ts expects { message: 'Hello API' } while src/main.ts answers { status: 'API is running on /api' }, so that test fails before any change and counts against neither port.

The Express 5 branch is the smaller change, and the agent lists each edit it needed. Express 5 forwards a rejected promise from an async handler to the error middleware, so the try { … } catch (error) { next(error) } blocks in every handler can go. req.query becomes a getter, path syntax moves to path-to-regexp 8, and express-jwt must still produce the UnauthorizedError that src/main.ts turns into a 401. The Hono branch rewrites the controller as a Hono app mounted at /api, swaps cors and body-parser for Hono's own middleware, and replaces express-jwt with a JWT check that keeps getTokenFromHeaders in src/app/routes/auth/auth.ts working, because that helper accepts both Token and Bearer prefixes and RealWorld clients send Token. Since only the article routes move, the Hono branch serves them beside the remaining Express routers, and the agent says how it joined the two.

Then it measures the same things on the baseline and both branches: the shared HTTP tests, npx nx build, lines changed from git diff --stat, and a short load test with a tool such as autocannon against GET /api/articles and one authenticated route, with the same seeded data, connection count and duration on each. Each number in the report is from a command in the run's transcript. Both branches stay in the sandbox; nothing is pushed.

What comes back is comparison.md, a file on the session with a download link that works for an hour. It has a table with one column each for the baseline, Express 5 and Hono, and rows for lines changed, files touched, the HTTP test results, the Jest results, the build result, and the benchmark's requests per second and latency percentiles. Under the table, each port has a list of the changes it needed and why, so the size of the diff can be read as work rather than as a number.

The trade-offs section is where the run earns its keep: what each option did to error handling, authentication and middleware in this codebase, which dependencies each one dropped or needed, and anything the agent had to work around. The session's transcript keeps every command it ran, including each benchmark with its full output, so the numbers can be checked or re-run.

Before deciding, a reviewer checks that the benchmark settings were the same across the three columns, that the HTTP tests covered the routes the team cares about, and that the Hono branch's mixing with Express is acceptable as a temporary state or would need the rest of the routers ported too. To take the next step, send the same session a follow-up asking it to open a pull request from the branch you chose; the sandbox wakes with both branches still on its disk.

A comparison like this goes stale when either side ships a major version. Have a job on your server watch the release feeds you care about and send this request when one appears, with an Idempotency-Key built from the version so one release starts one run.

Set a webhook URL on the API key, and Rush POSTs run.completed with the session_url when the run finishes. Your server attaches the new comparison.md to the architecture decision it informs, so the record shows how the numbers moved between releases.

A fair spike needs a database, a seeded dataset, three checkouts and a benchmark that is not competing with an editor, a browser and a dev server. In a Rush sandbox the agent gets a machine of its own for it: Postgres, the seed, both branches and the load tests run there, and nothing on your laptop changes.

What makes the write-up trustworthy is that the claims come with their commands. Every row in the table points back to a step in the transcript with its output, so the comparison can be argued about on the evidence. You can run the same request on several services at once, one run each, up to the key's concurrent run limit, and compare the reports side by side.

Will the agent change my repository?

Why port only one module instead of the whole app?

Are the benchmark numbers meaningful?

Can I compare Express 5 with Fastify instead?