To use Bluebird or not

Best Practices
1

My project, which resides on a closed network is targeting Firefox (Late versions) only. Is there any value to have bluebird loaded?

1 Like
2

I think it could be easier to do the evaluation the other way around: remove Bluebird and evolve your app, with a paper note of extra features Bluebird has to offer compared to native Promise.

From my experience, you may go very far before needing to reconsider.

1 Like
3

I guess i need to see what features bluebird has, I just don’t want any kind of performance hit

4

If you’re using promises mainly for database / remote api calls then performance of native vs Bluebird is not going to be a big factor. In that case the decision should be whether the minimum native Promise spec is enough for your needs:

Promise.all()
Promise.race()
Promise.reject()
Promise.resolve()
Promise.then()
Promise.catch()
Promise.finally()

If you need stuff like cancellation, timers, concurrency control, promisification, etc., then your app could benefit from Bluebird. My personal practice is don’t add fluff unless it’s actually needed.

1 Like
5

I don’t see why you wouldn’t use Bluebird. It has more features than native promises (e.g. my personal favorite finally), and it is reportedly better-performing than native promises.

1 Like
6

A reference for everyone, for esnext users, @babel/polyfill does add Promise.prototype.finally and Promise.all Promise.race for all browsers (has or has no basic promise support).

Our cli esnext (requirejs/systemjs/webpack) skeletons now uses @babel/polyfill by default, you can safely remove bluebird if you start new project. Note requirejs/systemjs babel polyfill is in aurelia.json prepend, but webpack skeleton imports it in main.js.

1 Like
7

Thanks all, I actually thought originally that bluebird was a band-aid and not enhancements.