Logo Gerardo Perrucci - Full Stack Developer

El Event Loop de JavaScript en profundidad

June 18, 2025 • 16 min read • Gerardo Perrucci
JavaScript Event Loop Diagram

JavaScript es asíncrono por naturaleza gracias al Event Loop. Comprender su mecánica es crucial para construir interfaces de usuario no bloqueantes y responsivas.

 Decorative quote iconJavaScript, a menudo descrito como un lenguaje single-threaded, presenta una paradoja intrigante: ¿cómo consigue gestionar operaciones complejas como peticiones de red, interacciones del usuario y temporizadores sin bloquear el hilo principal y congelar la interfaz? La respuesta reside en su sofisticado mecanismo Event Loop.

Para ingenieros avanzados que trabajan con frameworks modernos como React, comprender en profundidad el Event Loop, su interacción con las microtasks y macrotasks, y su papel clave en el renderizado del navegador y la gestión de eventos DOM no es simplemente académico: es fundamental para crear aplicaciones web concurrentes, de alto rendimiento y realmente responsivas.

Los componentes centrales del entorno de ejecución de JavaScript

Para captar de verdad el Event Loop, primero debemos entender el entorno en el que se ejecuta JavaScript. El propio motor de JavaScript (como V8 en Chrome o SpiderMonkey en Firefox) es ligero y contiene principalmente la Call Stack y el Heap. La magia de la asincronía procede en gran medida de las Web APIs que ofrece el navegador y de los mecanismos de encolado que interactúan con el Event Loop.

1. La Call Stack

La Call Stack es una pila LIFO (Last-In, First-Out) que lleva el seguimiento de la ejecución de tu programa. Cuando se invoca una función, se empuja (push) a la pila. Cuando retorna, se extrae (pop). JavaScript ejecuta una función a la vez, de arriba abajo de la pila.

function thirdFunction() {
  console.log("Third function executed");
}

function secondFunction() {
  console.log("Second function executed");
  thirdFunction(); // Pushes thirdFunction onto the stack
}

function firstFunction() {
  console.log("First function executed");
  secondFunction(); // Pushes secondFunction onto the stack
}

firstFunction(); // Pushes firstFunction onto the stack
console.log("Global scope finished");

Flujo de ejecución:

  1. firstFunction se empuja.
  2. console.log("First...") se ejecuta.
  3. secondFunction se empuja.
  4. console.log("Second...") se ejecuta.
  5. thirdFunction se empuja.
  6. console.log("Third...") se ejecuta.
  7. thirdFunction retorna y se extrae de la pila.
  8. secondFunction retorna y se extrae de la pila.
  9. firstFunction retorna y se extrae de la pila.
  10. console.log("Global...") se ejecuta.
  11. El contexto global finaliza y se extrae de la pila.

2. El Heap

El Heap es una gran región de memoria no estructurada donde se almacenan objetos y variables. A diferencia de la Call Stack, que gestiona el orden de ejecución, el Heap se encarga de la asignación de memoria para las estructuras de datos.

3. Web APIs (entorno del navegador)

No forman parte del motor de JavaScript en sí, sino que las proporciona el navegador. Permiten a JavaScript interactuar con el mundo exterior y realizar operaciones no bloqueantes. Ejemplos:

  • setTimeout() y setInterval(): para programar la ejecución de código tras un retardo.
  • DOM APIs: para interactuar con el DOM (p. ej., addEventListener, querySelector).
  • fetch() y XMLHttpRequest: para realizar peticiones de red.
  • location, localStorage, console: otras funcionalidades que expone el navegador.

Cuando llamas a una Web API (p. ej., setTimeout(callback, delay)), el navegador toma el control, inicia un temporizador o una operación de E/S. Una vez finaliza (p. ej., expira el temporizador, se reciben los datos), la Web API coloca la función callback asociada en una cola.

4. Callback Queue (Macrotask Queue / Task Queue)

En esta cola se sitúan los callbacks procedentes de Web APIs (como setTimeout, setInterval, E/S, renderizado de UI, etc.) una vez terminan sus operaciones asíncronas. Estos callbacks se consideran macrotasks.

5. Microtask Queue (Job Queue)

