Add attempt to require bluebird first

[ruimarinho]

This is likely controversial, but in my opinion, if a developer has bluebird installed, we might as well take advantage of that fact, at least for now, considering that it is 40x faster than ES6 Promises.

See https://github.com/petkaantonov/bluebird/tree/master/benchmark and angular/angular.js#6697 (comment).

We can always switch back to the previous order when ES6 Promises are optimized in V8. I've tested the benchmarks on io.js and even with the V8 upgrade, native promises are still way slower than bluebird's implementation.

[coveralls]

Coverage decreased (-11.11%) to 88.89% when pulling 2047b07 on seegno-forks:enhancement/try-bluebird-first into 652f574 on normalize:master.

[jonathanong]

i had it this way before. unfortunately, if we added this back, we would have to change the name of the module =P

[jonathanong]

people can vote on this though... don't really care

[ruimarinho]

I had the same thought :P but I think it's fine, people are probably going after functionality and performance rather than the actual order of events.

[ruimarinho]

@jonathanong would it make sense to allow some option like { preferNative: true } so that at the application level developers can prefer a native implementation but if not passed, cascades through the top Promises/A+ libs and then falls back to native anyway ( bluebird > es6-promise > native)?

I'm particularly interested in experimenting the new unhandled rejection tracking support on io.js and bluebird already has hooks for that.

[jonathanong]

i'm ambivalent. anyone care about this?

[jonathanong]

@dougwilson @dead-horse @fengmk2?

[fengmk2]

@jonathanong agree! Native Promise has memory gc reason and current can't be fix tj/co#180 .

[fengmk2]

or new module name bluebird-or-native ...

[jonathanong]

@fengmk2 good reason!

[jonathanong]

1.2.0!

[dead-horse]

haha. I always do global.Promise = require('bluebird') for now.