NylonMeltdown's comments

Except that an attacker can modify the ssh config to enable session multiplexing with a long timeout and then piggy-back off that connection, right?

> I'm surprised they're dropping windows/arm considering that seems to be the direction things are moving in.

Note that windows/arm64 is still supported. Not sure if 32 bit arm was ever relevant on Windows.

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.

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.

I'll second `fastifiy` or `koa`.