Consider this function `loadScript(src)` that loads a script:

When the script element is added to the document, the browser loads it and executes. So, the function works.

The function is *asynchronous*: the script starts loading now, but finishes later.

"Synchonous" and "asynchronous" are general programming terms, not specific to JavaScript.

A *synchronous* action suspends the execution until it's completed. For instance, a call to `alert` or `prompt` is synchronous: the program may not continue until it's finished.

let age = prompt("How old are you", 20);

An *asynchronous* action allows the program to continue while it's in progress. For instance, a call to `loadScript` is asynchronous. It initiates the script loading, but does not suspend the execution. Other commands may execute while the script is loading:

loadScript('/my/script.js');

As of now, the `loadScript` function loads the script, doesn't provide a way to track the load completion. The script loads and eventually runs, that's all. But we'd like to know when happens, to use additional functions and variables from that script.

Now we're able to load a script and then run our code that can use new functions from it, like here:

loadScript('https://cdnjs.cloudflare.com/ajax/libs/lodash.js/3.2.0/lodash.js', function(script) {

Here it was used for `loadScript`, but of course it's a general approach.

What if we need to load two scripts sequentially: the first one, and then the second one after it?

We can put the second `loadScript` inside the callback, like this:

Now after the outer `loadScript` is complete, the callback initiates the inner one.

As we can see, a new asynchronous action means one more nesting level. So the code becomes deeper and deeper.

In examples above we didn't consider errors. What if a script loading failed with an error? Our callback should be able to react on that.

Usage:

So the single `callback` function is used both for reporting errors and passing back results. That's called "error-first callback" style. Or we could use different functions for successful and erroneous completion.

As calls become more nested, the whole thing becomes increasingly more difficult to manage, especially if we add real code instead of `...`, that may include more loops, conditional statements and other usage of loaded scripts.

The pyramid grows to the right with every asynchronous action. Soon it spirales out of control.

In simple cases we can evade the problem by making every action a standalone function, like this:

See? It does the same, and there's no deep nesting now, because we moved every function to the top. But the code looks like a torn apart spreadsheet. We need to eye-jump between pieces while reading it. It's not very readable, especially if you are not familiar with it and don't know where to eye-jump.

Also the functions `step*` have no use, they are only created to evade the "pyramid of doom".

So we'd like to have a better way of coding for complex asynchronous actions.

Luckily, there are other ways to evade such pyramids. For instance, we can use "promises", described in the next chapter.