Use native promises

[ob-stripe]

r? @brandur-stripe
cc @stripe/api-libraries @OrKoN

• Use native ES6 promises instead of Bluebird promises
• Add a setPromise configuration option for users to provide their own Promise implementation

Fixes #438.

[brandur-stripe]

Awesome!

I'm just thinking about the idea of allowing the library's Promise implementation to be set — TBH, I don't know enough about the JS ecosystem to know whether people would want to do this, but it seems to me that given the historical here, i.e., JS didn't have promises so various libraries appeared to add them, but then the core language started supporting them, it seems to me that the overwhelmingly preferred destination is going to be wide convergence on native promises.

With that assumption, we may even want to not expose a way to configure a promise if possible so that we won't have to deal with that additional API over the long term. I wonder if we should hide that configuration for now, and then add it in if/when someone asks for it?

[ob-stripe]

TBH, I don't know enough about the JS ecosystem to know whether people would want to do this

TBH, I don't either 😆

That said, I've done some quick research and it seems people prefer third-party libraries like Bluebird over native promises for two reasons:

• performance
• much more extensive API

In our case, performance is probably a non-issue (the time spent in the Promise implementation is likely negligible compared to the time waiting for network requests to complete), and this PR proves we can get by with the native promises API. (Of course, users can still use third-party promise libraries in their own code.)

So, yeah, it probably makes sense for us to remove the setPromise method entirely and just use native promises always. I'll update the PR.

[brandur-stripe]

Haha, thanks OB. I just hope that I wasn't too far off point and that we don't just have to bring this back to your original implementation in a week ;)

LGTM.

[OrKoN]

I have run the latest benchmark on my laptop (./bench doxbee):

results for 10000 parallel executions, 1 ms per I/O op

file                                       time(ms)  memory(MB)
callbacks-baseline.js                           192       28.40
callbacks-suguru03-neo-async-waterfall.js       233       35.93
promises-bluebird-generator.js                  272       38.94
promises-bluebird.js                            294       47.81
promises-cujojs-when.js                         369       64.38
promises-tildeio-rsvp.js                        435       92.23
promises-lvivski-davy.js                        452       94.56
promises-native-async-await.js                  482      103.48
promises-ecmascript6-native.js                  495       96.97
promises-then-promise.js                        531       70.89
generators-tj-co.js                             532       86.63
callbacks-caolan-async-waterfall.js             615       81.26
promises-calvinmetcalf-lie.js                   876      159.32
promises-dfilatov-vow.js                        905      114.75
promises-obvious-kew.js                         967      116.49
streamline-generators.js                        973       78.28
promises-medikoo-deferred.js                   1175      107.42
observables-pozadi-kefir.js                    1205      143.38
streamline-callbacks.js                        1606       99.76
observables-Reactive-Extensions-RxJS.js        2328      183.53
promises-kriskowal-q.js                        7993      283.82
observables-caolan-highland.js                10067      496.00
observables-baconjs-bacon.js.js               22531      728.57

Platform info:
Linux 4.4.0-116-generic x64
Node.JS 8.10.0
V8 6.2.414.50
Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz × 8

[brandur-stripe]

@OrKoN Thanks for doing that! Looks liike amazingly, Bluebird is still faster. I wouldn't have thought that the native promises would have so many more opportunities for optimization compared to a userspace library.