Hacker News Reader

Comment by platz | Hacker News Reader

This is great for one's own projects, but if creating something for more than one's immediate project (i.e. libraries), it forces everyone else to adopt the same style.

Maybe those other projects are also using other libraries that don't use promises, so now there is a problem. Do you wrap the other library in promises too, if that is even a viable option for you?

Colorness is a problem for the whole ecosystem too.

View on HN

Promise is the best thing an async library method could return because it's always trivial to convert into anything you want (callback, stream, async/await, yield whatever you want) because it's the only thing that's standardized. However, nobody gets the callback contract (https://gist.github.com/CrabDude/10907185) right. Even node core gets the callback contract wrong in different ways in its different APIs.

In practice however most library callback apis resemble the callback contract enough so that one-line promise-wrapping of the entire library is possible.

Maybe I didn't get this across in my original comment, but my primary job is open source software. So I spend ~40h/week working on public projects that are not all my own. I spend tons of time contributing to other peoples' projects, and I authored and maintain a significant number of libraries that are used by other developers.

What I was saying is that it does work. I can use dependencies with no problems no matter what they expose by coercing to promises internally, and have had no complaints about my libraries' APIs use of promises.

I agree that colorness is a problem, but there are also fantastic libraries that handle easier conversion between most of the common styles. For example, `bluebird` promises allow you to swap between error first callbacks in both directions with `promisify` and `Promise.nodeify`.

Reply on news.ycombinator.com