THE GARDEN

Browser runtime, async JavaScript, and the event loop

Updated 12 Oct 2026

• •

  Execution model

  • •

    Agent -> sequential JS execution within an agent.

    • •

      the whole browser is not necessarily single-threaded.

    • •

      async callbacks do not run in parallel on the same stack.

  • •

    Stack -> active function execution contexts, LIFO.

    • •

      call: push context.

    • •

      return: pop context.

  • •

    Heap -> object memory, separate from stack/queue scheduling.

  • •

    Queues -> pending jobs/work.

    • •

      teaching model: FIFO for a queue.

    • •

      browser detail: task sources/queues plus a separate microtask queue; no universal FIFO ordering all timers, input, and network events.

• •

  Synchronous vs asynchronous

  • •

    Synchronous -> execute current work in sequence before moving on.

  • •

    Asynchronous

    • •

      Flow -> delegate waiting work -> continue current JS -> process scheduled completion.

    • •

      useful waits: timers, events, I/O.

    • •

      does not make a long CPU loop nonblocking.

  • •

    Timer example

    • •

      first log: A.

    • •

      request B with a 1,000 ms timer.

    • •

      current work: log C.

    • •

      later callback: log B; output A -> C -> B.

    • •

      delay is a scheduling threshold, not an exact wall-clock execution guarantee.

• •

  Event loop, tasks, and microtasks

  • •

    Useful trace

    • •

      run a runnable task.

    • •

      finish the current stack.

    • •

      drain available microtasks, including newly enqueued ones.

    • •

      rendering opportunity: browser may update rendering.

    • •

      run another runnable task.

  • •

    Tasks

    • •

      examples: asynchronous click/input dispatch and timeout callbacks.

    • •

      Run-to-completion -> queued work cannot interrupt currently running JS on that stack.

  • •

    Microtasks

    • •

      sources: Promise reactions, queueMicrotask(), MutationObserver delivery.

    • •

      timing: at a checkpoint after current JS unwinds, before the next task.

    • •

      returning from one function is not enough while its caller still executes.

    • •

      Execution -> callbacks run synchronously on the stack when their turn arrives.

    • •

      continually adding microtasks can starve tasks/rendering; keep work short.

  • •

    Promise handlers

    • •

      .then() -> success processing, including fetched results.

    • •

      .catch() -> rejection handling.

    • •

      .finally() -> cleanup after settlement, whether success or failure.

    • •

      reactions are scheduled after settlement, not run immediately upon registration.

  • •

    Ordering example

    • •

      console.log("A");
      setTimeout(() => console.log("task"), 0);
      Promise.resolve().then(() => console.log("microtask"));
      console.log("C");
      // A -> C -> microtask -> task
      

• •

  Debounce

  • •

    idea: postpone a function until events stop for a chosen interval.

    • •

      uses: product search, autocomplete, resize, form validation.

  • •

    Trailing-edge behavior

    • •

      new event: cancel the pending timeout.

    • •

      quiet interval: invoke with the latest arguments after roughly 500 ms.

      • •

        function debounce(fn, delay = 500) {
        let timer;
        return function (...args) {
        clearTimeout(timer);
        timer = setTimeout(() => fn.apply(this, args), delay);
        };
        }
        

  • •

    Limits

    • •

      execution can be delayed further.

    • •

      does not cancel an already-started request.

    • •

      does not guarantee arrival order.

• •

◌ Explore connections in Graph view