Introducida con Promises en ES6, la Microtask Queue es otra cola que alberga microtasks. Las microtasks tienen mayor prioridad que las macrotasks. Los callbacks de Promise.then(), Promise.catch(), Promise.finally() y MutationObserver suelen acabar aquí.

6. El propio Event Loop

El Event Loop es el proceso continuo que supervisa la Call Stack y las distintas colas. Su tarea es mover callbacks de las colas a la Call Stack para ejecutarlos cuando la Call Stack está vacía. Este es el mecanismo esencial que permite el comportamiento asíncrono y no bloqueante de JavaScript.

El algoritmo del Event Loop: paso a paso

El Event Loop funciona de forma precisa e iterativa. Piénsalo como un supervisor que comprueba constantemente el estado del entorno de ejecución.

El Event Loop garantiza que JavaScript siga siendo no bloqueante y responsivo, orquestando cuidadosamente la ejecución de código síncrono y asíncrono.

Algoritmo simplificado para una sola iteración (o “tick”) del Event Loop:

  1. Ejecutar la Call Stack:

    • El Event Loop comprueba continuamente si la Call Stack está vacía.
    • Si no lo está, ejecuta todas las funciones apiladas de forma síncrona hasta que la pila quede vacía. Aquí se ejecuta todo el código síncrono inicial.

  2. Procesar microtasks:

    • Una vez vacía la Call Stack, el Event Loop revisa la Microtask Queue.
    • Mueve todas las callbacks de la Microtask Queue a la Call Stack y las ejecuta una a una hasta que la Microtask Queue queda vacía. Por eso las microtasks tienen “alta prioridad”: se “cuelan” antes de que se ejecute la siguiente macrotask.

  3. Renderizado del navegador (si procede):

    • Tras procesar todas las microtasks y quedar la Call Stack vacía de nuevo, el navegador puede realizar un refresco de renderizado si hay uno pendiente y ha pasado tiempo suficiente (normalmente, 60 FPS ≈ 16,6 ms).

  4. Procesar una macrotask:

    • Finalmente, el Event Loop toma una callback de la Macrotask Queue y la empuja a la Call Stack para su ejecución.
    • Cuando esa macrotask termina, la Call Stack vuelve a quedar vacía y el ciclo (pasos 1-4) se repite.

Esta regla de “una macrotask por iteración” es crucial. Evita que el navegador se quede atascado procesando una larga cadena de callbacks de setTimeout, permitiendo actualizaciones de renderizado e interacción del usuario entre medias.

Microtasks vs. Macrotasks: priorización e implicaciones

La distinción entre microtasks y macrotasks es fundamental para entender el orden de ejecución asíncrona y asegurar la fluidez de la UI.

¿Qué son las Macrotasks?

Las macrotasks (o simplemente tasks) representan unidades de trabajo discretas y mayores. Se programan para ejecutarse después del contexto de ejecución actual y de que todas las microtasks pendientes hayan acabado. Si una macrotask dura demasiado, puede bloquear el hilo principal, provocando una UI “laggy” o no responsiva.

Fuentes comunes de macrotasks:

  • Callbacks de setTimeout()
  • Callbacks de setInterval()
  • Eventos de UI (p. ej., click, mousemove, keydown)
  • Operaciones de E/S (p. ej., XMLHttpRequest.onload, manejo interno de fetch antes de resolver la Promise)
  • requestAnimationFrame (aunque su programación está muy ligada al ciclo de renderizado)

¿Qué son las Microtasks?

Las microtasks (o jobs) son unidades de trabajo más pequeñas y de mayor prioridad. Se ejecutan inmediatamente después del script actual, antes de que se coja la siguiente macrotask de la cola. Son ideales para tareas que deben completarse rápidamente tras una operación asíncrona, como la resolución de Promises, evitando parpadeos o estados inconsistentes.

Fuentes comunes de microtasks:

  • Callbacks de Promise.then(), Promise.catch(), Promise.finally()
  • async/await (azúcar sintáctico sobre Promises; cada await genera microtasks)
  • Callbacks de MutationObserver
  • queueMicrotask() (API dedicada a programar microtasks directamente)

Tabla comparativa: Microtasks vs. Macrotasks

