5 ms·

Who cares how old something is, if it works well, why not use it? You can easily avoid callback-hell by making the callback you pass in to expressjs async and u

Who cares how old something is, if it works well, why not use it? You can easily avoid callback-hell by making the callback you pass in to expressjs async and use await inside of it, without much drawbacks. Just because the first closure into express is a callback doesn't mean you need to use callbacks everywhere, just use await/generators/whatever you want in your application code. expressjs at this point is battle-tested, minimal, easy to understand (both in usage and internals) and have a huge community still. It's very mature and does what it does well.

tshaddox 4y ago
> You can easily avoid callback-hell by making the callback you pass in to expressjs async and use await inside of it, without much drawbacks. I thought this was slightly awkward due to error handling, but it looks like Express 5 (in beta) supports async callbacks natively.
- aobdev 4y ago
  I'm sorry to point out that the first 5.0 alpha came out in 2014 and still hasn't been released. When people talk about the ecosystem/battle-tested-ness/quality of express I think that unfortunately doesn't extend to anything other than the latest major on npm. It's not "modern" but it's still a good tool.
cantaloa 4y ago
I haven't used Express in ten years, but imo `async (req, res, next) => ...` would mainly be attractive if failure was automatically handled and you could `await next()` to post-process the response. Though it would still help you write async code inside that route. Since iirc you send responses directly from handlers in Express, I'm not sure the latter is possible even with express-promise-router since you basically need downstream routes/middleware to return a Response object rather than send it directly. I think Express is never going to unify with Koa's direction since it's just too disruptive to Express' ecosystem (the v5.x branch is stale) which is probably for the best.
patdx 4y ago
The big problem is Express code like the following will either hang the HTTP request forever (--unhandled-rejections=warn), until the client times out and gives up, or crash your whole server, taking down any other HTTP requests in progress (--unhandled-rejections=throw): const db = { async getUsers() { throw new Error("failed to connect to database"); }, }; app.get("/", async (req, res) => { const result = await db.getUsers(); return result; }); There are various monkey patches/wrappers you can use to make async errors work the same as sync errors, but it is easy to forget and hard to understand, especially for newbies. Many other frameworks handle async/sync errors in a more consistent way.
- cipheredStones 4y ago
  Already fixed in Express 5 (which is technically still in beta, but that just seems to be the maintainer being very conservative about a major release): https://expressjs.com/en/guide/error-handling.html https://expressjs.com/en/guide/error-handling.html > Starting with Express 5, route handlers and middleware that return a Promise will call next(value) automatically when they reject or throw an error. For example: > app.get('/user/:id', async (req, res, next) => { const user = await getUserById(req.params.id); res.send(user) }) > If getUserById throws an error or rejects, next will be called with either the thrown error or the rejected value. If no rejected value is provided, next will be called with a default Error object provided by the Express router.
  - re-thc 4y ago
    > which is technically still in beta, but that just seems to be the maintainer being very conservative about a major release There hasn't been a new beta in a long time. Last release about a year ago and then the 1 before that about 3 years ago. Not a very convincing beta.
    - cipheredStones 4y ago
      I'm not sure whether you mean "not very convincing" in the sense of "not reassuring that it works" or something else, but judging from users' comments on this issue about the release plans, it seems to work just fine: https://github.com/expressjs/express/issues/4920 https://github.com/expressjs/express/issues/4920 The maintainer said this three months ago in a comment on that issue: > Express 5 is pretty much completed at this point, and we're just finishing up the last code merges in upstream modules in order to bump the dependencies finally in the 5.0 branch.
re-thc 4y ago
> It's very mature and does what it does well. Is it? It performs slower than e.g. Fastify. Don't see how that's doing well. > Who cares how old something is, if it works well, why not use it? It doesn't. That's the whole point. Software is always evolving and I doubt it's even close to complete. There hasn't been meaningful updates to Express in a long time. Why do people use it and/or promote it as a standard?
- capableweb 4y ago
  > Is it? It performs slower than e.g. Fastify. Don't see how that's doing well. It's such a marginal difference when you consider real-life applications built with either express or Fastify though. Seldom is the actual bottleneck which HTTP library you use (unless you're at a really, really, really big scale), and more about how you structure your code, database and general architecture. I can count on one hand the number of times I've had to care deeply about the HTTP stack in order to optimize something, while I've probably had to optimize 100s of web products over the years, all done without touching the HTTP parts at all. > It doesn't. That's the whole point. Software is always evolving and I doubt it's even close to complete. There hasn't been meaningful updates to Express in a long time. Why do people use it and/or promote it as a standard? How to handle HTTP requests kind of doesn't. HTTP 1.1 continues to work, and will continue to be sufficient for at least 90% of all the use cases on the web for a long time. I know that the JS community generally suffers from "If it hasn't been updated in the last year, it's probably broken and not modern enough" syndrome, but some software actually end up being "finished" and good enough for the task at hand. What improvements could you actually add to express without breaking the API interface that millions of applications depend on? Sometimes stability is wanted and needed, and that's how you get mature software. Who wants to rewrite their application and architecture every time some library you happen to use decides to "improve" it?
  - re-thc 4y ago
    > How to handle HTTP requests kind of doesn't. HTTP 1.1 continues to work, and will continue to be sufficient for at least 90% of all the use cases on the web for a long time. If you take out your 386 and boot up Dos 3.1 it'll; continue to work too. Let's just not improve, right? > but some software actually end up being "finished" and good enough for the task at hand Like dead? Do you ever stop learning and growing? Are you "finished" too? There are new vulnerabilities, new compatibilities, existing bugs, different use cases, etc - you think it's finished = turning a blind eye. > It's such a marginal difference when you consider real-life applications built with either express or Fastify though. That's how we get Electron and everything become a resource hog. Oh it doesn't matter. Oh marginal difference. No don't recycle, don't do good for the environment and anything in life because it's all marginal. Why even reply? It's a marginal difference. No, we can do better and will.

