4 ms·

I'm glad to hear he (and the Node community in general) has come back around to promises. I remember the very early version of Node.js that had them (looks lik

I'm glad to hear he (and the Node community in general) has come back around to promises. I remember the very early version of Node.js that had them (looks like they were added in v0.1.0 and removed in v0.1.30), although they weren't true chainable promises we have now.

jonny_eh 8y ago
I find it really bizarre that Node still doesn't have full promisified built-in libraries. It's not like it'd break existing APIs.
- dvlsg 8y ago
  I think they're testing natively provided promise APIs with the fs module. https://github.com/nodejs/node/pull/18297 https://github.com/nodejs/node/pull/18297 It's of course not a full promisification of every built in, but it looks like theyre at least trying it out.
- tlrobinson 8y ago
  Node 10 has fs, at least: require("fs").promises.readdir(".").then(console.log)
  - jonny_eh 8y ago
    Why not just: require("fs").readdir(".").then(console.log)
    - tlrobinson 8y ago
      That's the legacy callback version. In practice you'd probably do: const fs = require("fs").promises; // ... fs.readdir(".").then(console.log);
      - kjeetgill 8y ago
        Ah, thats pretty nice. The previous example was pretty janky but I didn't foresee it being used like this. Eyes opened.
    - salehenrahman 8y ago
      It can potentially break things. There are legacy code that assume that calling `readdir` will yield undefined, and will have just passed that result to a function, that alters its behaviour based on whether a parameter is undefined.
      - jonny_eh 8y ago
        Interesting. Seems like a great opportunity for a major version bump.
BenoitEssiambre 8y ago
Dear god no. Promises are ruining the best thing node had going for it: Its beautiful lisp like async model. Promises add hidden state, corner cases and incompatible libraries for very little gain.
- tree_of_item 8y ago
  Can you explain why you think Lisp is involved here?
  - BenoitEssiambre 8y ago
    Just how easy JavaScript, like lisp, makes it to pass around pure anonymous functions and make good use of closures (if you are willing to tolerate a few brackets). Promises had to ruin it by wrapping functions into stateful objects. Really the best case I found against Promises comes from, believe it or not, the pro promise chapter of a book: https://github.com/getify/You-Dont-Know-JS/blob/master/async%20%26%20performance/ch3.md https://github.com/getify/You-Dont-Know-JS/blob/master/async... I really don't understand how the author managed to view the things he described as positives. Just the length of the chapter is a testament to how overly complex promises are. On top of bringing in a ton of jargon such as "thenable", "rejection", "fullfilment", "future value" (I think the author means you are guaranteed a nextTick whooptidoo), "uninversion of control", "revealing constructor", it admits that promises do not solve most of the issues mentioned about callbacks in the previous chapter and often makes things fail in more subtle ways. It describes how you have to manually call things like Promise.race() to solve some of the problems hardly making things more automatic then callbacks. He talks about "Thenable Duck Typing" saying horrifying things such as "Given that Promises are constructed by the new Promise(..) syntax, you might think that p instanceof Promise would be an acceptable check. But unfortunately, there are a number of reasons that's not totally sufficient. Mainly, you can receive a Promise value from another browser window (iframe, etc.), which would have its own Promise different from the one in the current window/frame, and that check would fail to identify the Promise instance. Moreover, a library or framework may choose to vend its own Promises and not use the native ES6 Promise implementation to do so. " and "The standards decision to hijack the previously nonreserved -- and completely general-purpose sounding -- then property name means that no value (or any of its delegates), either past, present, or future, can have a then(..) function present, either on purpose or by accident, or that value will be confused for a thenable in Promises systems, which will probably create bugs that are really hard to track down." He praises immutability but ignores the fact that promises add mutable hidden state between your call and callback. He mentions that promises can silently swallow errors and calls it the "Pit of Despair". There is much more. Read the chapter. Pit of despair indeed. Callbacks are so much simpler and beautiful: https://medium.com/@b.essiambre/continuation-passing-style-patterns-for-javascript-5528449d3070 https://medium.com/@b.essiambre/continuation-passing-style-p...

