What are the differences between callbacks, promises and async/await?

Imagine that you have to call a function that will take time to respond. But you need its answer to be able to invoke another one later, since the second one needs as a parameter what the first one has produced. For example, the first might download a Web page, extract a URL from it, and the second might need this URL to access another resource.

Using synchronous code, everything is easily understood

function main() {
    r1 = serv1(parametros);
    r2 = serv2(r1);

    // Lo anterior también se podría haber escrito r2 = serv2(serv1(parametros))
    console.log("Resultado final: " + r2);
}

because we assume that the calls to serv1()and serv2()are made synchronously, that is, that until these functions do not have their response, the execution will not continue through the next line. This type of code is easy to write and understand, but it is very inefficient. It is assumed that the time it takes serv1()andserv2()in getting your response is mostly waiting time (network communications, for example), time during which the thread is stopped waiting for the response, and that you could have used doing something else. In fact, in JavaScript, this thread is the one that deals with interacting with the DOM and with the user, so the page would remain "hung" this time. And if the time is too long, the Browser will eventually detect that the thread isn't processing GUI events and will output a warning like "A script on this page is taking too long. Do you want to abort it?"

The solution is to make use of asynchronous versions of these functions. Let's call them asinc1()and asinc2()These functions return immediately to the main thread, but leave the Browser "in charge" of making the corresponding requests in another thread (dedicated to network communications).

Note making a function asynchronous does not cause it to automatically execute in another thread, nor is it a magic method of "parallel" execution. If the routine we called asynchronously were to do CPU-hogging calculations, the GUI thread would suffer as well. Only if the asynchronous function makes use of blocking input/output, typically network or disk access, can it benefit, since then it doesn't sit around waiting for the input/output operation to finish, but returns immediately and only later. , when the operation has finished (other processes like the op or another thread in the browser will have completed it), the task resumes and you can get the response.

The problem is what happens once those requests have been completed? Where does the answer go? Since we need the response from asinc1()before we can invoke asinc2(), how does our program know when it finished asinc1()and what the result was?

There are two possible implementations to solve this problem:

• Callbacks . The asynchronous call receives a function as a parameter. When the result is available, it will call that function passing the result as a parameter. This way often makes the code unreadable, this is known as Callback Hell
• Promises . The asynchronous call returns a Promise as a "provisional" result. This is an object that will contain the result in the future. This object has a series of well-defined methods that allow you to check its status (if it has been resolved or not yet, if there have been errors), assign it a status (which the asynchronous function will do when it gets the result), and even assign a function to it. as a callback that will be invoked when the Promise state is resolved.

The first solution ( callbacks ) is more direct, but results in more nested code, as you can see in the following example:

// Versión asíncrona. Se supone que asinc1() y asinc2() son funciones que admiten 
// un callback como parámetro, al cual llamarán pasándole el resultado
function main() {
    asinc1(parametros, function(r1){
        // Tenemos el resultado de asinc1
        asinc2(r1, function(r2) {
            console.log("Resultado final: " + r2);
        });
    });
}

Nesting would be worse as we have more chained functions (the result of one is needed to call the next), giving rise to functions that are parameters of other functions, that are parameters of others, etc. and the source code acquires a characteristic form in which it indents more and more and then undoes that indentation as braces and parentheses are closed, a structure known as Pyramid of Doom , or Callback hell .

