3 ms·
Just use bluebird
by psadri 9y ago
Just use bluebird
- jameshart 9y agoNot really the ideal solution in a world where people have libraries that return promises and other libraries that operate on promises.
- iEchoic 9y agoIt's really easy with Bluebird to assimilate promises from other libraries, though. Right now, I still think it's best to use Bluebird from the start in a new project than to use native promises. They're faster, have better error stack traces, and more capabilities.
- untog 9y agoPlease don't. According to the docs Bluebird is 17.76KB gzipped. With extensive Promise support in browsers that's a total waste of bandwidth and parse time.
- joshribakoff 9y agoComparing bluebird and promises is like comparing squares to rectangles. It's a superset. One benefit of bluebird is having specific catch blocks for specific types of errors. You can have certain errors handled by the catch while other errors bubble through. This is also possible (and cleaner) with async/await though. Bluebird also adds a bunch of operators for racing promises a d and polyfills for other things that might not be available in your runtime. I'm not saying to use bluebird, I definitely prefer native implementation, but there are still contrived use cases for bluebird
- untog 9y agoSure, but don't "just use Bluebird", as the OP said, in every situation. If you require the extra features of Bluebird, use Bluebird. But if you're just handling simple Promises, it's a waste.
- psadri 9y agoPerhaps I was too terse in my comment and earned myself down votes. Realistically, if you are shipping software in the real world where it could run on older browsers, you do need to use something like bluebird just to get uniform support. Not to mention things like maps/each/joins/timeouts that you will likely need for anything non-trivial.