CaracterísticaMicrotasksMacrotasks
PrioridadAlta (se ejecutan antes de la siguiente macrotask)Baja (una por iteración del Event Loop)
EjecuciónTodas las microtasks pendientes se ejecutan consecutivamenteSolo una macrotask pendiente por iteración
FuentesPromise.then(), async/await, MutationObserver, queueMicrotask()setTimeout(), setInterval(), eventos de UI, E/S, requestAnimationFrame
Impacto en la UIPueden retrasar el siguiente render si son demasiadas o muy largasPueden causar jank si una task es demasiado larga
Uso típicoEncadenar operaciones asíncronas, observar el DOM, actualizaciones inmediatas tras PromisesDiferir tareas, manejar entrada de usuario, actualizaciones periódicas

Ejemplo práctico (TypeScript): orden de ejecución

Ilustremos el orden exacto de ejecución en un entorno de navegador.

console.log("1. Script start");

setTimeout(() => {
  console.log("5. setTimeout callback (Macrotask)");
}, 0); // Scheduled as a macrotask

Promise.resolve().then(() => {
  console.log("3. Promise.then callback (Microtask 1)");
  Promise.resolve().then(() => {
    console.log("4. Inner Promise.then callback (Microtask 2)");
  });
});

console.log("2. Script end");

// Simulate a click event
document.addEventListener('click', () => {
  console.log("6. Click event callback (Macrotask)");
  Promise.resolve().then(() => {
    console.log("7. Click event Promise (Microtask 3)");
  });
});

// To trigger the click event, you would manually click somewhere on the page
// or programmatically dispatch an event:
// const button = document.createElement('button');
// document.body.appendChild(button);
// button.click(); // This would trigger the click event listener

Salida esperada (sin hacer clic manualmente):

1. Script start
2. Script end
3. Promise.then callback (Microtask 1)
4. Inner Promise.then callback (Microtask 2)
5. setTimeout callback (Macrotask)

Explicación:

  1. console.log("1. Script start") se ejecuta inmediatamente (síncrono).
  2. Se encuentra setTimeout. Su callback se envía a Web APIs y se programará en la Macrotask Queue tras expirar el temporizador (aunque sea 0 ms).
  3. Se encuentra Promise.resolve().then(). Su callback pasa a la Microtask Queue.
  4. console.log("2. Script end") se ejecuta inmediatamente.
  5. La Call Stack queda vacía. El Event Loop revisa la Microtask Queue.
  6. "3. Promise.then callback (Microtask 1)" se mueve a la Call Stack y se ejecuta. Dentro, otro Promise.resolve().then() encola "4. Inner Promise.then callback (Microtask 2)".
  7. La Call Stack queda vacía de nuevo. El Event Loop revisa la Microtask Queue y encuentra la nueva microtask.
  8. "4. Inner Promise.then callback (Microtask 2)" se mueve a la Call Stack y se ejecuta.
  9. La Call Stack está vacía y la Microtask Queue también.
  10. El Event Loop revisa la Macrotask Queue y encuentra el callback de setTimeout.
  11. "5. setTimeout callback (Macrotask)" se mueve a la Call Stack y se ejecuta.

Si haces clic después de la salida inicial:

6. Click event callback (Macrotask)
7. Click event Promise (Microtask 3)

Explicación del clic:

  1. Se produce el evento click. El navegador coloca su callback en la Macrotask Queue.
  2. En una iteración posterior del Event Loop, tras las microtasks pendientes, el callback de click se recoge como nueva macrotask.
  3. Se ejecuta "6. Click event callback (Macrotask)".
  4. Dentro, Promise.resolve().then() programa "7. Click event Promise (Microtask 3)" en la Microtask Queue.
  5. Tras finalizar "6.", la Call Stack está vacía. El Event Loop procesa inmediatamente la microtask "7. Click event Promise (Microtask 3)".

Eventos DOM y Event Loop: capturando la interacción del usuario

Los eventos DOM (como click, mouseover, submit, input) son una fuente principal de interacción de usuario. Su ejecución se apoya igualmente en el Event Loop.

Cuando usas element.addEventListener('event', callbackFunction), registras callbackFunction con las Web APIs del navegador, que vigilan el evento indicado.

Cuando ocurre el evento:

  1. El mecanismo interno de despacho de eventos del navegador lo detecta.
  2. Coloca la callback correspondiente en la Macrotask Queue.
  3. En un tick posterior del Event Loop (cuando la Call Stack está vacía y no hay microtasks pendientes), esa macrotask se ejecuta, llamando a tu callbackFunction.

