Maybe it's still standard, but if you don't want to shoot yourself in the foot, just stay away from it.
Express's API is horrible. It's not integrated with Promises (async/await) at all, so be prepared to wrap every async endpoint (so probably all of them) with a custom error handling wrapper. If you don't (and don't have a big catch-block around the whole implementation), an unhandled error will hang the connection forever without a response.
Also, the API makes it pretty much impossible to write "wrapping" middleware, for example if you want output validation. As soon as an express middleware calls `next`, it's done and there's no way intercepting it before a response is sent.
It also still doesn't support Node's HTTP2, just some (nowadays) weird third-party HTTP2 implementation.
The standard `compression` middleware also seems abandoned, not supporting brotli (so you'll have worse loading times), despite Node.js natively providing the required functions for years.
The thing is, express's foot guns are well known and well documented, and you basically just enumerated them. If you pick another framework then you'll be left exploring its footguns on your own. That may or may not be worth it to you, but it's not obvious to me that choosing the well-known framework is a worse choice than choosing the ones that try to solve its problems but don't yet have the rough edges discovered and documented.
I think there's a slight difference between doing something that nobody's ever done before and just choosing a less travelled path. In any case, I'd rather not use the tool with well-known foot-guns, hoping that all developers in the project (and future ones!) do know these foot-guns as well.
I'd rather chose a tool with less foot-guns (or if not possible: provide easy workarounds that are consistenly used). With the design-flaws of express (no fault to it, since it predates standardised Promises by more than 5 years) and the availability of a simple and sane evolution of its API (koa), I really don't get why so many still cling to express.
I consider Koa to be a sensible evolution of express (even by the some of the authors).
Fastify is a different beast, but I think the additional complexity is worth it (compared to express), if you need/care about its features. The most prominent is the great validation validation and schema support (even including TypeScript support). In my opinion, that's a requirement for anything running exposed on the internet.
For a tiny toy project, I'd rather use koa or a plain Node.js http.Server. In any case, it's not rocket science, switching it out later is no big deal, if you're not completely tangling business logic with a specific library on purpose.
Express's API is horrible. It's not integrated with Promises (async/await) at all, so be prepared to wrap every async endpoint (so probably all of them) with a custom error handling wrapper. If you don't (and don't have a big catch-block around the whole implementation), an unhandled error will hang the connection forever without a response.
Also, the API makes it pretty much impossible to write "wrapping" middleware, for example if you want output validation. As soon as an express middleware calls `next`, it's done and there's no way intercepting it before a response is sent.
It also still doesn't support Node's HTTP2, just some (nowadays) weird third-party HTTP2 implementation.
The standard `compression` middleware also seems abandoned, not supporting brotli (so you'll have worse loading times), despite Node.js natively providing the required functions for years.
I'll second `fastifiy` or `koa`.