3 ms·

>That’s getting pretty ridiculous...but because of the way promise chaining works, the code can now be much flatter. In what way is the indented code ridiculou

>That’s getting pretty ridiculous...but because of the way promise chaining works, the code can now be much flatter. In what way is the indented code ridiculous, and why is flatter better? Conceptually, you still have to think of the callbacks operating the same way in order to properly understand the code. Flattening it out and changing the shape so that it isn't nested doesn't really help change what is going on. Maybe I'm missing the bigger picture.

rektide 14y ago
Indenting is a symptom of having to write code structurally, having to tightly couple call side with it's handler. Promises break that structural linkage: we have the only thing in JS that matters, an object, a first class plain old object, that we can reason with and perform operations on as if it were any other object. It happens to be an object about a future which will one day resolve, but it's just an object. And because it's an object that can, after it's inception, have handlers added to it, we break the necessary structural linkage that callbacks mandate: we can make callbacks latter, we can condition what callbacks to attach, we can compose or chain more promises after our first promise and put our handler on that... we have a first class thing to work with, not just a function, which expects a fully-readied handler. It defers the need to define handling. Read more of my comments to get a better sense of why A) I adore promises B) I feel this article is injurous to the case for promises.
- jessaustin 14y ago
  this article is injurous to the case for promises. Haha I thought the same about the Crockford talk. Can you point me to a non-injurious source?
  - jasondenizac 14y ago
    see also: https://gist.github.com/3889970 https://gist.github.com/3889970
steveklabnik 14y ago
It might not matter to you with two levels, but once you get to three levels of nesting, I bet it'd be more clear how much nicer the flat version is. > you still have to think of the callbacks operating the same way in order to properly understand the code. It depends on your conception. ;) Maybe it's my Haskell/monad experience, but to me, there's a difference between "here's the control flow between these bits of computation" and "where does this level of nesting end, again?"
jessaustin 14y ago
I'll echo what rektide said, but add that the flat code is easier to modify. It's easy to add another promise anywhere in the flat chain, and it's easy to add conditional logic if you need to. In addition, I think we'll see easy-to-reason-about operators built on top of the promise "primitive" that you couldn't even imagine for the nested code.

rektide 14y ago

Indenting is a symptom of having to write code structurally, having to tightly couple call side with it's handler. Promises break that structural linkage: we have the only thing in JS that matters, an object, a first class plain old object, that we can reason with and perform operations on as if it were any other object. It happens to be an object about a future which will one day resolve, but it's just an object. And because it's an object that can, after it's inception, have handlers added to it, we break the necessary structural linkage that callbacks mandate: we can make callbacks latter, we can condition what callbacks to attach, we can compose or chain more promises after our first promise and put our handler on that... we have a first class thing to work with, not just a function, which expects a fully-readied handler. It defers the need to define handling. Read more of my comments to get a better sense of why A) I adore promises B) I feel this article is injurous to the case for promises.

jessaustin 14y ago
this article is injurous to the case for promises. Haha I thought the same about the Crockford talk. Can you point me to a non-injurious source?
- jasondenizac 14y ago
  see also: https://gist.github.com/3889970 https://gist.github.com/3889970

steveklabnik 14y ago

It might not matter to you with two levels, but once you get to three levels of nesting, I bet it'd be more clear how much nicer the flat version is. > you still have to think of the callbacks operating the same way in order to properly understand the code. It depends on your conception. ;) Maybe it's my Haskell/monad experience, but to me, there's a difference between "here's the control flow between these bits of computation" and "where does this level of nesting end, again?"

jessaustin 14y ago

I'll echo what rektide said, but add that the flat code is easier to modify. It's easy to add another promise anywhere in the flat chain, and it's easy to add conditional logic if you need to. In addition, I think we'll see easy-to-reason-about operators built on top of the promise "primitive" that you couldn't even imagine for the nested code.