jonny_eh 8y ago

I find it really bizarre that Node still doesn't have full promisified built-in libraries. It's not like it'd break existing APIs.

dvlsg 8y ago
I think they're testing natively provided promise APIs with the fs module. https://github.com/nodejs/node/pull/18297 https://github.com/nodejs/node/pull/18297 It's of course not a full promisification of every built in, but it looks like theyre at least trying it out.
tlrobinson 8y ago
Node 10 has fs, at least: require("fs").promises.readdir(".").then(console.log)
- jonny_eh 8y ago
  Why not just: require("fs").readdir(".").then(console.log)
  - tlrobinson 8y ago
    That's the legacy callback version. In practice you'd probably do: const fs = require("fs").promises; // ... fs.readdir(".").then(console.log);
    - kjeetgill 8y ago
      Ah, thats pretty nice. The previous example was pretty janky but I didn't foresee it being used like this. Eyes opened.
  - salehenrahman 8y ago
    It can potentially break things. There are legacy code that assume that calling `readdir` will yield undefined, and will have just passed that result to a function, that alters its behaviour based on whether a parameter is undefined.
    - jonny_eh 8y ago
      Interesting. Seems like a great opportunity for a major version bump.

BenoitEssiambre 8y ago

Dear god no. Promises are ruining the best thing node had going for it: Its beautiful lisp like async model. Promises add hidden state, corner cases and incompatible libraries for very little gain.

tree_of_item 8y ago
Can you explain why you think Lisp is involved here?
- BenoitEssiambre 8y ago
  Just how easy JavaScript, like lisp, makes it to pass around pure anonymous functions and make good use of closures (if you are willing to tolerate a few brackets). Promises had to ruin it by wrapping functions into stateful objects. Really the best case I found against Promises comes from, believe it or not, the pro promise chapter of a book: https://github.com/getify/You-Dont-Know-JS/blob/master/async%20%26%20performance/ch3.md https://github.com/getify/You-Dont-Know-JS/blob/master/async... I really don't understand how the author managed to view the things he described as positives. Just the length of the chapter is a testament to how overly complex promises are. On top of bringing in a ton of jargon such as "thenable", "rejection", "fullfilment", "future value" (I think the author means you are guaranteed a nextTick whooptidoo), "uninversion of control", "revealing constructor", it admits that promises do not solve most of the issues mentioned about callbacks in the previous chapter and often makes things fail in more subtle ways. It describes how you have to manually call things like Promise.race() to solve some of the problems hardly making things more automatic then callbacks. He talks about "Thenable Duck Typing" saying horrifying things such as "Given that Promises are constructed by the new Promise(..) syntax, you might think that p instanceof Promise would be an acceptable check. But unfortunately, there are a number of reasons that's not totally sufficient. Mainly, you can receive a Promise value from another browser window (iframe, etc.), which would have its own Promise different from the one in the current window/frame, and that check would fail to identify the Promise instance. Moreover, a library or framework may choose to vend its own Promises and not use the native ES6 Promise implementation to do so. " and "The standards decision to hijack the previously nonreserved -- and completely general-purpose sounding -- then property name means that no value (or any of its delegates), either past, present, or future, can have a then(..) function present, either on purpose or by accident, or that value will be confused for a thenable in Promises systems, which will probably create bugs that are really hard to track down." He praises immutability but ignores the fact that promises add mutable hidden state between your call and callback. He mentions that promises can silently swallow errors and calls it the "Pit of Despair". There is much more. Read the chapter. Pit of despair indeed. Callbacks are so much simpler and beautiful: https://medium.com/@b.essiambre/continuation-passing-style-patterns-for-javascript-5528449d3070 https://medium.com/@b.essiambre/continuation-passing-style-p...