3 ms·

Automatic promisification and the disposer pattern are both Bluebird-specific features that native ES6 promises don't support, so you'll have to continue using

Automatic promisification and the disposer pattern are both Bluebird-specific features that native ES6 promises don't support, so you'll have to continue using Bluebird if you rely on them. However, promises returned by Promises/A+ compliant libraries -- and this includes native ES6 promises -- are interoperable with each other. That means you can mix Bluebird promises with native promises for the most part. E.g, passing an ES6 promise to Bluebird's Promise.all will work just fine. This works up to a point, and breaks when you try to use a Bluebird-specific function that's expecting additional functionality to be attached to the promise object. I don't see why mixing Bluebird promises with ES6 promises would make anything slower. You shouldn't worry about this.

SparkyMcUnicorn 10y ago
Bluebird is faster than native promises as well. http://softwareengineering.stackexchange.com/questions/278778/why-are-native-es6-promises-slower-and-more-memory-intensive-than-bluebird http://softwareengineering.stackexchange.com/questions/27877...
gsathya_hn 10y ago
Native promises and bluebird use different microtask queues on Node which makes interop incorrect (which is also one of the reasons why bluebird is ES6 spec non compliant). See https://gist.github.com/anonymous/9936c695f2c29e79a0c1a0dec863abea https://gist.github.com/anonymous/9936c695f2c29e79a0c1a0dec8... This might lead to subtle ordering bugs, I would recommend against using both together. Using bluebird and native promises together may result in slower performance because V8 has fast paths for native promises which fail for bluebird.
- randallsquared 10y ago
  In what way is this incorrect? Those are three separate promises; no code can be correct that depends on whether one resolve() call finishes before an independently started resolve() call, right?
- Macha 10y ago
  If the ordering is important, then you should be using a() .then(()=>b()) .then(()=>c()) Assuming anything about the completion order of: a(): b(); c(); Where a, b and c are async tasks of any kind (be they classic old callbacks, Promises, Observables, whatever) is just asking for trouble. The whole point is that you don't care about when it finishes, you just want to know that it has finished. If the order is that important and you don't want to handle managing it, you should just write standard synchronous code.

SparkyMcUnicorn 10y ago

Bluebird is faster than native promises as well. http://softwareengineering.stackexchange.com/questions/278778/why-are-native-es6-promises-slower-and-more-memory-intensive-than-bluebird http://softwareengineering.stackexchange.com/questions/27877...

gsathya_hn 10y ago

Native promises and bluebird use different microtask queues on Node which makes interop incorrect (which is also one of the reasons why bluebird is ES6 spec non compliant). See https://gist.github.com/anonymous/9936c695f2c29e79a0c1a0dec863abea https://gist.github.com/anonymous/9936c695f2c29e79a0c1a0dec8... This might lead to subtle ordering bugs, I would recommend against using both together. Using bluebird and native promises together may result in slower performance because V8 has fast paths for native promises which fail for bluebird.

randallsquared 10y ago
In what way is this incorrect? Those are three separate promises; no code can be correct that depends on whether one resolve() call finishes before an independently started resolve() call, right?
Macha 10y ago
If the ordering is important, then you should be using a() .then(()=>b()) .then(()=>c()) Assuming anything about the completion order of: a(): b(); c(); Where a, b and c are async tasks of any kind (be they classic old callbacks, Promises, Observables, whatever) is just asking for trouble. The whole point is that you don't care about when it finishes, you just want to know that it has finished. If the order is that important and you don't want to handle managing it, you should just write standard synchronous code.