3 ms·

Yup. I actually adore promises, but I don't buy the decoupling argument at all. And the thing I keep seeing about how promises let you decide what to do with th

Yup. I actually adore promises, but I don't buy the decoupling argument at all. And the thing I keep seeing about how promises let you decide what to do with the data after you make the call as opposed to before seems...totally silly, since I had to make that decision when I wrote the code.

sanderjd 13y ago
When people say "later", they don't mean in human time, they mean in program execution time. As in, your program can decide based on the dynamic state of the system how (or even whether) to use the resolved value. In my experience, that is not nearly as convenient to do with callbacks as it is with promises.
- icambron 13y ago
  Later in that sense isn't usually very useful, since if the promise isn't resolved, there's no new information about the state of the system. Where I think promises help is that they allow to express the concept of "do stuff later" in a cleaner, more extensible way. It's really just about having a nicer interface (you can even ask it questions like, "what's been done?"). But the part where you decide what the promise will do after you specify what it's a promise for isn't, in my view, an important detail.
  - sanderjd 13y ago
    I think we actually agree. Deciding "later" to do nothing is exactly the type of decision I'm talking about.
- ollysb 13y ago
  ember-data is a great example of why promises can be useful. When a view is loaded you query your server for the model(via ember-data's api), but at this point what you get is a graph of unresolved promises. It then gets passed through to the controllers/templates etc. which render immediately but are then updated automatically as soon as the promises resolve. This is the real value of promises, you can pass them around your app before they're resolved.
  - sanderjd 13y ago
    Yep, doing much the same thing in angularjs as we speak. It works very nicely and would have been a pain with only callbacks.
  - tyleregeto 13y ago
    (Note: I haven't worked with Ember, and this probably doesn't jive with how they do things) This sounds a lot like traditional async Model/View programming. I've traditionally passed a model around, and use subscriptions to listen for "data." That has the added benefit of being reusable, with the model dispatching change events. Promises in this case sound like they are fulfilling a similar role by your description.

sanderjd 13y ago

When people say "later", they don't mean in human time, they mean in program execution time. As in, your program can decide based on the dynamic state of the system how (or even whether) to use the resolved value. In my experience, that is not nearly as convenient to do with callbacks as it is with promises.

icambron 13y ago
Later in that sense isn't usually very useful, since if the promise isn't resolved, there's no new information about the state of the system. Where I think promises help is that they allow to express the concept of "do stuff later" in a cleaner, more extensible way. It's really just about having a nicer interface (you can even ask it questions like, "what's been done?"). But the part where you decide what the promise will do after you specify what it's a promise for isn't, in my view, an important detail.
- sanderjd 13y ago
  I think we actually agree. Deciding "later" to do nothing is exactly the type of decision I'm talking about.
ollysb 13y ago
ember-data is a great example of why promises can be useful. When a view is loaded you query your server for the model(via ember-data's api), but at this point what you get is a graph of unresolved promises. It then gets passed through to the controllers/templates etc. which render immediately but are then updated automatically as soon as the promises resolve. This is the real value of promises, you can pass them around your app before they're resolved.
- sanderjd 13y ago
  Yep, doing much the same thing in angularjs as we speak. It works very nicely and would have been a pain with only callbacks.
- tyleregeto 13y ago
  (Note: I haven't worked with Ember, and this probably doesn't jive with how they do things) This sounds a lot like traditional async Model/View programming. I've traditionally passed a model around, and use subscriptions to listen for "data." That has the added benefit of being reusable, with the model dispatching change events. Promises in this case sound like they are fulfilling a similar role by your description.