Este manejo basado en macrotasks garantiza que las interacciones sigan siendo responsivas. Incluso si tu app está ocupada procesando datos, un clic acabará siendo gestionado porque el Event Loop revisa periódicamente la Macrotask Queue entre renderizados o tareas prolongadas.

Renderizado del navegador y Event Loop: el baile de los frames

La animación fluida de aplicaciones modernas depende de que el navegador renderice nuevos frames a alta frecuencia (≈60 FPS). El Event Loop es crucial aquí, pues el renderizado suele ocurrir entre macrotasks.

Pipeline de renderizado: Cuando el navegador necesita pintar (p. ej., tras un cambio en el DOM), suele seguir estas fases:

  1. Style: calcula estilos.
  2. Layout: determina tamaño y posición de los elementos.
  3. Paint: pinta píxeles (texto, colores, imágenes, bordes).
  4. Compositing: combina capas para la imagen final.

¿Cuándo ocurre el renderizado? Sucede después de que la Call Stack esté vacía y todas las microtasks se hayan ejecutado, pero antes de que se tome la siguiente macrotask. Si tu JS bloquea el hilo principal con una tarea síncrona larga o demasiadas microtasks, se retrasará el próximo render, resultando en “jank” o UI congelada.

requestAnimationFrame (rAF): requestAnimationFrame es una Web API especial para animaciones. Su callback se programa justo antes del próximo repintado, sincronizándose con el ciclo de render y evitando parpadeos.

React y el Event Loop: el tango de la reconciliación

El proceso de reconciliación de React, donde actualiza el DOM en función del estado, se entrelaza profundamente con el Event Loop. Su objetivo es mantener la UI sincronizada de forma eficiente, y sus últimas funcionalidades (especialmente en React 18 con Concurrent Mode) aprovechan la planificación del Event Loop.

Proceso de renderizado de React simplificado:

  1. Fase de render (Reconciliación):

    • Llama a funciones de componentes, ejecuta render, calcula diferencias entre el nuevo y viejo Virtual DOM.
    • Es interrumpible. En Concurrent Mode React puede pausar, ceder control al navegador y reanudar.

  2. Fase de commit:

    • Aplica cambios al DOM real.
    • Es síncrona e ininterrumpible. Métodos como componentDidMount, componentDidUpdate y useLayoutEffect se disparan aquí.

Cómo setState y useState programan actualizaciones

Al llamar a setState o al setter de useState, React programa una actualización. Su planificador interno prioriza y agrupa dichas actualizaciones.

Históricamente, antes de Concurrent Mode, las actualizaciones eran mayormente síncronas o agrupadas en una sola macrotask, lo que podía bloquear el hilo principal.

React 18 Concurrent Mode: aprovechando el Event Loop para la respuesta

React 18 introduce Concurrency, permitiendo trabajar en varias tareas y priorizarlas. No es paralelismo real, sino planificación inteligente que coopera con el Event Loop.

Mecanismos clave:

  • Scheduler: Prioriza actualizaciones; marca urgentes (entrada directa) y no urgentes (carga en segundo plano).
  • Ceder control: Durante la fase de render, React puede “yield” y devolver control al navegador, permitiendo procesar tareas prioritarias y luego reanudar.
  • startTransition y useDeferredValue: APIs para marcar actualizaciones como transiciones (no urgentes).
// React TypeScript Example: Demonstrating Concurrent Updates
import React, { useState, useTransition, useDeferredValue } from 'react';
import { createRoot } from 'react-dom/client';

function App() {
  const [inputValue, setInputValue] = useState('');
  const [listQuery, setListQuery] = useState('');
  const [isPending, startTransition] = useTransition(); // Hook for transitions
  const deferredListQuery = useDeferredValue(listQuery); // Hook for deferred values

  const handleInputChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    const value = e.target.value;
    setInputValue(value); // Urgent update: immediate feedback for input

    // Non-urgent update: deferred search
    startTransition(() => {
      setListQuery(value);
    });
  };

  // Simulate a heavy list rendering based on the deferred value
  const generateList = (query: string) => {
    console.log(`Generating list for: ${query}`); // See when this actually runs
    const items = [];
    for (let i = 0; i < 20000; i++) { // Large number of items to simulate heavy work
      items.push(<li key={i}>{`${query} - Item ${i}`}</li>);
    }
    return items;
  };

  return (
    <div>
      <h1>React Concurrent Features & Event Loop</h1>
      <input
        type="text"
        value={inputValue}
        onChange={handleInputChange}
        placeholder="Type to search..."
      />
      {isPending && <p style={{ color: 'blue' }}>Updating list (pending)...</p>}
      <hr />
      <h2>Search Results:</h2>
      {/* Use deferredListQuery to render the list, allowing input to remain responsive */}
      <ul style={{ opacity: isPending ? 0.5 : 1 }}>
        {generateList(deferredListQuery)}
      </ul>
    </div>
  );
}

