Bluebird VS q

It might, if the code can be optimized. There are all sorts of reasons why it might not. For example, at one point in time, a switch statement with more than 128 cases could not be optimized.

https://github.com/petkaantonov/bluebird/wiki/Optimization-k...

Prior to ES6, we used bluebird or Q. Now we have Promises natively:

For example: https://github.com/petkaantonov/bluebird/wiki/Optimization-killers

The standard library is quite barebones so you’ll need to import something else (Think bluebird for JS). You need an executor to run a future. I recommend using https://github.com/tokio-rs/tokio and reading their documentation.

I had a look at the bluebird promise FAQ, in which it mentions that .then(success, fail) is an antipattern. I don't quite understand its explanation as for the try and catch.What's wrong with the following?

I have not looked into how packages like bluebird does this, but I expect it is similar to the above items I expressed

You can look at the implementation of Bluebird an implementation of Promises that preceded them being available in JS itself.

How can I achieve this in NodeJS. I wonder if Q Library can be utilized in this case

Prior to ES6, we used bluebird or Q. Now we have Promises natively:

JavaScript Promises were a nightmare to wrap my head around. Not the fancy async/await syntax we have now, but the early stuff like kriskowal’s q. Wasn’t really until Promise was native did I fully understand it. Someone told me “the .then function only runs if you call resolve() in the previous block”. I think that’s what made it click.

I have some code that returns a promise object, e.g. using Q library for NodeJS.

Before promises arrived natively in JS, there were(and still are) many separate independent promise implementations in the form of third-party libraries for example Q, RSVP, etc. Even jQuery has its own custom implementation that they call deferreds. The name and the implementation might differ from library to library but the intention is the same, making asynchronous code behave like synchronous code.

Promises are a popular way of getting rid of callback hell. Originally it was a type of construct introduced by JavaScript libraries like Q and when.js, but these types of libraries became popular enough that promises are now provided natively in ECMAScript 6.

Another great library is Q https://github.com/kriskowal/q. This library is exposes the concept of promises. A promise is basically an object that is returned from a method with the “promise” that it will eventually provide a return value. This ties is very neatly with the asynchronous nature of javascript and node.js.

q : This module is used for creating custom promises. Check it out here