How much should I be using promises in ES6 node projects?

Question

In the official bluebird promises page it is written that if you are using node.js it's very unlikely I will have to write promises myself.

Since I started on a new project I found all my code base revolving around promises. For example I have a databaseConnector that returns a promise, an express route that takes a promise, tests with chai-as-promised that test promises and in general I haven't written any function that receives a callback.

Should I be writing callback modules and if needed promisify them?

What are the cons if any?

Answer 1

Should I be using promises in ES6 node projects?

Yes, definitively. Promises are the new standard asynchronous interface.

In the official bluebird promises page it is written that it's very unlikely I will have to write promises myself.

Not exactly. What they mean here is that you hardly ever will need to use the new Promise constructor function - most of its usages are an antipattern.
You will want to use promises everywhere, but you don't want to create them explicitly from callbacks. If you have asynchronous code that takes callbacks, promisification is much easier to use than new Promise.

Since I started on a new project I found all my code base revolving around promises

You're lucky! All the functions you are working with already return and expect promises - that's great! You can just use them, embrace them. You don't have to worry about odd callback patterns in your promise code.

Should I be writing callback modules and if needed promisify them?

No. Especially not if you all the APIs you're working with already use promises. Promises make much simpler and more correct code. They're just great.

Answer 2

Comparing to callbacks, you should almost always use promises. They are way more readable, solve some of the nesting problems and provide a standardized way to notify on errors (using reject()).

What the official bluebird promises page could mean is

• on node, you can often solve things more performant using streams (like gulp does), where you often have callbacks instead of promises (think of es.map())
• as you mentioned es6, you could use generators instead of callbacks/promises. They don't work well together, so stick with one or the other, but they are handy in some cases.
• you could even use the es7 feature async/await, which will hopefully make everything else obsolete in the future.

Cons of callbacks. Well... They once were continuations and no compiler designer even thought of bothering language users directly with this. Then node.js came and now everyone writes endlessly nested function calls that are not readable (don't even think of debugging), don't provide ways for error handling (except the de-facto standard of having err as the first parameter for the callback) and don't interact well with synchonous code.