const container = document.getElementById('root');
const root = createRoot(container!); // Create a concurrent root
root.render(<App />);

// In your index.html:
// <div id="root"></div>

Explicación:

  1. setInputValue(value): actualización urgente, React la procesa al instante.

  2. startTransition(() => { setListQuery(value); }): marca setListQuery como transición no urgente.

    • Al teclear rápido, setListQuery se llama repetidamente. React puede interrumpirla.
    • generateList es costosa y usa deferredListQuery.
    • useDeferredValue(listQuery): da una versión “obsoleta” del valor mientras la transición está pendiente, manteniendo la UI fluida.
    • Si entra una actualización urgente, React descarta la transición en curso y prioriza la urgente. isPending indica si hay transición.

Este ejemplo muestra cómo React, al comprender el Event Loop, evita que renderizados largos bloqueen la entrada del usuario, logrando una experiencia mucho más suave.

Temas avanzados y trampas

process.nextTick() (solo Node.js)

En Node.js, process.nextTick() es una microtask única que se ejecuta antes de cualquier Promise en la microtask queue y antes de que el Event Loop revise E/S o callbacks de setTimeout. No está disponible en navegadores.

setImmediate() (solo Node.js)

También específico de Node.js, setImmediate() programa un callback para ejecutarse inmediatamente después de la fase actual del Event Loop. Corre después de cualquier setTimeout(..., 0) pero antes de la siguiente iteración que procesaría setTimeout. Tampoco existe en navegadores.

requestIdleCallback() vs. requestAnimationFrame()

  • requestAnimationFrame (rAF): pensado para animaciones; su callback corre justo antes del repintado.
  • requestIdleCallback (rIC): para tareas en segundo plano; su callback se ejecuta cuando el navegador está ocioso, recibiendo un deadline para saber cuánto tiempo queda. Ideal para analítica o cálculos que no deben interferir con la UX.

Errores comunes: bloquear el hilo principal

El mayor peligro es escribir código síncrono prolongado que bloquee la Call Stack, impidiendo operar al Event Loop.

// Anti-pattern: Blocking the main thread
function calculateHeavy() {
  let sum = 0;
  for (let i = 0; i < 1000000000; i++) { // A billion iterations!
    sum += i;
  }
  console.log("Heavy calculation done:", sum);
}

console.log("Start");
calculateHeavy(); // This will block the UI until it finishes
console.log("End");

Cuándo usar Web Workers

Para cálculos realmente intensivos que no pueden dividirse en trozos asíncronos, los Web Workers son la solución. Se ejecutan en un hilo separado y se comunican con el principal mediante mensajes, manteniendo la UI libre.

Conclusión: dominar la asincronía para una UX superior

El Event Loop de JavaScript es mucho más que un gestor de colas; es el orquestador que permite a un lenguaje single-threaded manejar operaciones asíncronas, interacciones de usuario y renderizados dinámicos sin problemas. Para ingenieros avanzados, comprender la Call Stack, Web APIs, Macrotask Queue y Microtask Queue, junto con su interacción en el algoritmo iterativo del Event Loop, es innegociable.

La evolución de React, especialmente con Concurrent Mode en React 18, demuestra cómo un framework puede aprovechar el Event Loop para lograr niveles inéditos de respuesta y concurrencia percibida. Al dominar estos mecanismos, podrás diagnosticar cuellos de botella, optimizar renderizados y crear aplicaciones web fluidas y encantadoras. El orquestador invisible, una vez desmitificado, se convierte en un aliado poderoso en la búsqueda de la excelencia en desarrollo web.

Referencias y recursos