tshaddox 4y ago

> You can easily avoid callback-hell by making the callback you pass in to expressjs async and use await inside of it, without much drawbacks. I thought this was slightly awkward due to error handling, but it looks like Express 5 (in beta) supports async callbacks natively.

aobdev 4y ago
I'm sorry to point out that the first 5.0 alpha came out in 2014 and still hasn't been released. When people talk about the ecosystem/battle-tested-ness/quality of express I think that unfortunately doesn't extend to anything other than the latest major on npm. It's not "modern" but it's still a good tool.

cantaloa 4y ago

I haven't used Express in ten years, but imo `async (req, res, next) => ...` would mainly be attractive if failure was automatically handled and you could `await next()` to post-process the response. Though it would still help you write async code inside that route. Since iirc you send responses directly from handlers in Express, I'm not sure the latter is possible even with express-promise-router since you basically need downstream routes/middleware to return a Response object rather than send it directly. I think Express is never going to unify with Koa's direction since it's just too disruptive to Express' ecosystem (the v5.x branch is stale) which is probably for the best.

patdx 4y ago

The big problem is Express code like the following will either hang the HTTP request forever (--unhandled-rejections=warn), until the client times out and gives up, or crash your whole server, taking down any other HTTP requests in progress (--unhandled-rejections=throw): const db = { async getUsers() { throw new Error("failed to connect to database"); }, }; app.get("/", async (req, res) => { const result = await db.getUsers(); return result; }); There are various monkey patches/wrappers you can use to make async errors work the same as sync errors, but it is easy to forget and hard to understand, especially for newbies. Many other frameworks handle async/sync errors in a more consistent way.

cipheredStones 4y ago
Already fixed in Express 5 (which is technically still in beta, but that just seems to be the maintainer being very conservative about a major release): https://expressjs.com/en/guide/error-handling.html https://expressjs.com/en/guide/error-handling.html > Starting with Express 5, route handlers and middleware that return a Promise will call next(value) automatically when they reject or throw an error. For example: > app.get('/user/:id', async (req, res, next) => { const user = await getUserById(req.params.id); res.send(user) }) > If getUserById throws an error or rejects, next will be called with either the thrown error or the rejected value. If no rejected value is provided, next will be called with a default Error object provided by the Express router.
- re-thc 4y ago
  > which is technically still in beta, but that just seems to be the maintainer being very conservative about a major release There hasn't been a new beta in a long time. Last release about a year ago and then the 1 before that about 3 years ago. Not a very convincing beta.
  - cipheredStones 4y ago
    I'm not sure whether you mean "not very convincing" in the sense of "not reassuring that it works" or something else, but judging from users' comments on this issue about the release plans, it seems to work just fine: https://github.com/expressjs/express/issues/4920 https://github.com/expressjs/express/issues/4920 The maintainer said this three months ago in a comment on that issue: > Express 5 is pretty much completed at this point, and we're just finishing up the last code merges in upstream modules in order to bump the dependencies finally in the 5.0 branch.

re-thc 4y ago

> It's very mature and does what it does well. Is it? It performs slower than e.g. Fastify. Don't see how that's doing well. > Who cares how old something is, if it works well, why not use it? It doesn't. That's the whole point. Software is always evolving and I doubt it's even close to complete. There hasn't been meaningful updates to Express in a long time. Why do people use it and/or promote it as a standard?

capableweb 4y ago
> Is it? It performs slower than e.g. Fastify. Don't see how that's doing well. It's such a marginal difference when you consider real-life applications built with either express or Fastify though. Seldom is the actual bottleneck which HTTP library you use (unless you're at a really, really, really big scale), and more about how you structure your code, database and general architecture. I can count on one hand the number of times I've had to care deeply about the HTTP stack in order to optimize something, while I've probably had to optimize 100s of web products over the years, all done without touching the HTTP parts at all. > It doesn't. That's the whole point. Software is always evolving and I doubt it's even close to complete. There hasn't been meaningful updates to Express in a long time. Why do people use it and/or promote it as a standard? How to handle HTTP requests kind of doesn't. HTTP 1.1 continues to work, and will continue to be sufficient for at least 90% of all the use cases on the web for a long time. I know that the JS community generally suffers from "If it hasn't been updated in the last year, it's probably broken and not modern enough" syndrome, but some software actually end up being "finished" and good enough for the task at hand. What improvements could you actually add to express without breaking the API interface that millions of applications depend on? Sometimes stability is wanted and needed, and that's how you get mature software. Who wants to rewrite their application and architecture every time some library you happen to use decides to "improve" it?
- re-thc 4y ago
  > How to handle HTTP requests kind of doesn't. HTTP 1.1 continues to work, and will continue to be sufficient for at least 90% of all the use cases on the web for a long time. If you take out your 386 and boot up Dos 3.1 it'll; continue to work too. Let's just not improve, right? > but some software actually end up being "finished" and good enough for the task at hand Like dead? Do you ever stop learning and growing? Are you "finished" too? There are new vulnerabilities, new compatibilities, existing bugs, different use cases, etc - you think it's finished = turning a blind eye. > It's such a marginal difference when you consider real-life applications built with either express or Fastify though. That's how we get Electron and everything become a resource hog. Oh it doesn't matter. Oh marginal difference. No don't recycle, don't do good for the environment and anything in life because it's all marginal. Why even reply? It's a marginal difference. No, we can do better and will.