Node is fine (and improving), but Express, or any of the many other libraries with similar APIs, is full of footguns:
- The base request-response cycle is ridiculously dynamic: the void-returning-callback API + stateful response object makes debugging a nightmare.
- Then there’s middlewares: they can come from anywhere, do anything anywhere in the call stack. They create complex webs of implicit coupling you can’t see, can’t find with static analysis, and can’t know if they’re changed or removed.
- You can add static types to address some of the above, but you cannot have any real confidence that the types reflect the actual presence or behavior of anything. It’s all just type assertions out of thin air.
- It’s routers all the way down; if you so much as nest one on a subpath, you have footguns squared.
- Maybe more specific to Express than the overall design, an absurd set of the request/response property names are very wrong, and get wronger in common setups.
It’s possible to address all of these without leaving Node (and I have!), but you’ll end up with a radically different API. It’ll be a better API, but it’ll also create friction for the unfamiliar, at least up front.
No direct experience, but the fact that route handlers return responses is a good sign. Both look like they have some of the request-mutation type of footguns.
For example, it's wrong if my back end is Java. Or Python. Or .Net. Or an exotic high performance database that serves JSON. Or anything that already works and I have no reason to replace or hobble with a new JS middleman at great cost.
- The base request-response cycle is ridiculously dynamic: the void-returning-callback API + stateful response object makes debugging a nightmare.
- Then there’s middlewares: they can come from anywhere, do anything anywhere in the call stack. They create complex webs of implicit coupling you can’t see, can’t find with static analysis, and can’t know if they’re changed or removed.
- You can add static types to address some of the above, but you cannot have any real confidence that the types reflect the actual presence or behavior of anything. It’s all just type assertions out of thin air.
- It’s routers all the way down; if you so much as nest one on a subpath, you have footguns squared.
- Maybe more specific to Express than the overall design, an absurd set of the request/response property names are very wrong, and get wronger in common setups.
It’s possible to address all of these without leaving Node (and I have!), but you’ll end up with a radically different API. It’ll be a better API, but it’ll also create friction for the unfamiliar, at least up front.