5 ms·

> It's something that works most of the time, but sometimes breaks when the callback code isn't what the promisify function expected. The sounds like a limitat

by mayank 10y ago

> It's something that works most of the time, but sometimes breaks when the callback code isn't what the promisify function expected. The sounds like a limitation of promisify, not inherently of callbacks. There are many situations and styles where callbacks are perfectly adequate, and promises offer no benefit, so referring to it as the "old callback style" may be a bit premature.

egeozcan 10y ago
> There are many situations and styles where callbacks are perfectly adequate, and promises offer no benefit Promises are superior in general, I guess that has been discussed already[1], many times. Promises may indeed offer just an insignificant benefit sometimes (you can even call it just a different style), for example when you are first writing a monolithic prototype. In this worst case, you would simply make a giant chain of ".then" methods, any your gain is you can get creative with the error handling if you want. However, the greatest benefit revels itself later: The composability that comes with them will help you immensely when refactoring. [1]: One example: http://softwareengineering.stackexchange.com/a/302456/9451 http://softwareengineering.stackexchange.com/a/302456/9451 Another: http://blog.parse.com/learn/engineering/whats-so-great-about-javascript-promises/ http://blog.parse.com/learn/engineering/whats-so-great-about...
- jborica 10y ago
  Promises are not superior in general. There is a significant performance hit that, in some problem areas, absolutely should not be ignored. Neither of those links claims that promises are superior in general. They provide additional, valuable features, but with tradeoffs.
  - egeozcan 10y ago
    Well, I stand corrected. Yes, there definitely is a performance penalty for promises. Performance may be a tradeoff for the current engines, but I'm optimistic that it will be optimized away as it doesn't add too much semantics over the callbacks. Maybe error handling is tricky. I would say they are superior to callbacks as object-oriented code is to procedural code - that also has some performance cost in many engines. But, you are saying tradeoffs - plural. I, as an experienced web developer, am sincerely curious what any other can be?
    - inimino 10y ago
      > as object-oriented code is to procedural code That is not a universally-accepted statement either. I'm not interested in taking sides here, only pointing out that there are a wider variety of extant opinions than you seem to realize.
      - egeozcan 10y ago
        That was exactly my point. Object-oriented code is conceptualized as a next step but there are indeed cases where you would be better off procedural and there are many people who like procedural just better. Maybe it's my poor English, would this be more clear: Promises are as superior as to callbacks as object-oriented code is to procedural code. (Ok now it's not very readable :) )

by mayank 10y ago

egeozcan 10y ago

> There are many situations and styles where callbacks are perfectly adequate, and promises offer no benefit Promises are superior in general, I guess that has been discussed already[1], many times. Promises may indeed offer just an insignificant benefit sometimes (you can even call it just a different style), for example when you are first writing a monolithic prototype. In this worst case, you would simply make a giant chain of ".then" methods, any your gain is you can get creative with the error handling if you want. However, the greatest benefit revels itself later: The composability that comes with them will help you immensely when refactoring. [1]: One example: http://softwareengineering.stackexchange.com/a/302456/9451 http://softwareengineering.stackexchange.com/a/302456/9451 Another: http://blog.parse.com/learn/engineering/whats-so-great-about-javascript-promises/ http://blog.parse.com/learn/engineering/whats-so-great-about...

jborica 10y ago
Promises are not superior in general. There is a significant performance hit that, in some problem areas, absolutely should not be ignored. Neither of those links claims that promises are superior in general. They provide additional, valuable features, but with tradeoffs.
- egeozcan 10y ago
  Well, I stand corrected. Yes, there definitely is a performance penalty for promises. Performance may be a tradeoff for the current engines, but I'm optimistic that it will be optimized away as it doesn't add too much semantics over the callbacks. Maybe error handling is tricky. I would say they are superior to callbacks as object-oriented code is to procedural code - that also has some performance cost in many engines. But, you are saying tradeoffs - plural. I, as an experienced web developer, am sincerely curious what any other can be?
  - inimino 10y ago
    > as object-oriented code is to procedural code That is not a universally-accepted statement either. I'm not interested in taking sides here, only pointing out that there are a wider variety of extant opinions than you seem to realize.
    - egeozcan 10y ago
      That was exactly my point. Object-oriented code is conceptualized as a next step but there are indeed cases where you would be better off procedural and there are many people who like procedural just better. Maybe it's my poor English, would this be more clear: Promises are as superior as to callbacks as object-oriented code is to procedural code. (Ok now it's not very readable :) )