JS: Asynchronous programming
2026-02-21 02:52 Diff
https://hexlet.io/courses/js-asynchronous-programming/lessons/promises/theory_unit

Asynchronous code has many advantages, but it is extremely hard to analyze. Just a few nested callbacks with parallel operations, and it is almost impossible to understand what is going on. It's frightening to think of a large program written completely asynchronously. A thousand lines of code, and no one can understand it.

From the beginning, developers understood the limitations of the callback approach, but it took a while for an alternative to appear - promises in JavaScript.

Promises changed the way we organize code without adding new syntax. When used correctly, they allow you to straighten out asynchronous code to make it consistent and smooth.

Much of today's JavaScript code is written with promises, leaving callbacks a thing of the past. For example, Node.js developers have implemented promises in almost all embedded modules. Functions built on promises and designed to work with file systems are available via the promises property of the fs module.

Compare some examples:

Technically, a promise is a special object that keeps track of an asynchronous operation and stores its result inside itself. It's returned by all asynchronous functions built on promises:

It is essential to grasp that a promise is not the result of an asynchronous operation. It is an object that tracks the progress of the operation. The operation is still asynchronous and will be executed some time later:

How to get the result of an asynchronous operation? From the outside, you can't. But you can continue the promise by using then() method, where you pass a callback function. The parameter of this callback function will be the result of the asynchronous operation:

The callback is called inside then(), not passed. The promise itself makes the call when the asynchronous operation is executed.

Regardless of the content of the callback function, a call to then() always returns a new promise. The return of the callback function becomes available as a callback parameter for the next then().

Such organization of promises allows you to build chains without putting calls into each other, thus avoiding callback hell:

What if the callback function returns a promise instead of just a value? The parameter of the next then() would be the execution result of that promise. Otherwise, the promises would be meaningless:

Using promises within a function automatically makes that function asynchronous. We don't call it a regular synchronous function because then we can neither use its result, nor wait for the operation to complete, nor find errors:

Once there is any asynchrony in the code, the code changes its structure. If it's callbacks, the code becomes more nested. If it's promises, the code turns into a continuous chain of promises:

Incorrect usage of promises

The primary advantage of promises over callbacks is that promises make asynchronous code seem synchronous. You can see the chain of calls, and it doesn't get any deeper, at least in theory. But in practice, promises sometimes aren't used correctly. Look at this code:

The code looks even more complicated than it does with the callbacks, even though we are using promises here. The problem lies in the way the calls are structured. The continuation of the chain comes from each successive asynchronous operation, not from the top promise.

In theory, promises can be nested, but only when there is no other way. Otherwise, the code should be flat and simple: