When NOT to use promises

Question

After you read dozens of articles about how big es6 promises are and why we should implement them, I have the feeling that ALL of my (non-trivial) javascript functions should be promises.

In fact, I feel great when writing code that uses them, as I avoid the doom triangle and seem to get clear and concise code. (it really makes reasoning about implementation a lot easier).

What I could not find: When do you NOT use promises? When will I not use them?

Update:

While I saw some great points, such as the consistency of the API, I have yet to find a solid case of NO. Lux's answer suggests that the operations that event emitters choose should avoid them, because repeated callbacks are not compatible with promises. However, I feel that the answer is still not enough to check it (as it is right) right now.

Answer 1

Some rules of thumb:

• When your method can be synchronous (simple data conversion), then use synchronous code in this method.

  However, if a method can sometimes be synchronous and sometimes asynchronous (several code paths based on internal or external state), it should always be asynchronous. Otherwise, you may encounter unexpected minor discrepancies in how your code behaves in complex scenarios, so it's best to avoid mixing the two relationships.

  [edit] As noted in the commentary, when your method is synchronous, but you are sure that you may need to perform asynchronous work at some point in the future, you can use promises from the very beginning to avoid costly refactoring.

• In general, your API should be consistent, so it is best to use promises everywhere or callbacks everywhere. This will facilitate the discussion of code.

• If you write ultra-high performance code and / or need little memory, you can not use promises, but callbacks or use a promise library with a focus on performance, like bluebird , instead of the built-in Promise polyfill implementation / general use case.

• [edit] In any case, new additions to the web platform, such as the global fetch function, will return Promise , and it looks like more and more built-in browsers will work on promises in the near future. Therefore, if you want to write modern code, you will not escape promises.

Answer 2

You use promises for one-time asynchronous operations. Initiate an operation, perform an operation, notify the caller of completion or results or error, and then do it well.

Strong situations in which you do not use promises are those that differ from those described above:

• When your operation or function is completely synchronous . Including an asynchronous API (even with promises) in a synchronous operation just makes things more complicated than necessary.
• Instead of events that may occur several times. For example, you will not use a promise for a button click handler. An EventEmitter or other event-like structure is still the best structure for recurring events.
• When you have a callback situation in which the callback is intended to be called multiple times (for example, to run reports or provide a plug-in via a callback).
• If you add one new operation to an API that has already been developed in some other way (for example, with traditional callbacks) and Consistency API .
• If you are configured for older environments that do not support promises (for example, old browsers), and you are trying to optimize the size of the loaded code, and you only do one or two asynchronous operations, and you are not using something like jQuery or Angular, which already has a form of built-in promises that you can use. If you are doing any significant work in asynchronous mode, then most likely it is worth using promises polyfill, so this point is intended only for cases when size is extremely important and async works very little.
• For situations where the action often does not end or takes place . promises are an object with state and therefore consume some memory. It would be pointless to create thousands of promises to receive notifications about a lot of different things that usually will not occur, because it will create thousands of promise objects (usually with their accompanying closures) that in most cases will never be used. This is simply inefficient memory usage and is probably better served by some kind of event notification. As I said above, promises work best when you start an operation, perform an operation, notify the caller of the results or errors.

Answer 3

Good Promises have one use case: async results that appear only once.

You are not using Promises if you can return the result in synchronization, and you still need event callbacks because they can occur several times.

Answer 4

You can not use Promises if you want your code to run in a browser (which may not have Promises built-in) and the size is REALLY , so you can't allow the use of Promise shims / libs.

Answer 5

Promises are most often used to simplify working with asihnronnous tasks. Sometimes we intentionally do some things asynchronously in order to avoid overloading the thread we are working with. We have only one thread per tab. No need to use promises when something is small or things can be done using WebWorker.