On the other hand, in this code all the logic is "backwards" in some way, since the functions do not return results, but rather pass those results as parameters (to other functions), and the functions that handle the response are in turn passed as parameters. Error flow (which I won't go into in this answer) is also complicated, as exceptions can no longer be used, instead there would typically be two callback functions , one called on success and one called on failure.

Promises avoid this nesting, and make error handling simpler. A Promise has a method then()that you pass a function to, which will be executed automatically when the promise resolves (or immediately if it was already resolved at the time we invoked .then()). This function will receive as a parameter the value of the promise (the expected result). And the best thing is that it .then()returns a new Promise, which will be resolved when the function that we had associated with it is executed. In this way, several can be chained together .then()to "simulate" a sequential code, like "when this promise resolves, do this, and then, when this one resolves, do this, and then...)

This would be the new syntax:

// Versión con Promises
// Ahora asinc1 y asinc2 se supone que retornan una Promise
function main() {
    asinc1(parametros)
    .then(function(r1){ return asinc2(r1); })
    .then(function(r2){
    console.log("Resultado final: " + r2); 
    })
}

// Lo anterior puede escribirse aún más concisamente así:
function main() {
    asinc1(parametros)
    .then(asinc2)
    .then(function(r2){
    console.log("Resultado final: " + r2); 
    })
}

Since 2017 JavaScript also has the words async/await, which are syntactic sugar for using Promises with a new syntax that hides them, and makes them look like synchronous code.

If we use the word awaitin front of a function call, that function is understood to return a promise. Then somehow (I won't go into the messy details of how it does it "inside") execution pauses at that point (but doesn't block the main thread) and only resumes when the promise has been resolved, and then awaitreturns the value of the promise as a result.

Thanks to this the code would now be:

async function main() {
    r1 = await asinc1(parametros);
    r2 = await asinc2(r1);

    console.log("Resultado final: " + r2);
}

Compare the latter with the former (synchronous). The structure is identical and has only been put awaitbefore asynchronous calls, and asyncbefore the function (since only a function declared with asynccan use await).

The runtime efficiency of the three asynchronous solutions is similar. What changes a lot is the structure of the code, which is simplified with Promises and even more so with await, possibly resulting in fewer errors, and better maintainability and debugging.

To answer your question you have to answer something fundamental first

What is asynchrony?

The term is used loosely in Javascript and programmers usually associate it with the ability to execute a task without blocking the Javascript thread, which is completely false . What asynchrony actually means is the ability to execute instructions in a different stage of the event cycle or event loop as it is known in English. You can perfectly schedule a job with setTimeout, for example, and this, when it's time to run, blocks the main thread.

Don't press the button on this snippet unless you're ready to see your browser crash and I'm using a setTimeoutto schedule the task tareaIntensivathat contains the loop. In any case, the browser will show you a sign that there is a script blocking the page.

function start() {
  function tareaIntensiva() {
    for (let i = 0; i < 10000000; i++) {
      console.log(1);
    }
  }
  setTimeout(tareaIntensiva);
}

button {
  padding: 10px 5px;
  background-color: royalblue;
  border: solid 1px lightgray;
  border-radius: 3px;
  color: white;
  cursor: pointer;
}

<button id="doom" type="button" onclick="start()">
   Destruir navegador
</button>

The event loop is composed in a very simplified way by different messages or functions that are executed one after the other following a certain pre-established order using a specific system of priorities until there are no more messages to process. In another more advanced model of abstraction it is composed of normal user code, micro-tasks and macro-tasks . This topic is quite complex but you can find here a fairly extensive and detailed article on how everything works. To explain it in a simplified way when you usesetTimeoutyou create a macro-task that will be executed in some later cycle, promises create micro-tasks are executed in the same cycle you are in right after executing all the traditional code you write without these artifacts. It follows that if you call setTimeoutand a promise the latter will be executed first.

I have to explain all of the above so you understand how it applies to your problem:

Callbacks

In terms of styles they are the worst decision as they are known to create the callback hell that makes the nested code completely unreadable. Regarding error handling in Nodejs there is a convention of passing the error as the first parameter but this standard can be violated since callbacks are simple functions that you pass as parameters.

In terms of execution, callbacks are agnostic since it depends on the implementer to use micro-tasks or macro-tasks for their execution. This might not incur asynchrony at all. Here is an example:

function miFuncion(param, callback) {
    if (param > 20) {
        leeUnFichero(callback);
    } else {
        callback();
    }
}

This harmless code is only executed in a later stage of the event loop if and only if param > 20, otherwise it would be the same as writing for example:

miFuncion(19);
callback();

This code doesn't even run a task which sometimes creates real headaches trying to figure out what's wrong. In this case, the correct thing would be to use it setTimeoutto simulate asynchrony and that the function behaves in the same way regardless of the parameters.

function miFuncion(param, callback) {
    if (param > 20) {
        leeUnFichero(callback);
    } else {
        setTimeout(callback);
    }
}

promises

They are usually executed using micro-tasks (only in extreme cases when nothing else is available are macro-tasks used). If you are using native promises in both Node and the browser they are guaranteed to be micro-tasks so you can safely say that whatever they do, promises ARE asynchronous.

Style-wise it's an improvement over callbacks but actually both the thenand the catchuse callbacks to schedule code execution. The advantage is that the pyramid is not created since the promises can be chained. Among other reasons they are designed to make asynchronous code retain properties of synchronous code such as flat indentation and a single error channel which is impossible to achieve with pure callbacks.

It is important to understand that you can create a chain as long as you want because every time you return something in a thena new promise is created (you return undefineda function if you don't return anything) but for each of them thena new micro-task is programmed that although it is less expensive than a macro-task it still has a small cost in the event loop.

// puede ser tan larga como quieras
promesa().then(() => {}).then(() => {}).then(() => {}).then(() => {})

One aspect that many developers forget is that you should always handle the error at the end of a chain since, for example, in Node an errored promise that is not caught could kill the process . This is important to keep in mind for what I am going to say in the next point.

async/await

It's syntactic sugar on promises. For that same reason they use micro-tasks as well. There are claims that they can be optimized to be faster . This of course depends on the browser and is not 100% secure every time.

As for style "promises" less indentation than promises but if you remember what I said before about handling errors you will have to write a try/catchto handle the error and inevitably you will create indentation. If you use some abstraction model you can handle the error elsewhere getting completely flat and very easy to read code.

async function miCodigo() {
   const valor1 = await funcionAsincrona1();
   const valor2 = await funcionAsincrona2();
}

// En otra parte podrías tener:
async function main() {
    try {
        await miCodigo();
    } catch (e) {
        // Manejar error
    }
}

main();

There are also advantages to handling errors with async/await since any error thrown within the function asyncwill be caught by the function and turned into a rejected promise automatically.

That said, it is clear that you cannot compare promises and callbacks since they fulfill a different function but in terms of style and if you have truly asynchronous code (for example ajax calls, reading files, websocket connections, etc) they will be a great improvement in terms of readability is concerned. If your code is really complex, async/await will be the best option in terms of promises to write and understand your code.

For completeness you should know that there are tons of ways to create asynchrony, not just promises. You can find standard methods like setTimeout, setInterval, requestAnimationFrame, process.nextTick, setInmediateand informal methods like MutationObserver which allows you to artificially create a micro-task in the browser. If you want to do really intensive operations that can block the main thread you should use Web Workers

The two previous answers, from @devconcept and @abulafia, explain the concepts in great detail, but I want to provide a version for quick references, where you can see how we can go from callbacks to promises, and with them how to use the syntaxasync / await

Therefore, this answer will be a practical example where we will take an asynchronous call and refactor it step by step until we obtain the most elegant code possible.

Callbacks

Let's imagine that we have the classic AJAX call through XHR:

const url = 'https://swapi.dev/api/people/1/';

function callbackFunction(event) {
  const resultado = JSON.parse(event.target.responseText);
  console.log(resultado.name)
}

const xhr = new XMLHttpRequest();
xhr.open("GET", url)
xhr.addEventListener('load',callbackFunction);
xhr.send();
console.log('Petición hecha');

The AJAX call is asynchronous, which means that we know when the request ( xhr.send();) is made but not when the response will be returned. All we know is that when the browser receives the response, the function will be called callbackFunctionbecause we have defined it that way.

But now let's imagine that we want to create a function that allows us to make AJAX calls in a simple way, to have the calls made in one line:

function callbackFunction(event) {
  const resultado = JSON.parse(event.target.responseText);
  console.log(resultado.name)
}

//función que hace una llamada ajax
function myFetch(url, callback) {
  const xhr = new XMLHttpRequest();
  xhr.open("GET", url)
  xhr.addEventListener('load',callback);
  xhr.send();
  console.log('Petición hecha');
}

//ahora podemos hacer varias llamadas en una línea:

myFetch('https://swapi.dev/api/people/1/', callbackFunction);
myFetch('https://swapi.dev/api/people/2/', callbackFunction);
myFetch('https://swapi.dev/api/people/3/', callbackFunction);

This is progress, but we have a problem if we have dependencies: What happens if the second call depends on the first? We would be left with something like this:

//función que hace una llamada ajax
function myFetch(url, callback) {
  const xhr = new XMLHttpRequest();
  xhr.open("GET", url)
  xhr.addEventListener('load',callback);
  xhr.send();
  console.log('Petición hecha');
}

//llamadas AJAX anidadas
myFetch('https://swapi.dev/api/people/1/', function callbackFunction({target}) {
  const personaje = JSON.parse(target.responseText);
  console.log('Personaje:',personaje.name);
  console.log('Nació en',personaje.homeworld, '(oops, necesitamos otra llamada)');
  //por seguridad las llamadas serán vía HTTPS
  const url = personaje.homeworld.replace('http','https');
  myFetch(url, function callbackfunction2({target}) {
    const planeta = JSON.parse(target.responseText);
    console.log('El planeta era:',planeta.name);
    const url2 = planeta.films[0].replace('http','https');
    myFetch(url2, function callbackfunction3({target}) {
      const film = JSON.parse(target.responseText);
      console.log('El título de la primera película en la que aparece es', film.title);
    }); //fin tercer callback
  }); //fin segundo callback
}); //fin primer callback

En este caso aún tenemos algo manejable (3 llamadas anidadadas), pero este anidamiento nos puede causar el llamado Callback Hell (infierno de llamadas anidadas):

Promesas

¿Cómo evitarlo? Pues con promesas. Una promesa es un objeto que permite encadenar acciones asíncronas, diciendo "realiza la acción A, cuando termines A, ejecuta B, entonces ejecuta C, entonces ejecuta ..." de un modo algo más sencillo:

//Creemos promesas!!
function myFetchPrometido(url) {
  //creamos una promesa que se resuelve cuando la llamada AJAX obtiene una respuesta
  return new Promise(function (tenemosRespuesta, tenemosError) {
    const xhr = new XMLHttpRequest();
    xhr.open("GET", url)
    xhr.addEventListener('load',({target}) => {
      tenemosRespuesta(JSON.parse(target.responseText));
    });
    xhr.send();
    console.log('Petición hecha');
  });
}

//ahora podemos hacer varias llamadas dependientes
// sin anidamiento extra.
const promesa = myFetchPrometido('https://swapi.dev/api/people/1/');
promesa.then(personaje => {
  console.log('Personaje:',personaje.name);
  console.log('Nació en',personaje.homeworld, '(oops, necesitamos otra llamada)');
  //por seguridad las llamadas serán vía HTTPS
  return  myFetchPrometido(personaje.homeworld.replace('http','https'));
}).then(planeta => {
  console.log('Planeta', planeta.name);
  return  myFetchPrometido(planeta.films[0].replace('http','https'));
}).then(film => {
  console.log('Primera aparición en la película', film.title);
});

Como vemos, una promesa tiene el método then, al que se le pasa la función callback. Lo bueno de este método es que si la función callback devuelve algo, el método lo devuelve a su vez como el resultado de una nueva promesa (si la función devuelve una promesa, no se anidan, es así de inteligente), con lo que puedes tener un número indefinido de métodos then encadenados.

async / await

De este modo ya nos hemos ahorrado una anidación exagerada, pero el código sigue siendo un poco feo. ¿Se puede hacer más elegante?

La respuesta es sí: existe una sintaxis que es equivalente a usar Promesas pero las "oculta", haciendo que el código parezca síncrono, sin necesidad de callbacks, anidadas o no:

//Creemos promesas!!
function myFetchPrometido(url) {
  //creamos una promesa que se resuelve cuando la llamada AJAX obtiene una respuesta
  return new Promise(function (tenemosRespuesta, tenemosError) {
    const xhr = new XMLHttpRequest();
    xhr.open("GET", url)
    xhr.addEventListener('load',({target}) => {
      tenemosRespuesta(JSON.parse(target.responseText));
    });
    xhr.send();
    console.log('Petición hecha');
  });
}

// await sólo se puede usar dentro de una función asíncrona,
// es la única limitación o pega
async function main () {
  //await es literalmente "espera", estamos esperando la resolución de una promesa
  const personaje = await myFetchPrometido('https://swapi.dev/api/people/1/');
  console.log('Personaje:',personaje.name);
  console.log('Nació en',personaje.homeworld, '(oops, necesitamos otra llamada)');
  
  const planeta = await myFetchPrometido(personaje.homeworld.replace('http','https'));
  console.log('Planeta', planeta.name);
  
  const film = await myFetchPrometido(planeta.films[0].replace('http','https'));
  console.log('Primera aparición en la película', film.title);
};

//llamamos a la función asíncrona
main();

Ejemplo de que es async y await:

Supongamos el siguiente caso hipotético, donde hacemos una petición a una API(esta API nos devuelve un array de productos) ,está por defecto, va a tener una latencia o un 'delay'.

let productos = [1,2,3];
const conseguirProductos= ()=>{

        return new Promise((resolve,reject)=>{//creamos nuestra promesa
        console.log('Cargando productos... esto puede dilatar un poco');//le damos un mensaje al usuario

        setTimeout(()=>{
            resolve(productos)
        },5010);

 });
}
async function getMisProd()//para indicar que es una funcion asincrona debe colocar la palabra reservada 'async'
{
    let misP= await conseguirProductos();//podriamos decir que 'await' remplaza el 'then' 
    console.log('Mira, este es el resultado '+misP);
}//esto lo definimos como 'azuzar sintactia' /
//++asyncs++ a +++await+++ lo usamos en algo que tenga ver con una promesa o algo que tenga cierta latencia...



getMisProd();//llamamos a la función

En el caso anteriormente mencionado nosotros usamos async y await... Ahora les mostraré de como seria sin async y await.

//esto seria usando la forma 'normal' sin el await
let productos = [1,2,3];
const conseguirProductos= ()=>{

        return new Promise((resolve,reject)=>{//cremos nuestra promesa
        console.log('Cargando productos...esto puede dilatar un poco');//le damos un mensaje al usuario

        setTimeout(()=>{
            resolve(productos)
        },5010);

 });
}

conseguirProductos()
    .then(datos=>{//en caso de que sea exitosa se ejecuta 'then'
        console.log(datos);
    });
   

Resumen:Async y Await nos da una sintaxis más bonita y fácil de usar...