1

During studying promise in node.js. i have some doubt.
'promise' is already defined in node.js
but usally it seems to use additional promise framework like Q,bluebird,RSVP etc.
Is there any reason?

Is the reason that core node.js function cannot support promise with promise.denodeify function?

Terry Cho
  • 608
  • 6
  • 14

2 Answers2

2

I can't say for Q, but Bluebird is a lot faster than native Promises, and provides a bunch of extra features on top of the native promise.

It's the same reason people use lodash despite having [].map() for years now.

Additionally, Bluebird has better browser support than the native Promise implementation.


You normally only use Bluebird on the server, though. The extra features and speed are not worth the extra size of the library the user has to download.

Madara's Ghost
  • 172,118
  • 50
  • 264
  • 308
  • 1
    Just tacking this on to this answer, these [benchmarks](http://bluebirdjs.com/docs/benchmarks.html) reinforce this answer. Bluebird is far more performant than virtually any other async approach right now. ES6 Native Promises are more performant than Q though, which is worth noting. Also Bluebird has [promisification](http://bluebirdjs.com/docs/api/promisification.html) of non-promise libraries which is another huge benefit of using Bluebird. – peteb Mar 16 '16 at 15:42
  • This isn't true any longer. [Bluebeard Github readme](https://github.com/petkaantonov/bluebird): "Please use native promises instead if at all possible. Native Promises have been stable in Node.js and browsers for around 6 years now and they have been fast for around 3" – ggorlen Jul 10 '22 at 00:34
  • @ggorlen feel free to edit that into the answer. – Madara's Ghost Jul 10 '22 at 13:11
0

Well, promise is the native JavaScript object. All those libraries are userland implementations. For example if we look at bluebird it has:

  • A lot of utility functions and helpers that make your life easier.
    • It has typed .catch which makes sure you don't catch programmer errors by mistake.
    • It has .some .any .map .filter and so on for working with collections easily.
    • It has .reflect and synchronous inspection of promises.
  • It doesn't swallow errors by default when throwing in a then handler.
  • Built in coroutine (generator) support for flattening asynchronous flow.
  • It's faster (usually between 4x and 10x) than native promises in different browsers.
  • It provides more debugging hooks and better stack traces.
  • It provides warnings against common promise anti-patterns.
  • It lets you override the scheduler so you can determine how it schedules tasks.
  • It supports promise cancellation with sound semantics which is proposed for native promises but not yet adopted.

So in a tl;dr; :

  • It's faster.
  • It's more debuggable.
  • It has a richer API.

Now, whether or not you should use it is up to you - there is always overhead in including libraries - I'm biased as a core contributor.

Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504