Introduction

In normal JavaScript execution, a running event handler is not interrupted midway by an AJAX callback. JavaScript runs one piece of synchronous code at a time, so the current handler must return control before another queued callback can run.

The Short Answer

Yes, a currently running event handler runs to completion before an AJAX callback gets a chance to execute.

That guarantee comes from JavaScript's event loop model:

• one call stack
• one currently executing task
• asynchronous completions are queued for later execution

An AJAX completion callback cannot preempt code that is already on the stack.

A Concrete Example

Consider this browser example:

1<button id="btn">Click</button>
2<script>
3  document.getElementById("btn").addEventListener("click", function () {
4    console.log("handler start");
5
6    fetch("/data")
7      .then(() => console.log("fetch callback"));
8
9    for (let i = 0; i < 3; i++) {
10      console.log("working", i);
11    }
12
13    console.log("handler end");
14  });
15</script>

The output order will always keep the synchronous event-handler code together:

• 'handler start'
• 'working 0'
• 'working 1'
• 'working 2'
• 'handler end'
• later, after the request resolves, fetch callback

Even if the network request finishes quickly, the callback still waits until the current handler has finished.

Why This Happens

JavaScript uses an event loop. The important pieces are:

• the call stack, where currently executing functions live
• task queues, where events and many async completions wait
• the microtask queue, where promise continuations wait

A callback from AJAX or fetch is not executed immediately when the HTTP response arrives. Instead, it becomes eligible for later execution. The engine only runs it after the currently executing stack is empty.

Task Queue Versus Microtask Queue

There is an important refinement. Not all callbacks wait in the same queue.

• traditional event callbacks are macrotasks or tasks
• promise continuations such as .then(...) are microtasks

Microtasks run before the next task, but only after the current synchronous execution finishes.

That means even promise-based callbacks still do not interrupt the current event handler.

1button.addEventListener("click", () => {
2  console.log("click start");
3
4  Promise.resolve().then(() => {
5    console.log("microtask");
6  });
7
8  console.log("click end");
9});

The order is still:

• 'click start'
• 'click end'
• 'microtask'

So the rule is stronger than just AJAX behavior. Synchronous execution runs to completion before queued asynchronous work executes.

What Is Not Guaranteed

What is not guaranteed is the ordering between unrelated future callbacks unless you control it explicitly.

For example:

• two network requests can finish in either order
• a timer and an AJAX completion may race
• a later user event may arrive before a slower request completes

So the guarantee is local:

• current synchronous handler finishes first

It is not a global guarantee that all future callbacks happen in a particular order.

How To Enforce Ordering Explicitly

If your logic depends on one async step finishing before another begins, encode that dependency in the code.

1async function loadData() {
2  const response = await fetch("/data");
3  const json = await response.json();
4  return json;
5}
6
7button.addEventListener("click", async () => {
8  console.log("before load");
9  const data = await loadData();
10  console.log("after load", data);
11});

This does not change the event-loop rule. It just makes the ordering explicit and readable.

Common Pitfalls

A common mistake is thinking asynchronous completion can interrupt a long-running event handler. It cannot, but that does not make long handlers safe. They still block the UI and delay every other callback.

Another issue is confusing "runs after the current handler" with "runs in the order I mentally expect". Multiple async sources can still complete in surprising sequences.

Developers also sometimes forget the microtask queue. Promise callbacks run sooner than the next task, but still only after current synchronous code has finished.

Finally, do not rely on AJAX timing for correctness. If order matters, express that dependency directly with callbacks, promises, or async and await.

Summary

• A running JavaScript event handler completes before an AJAX callback can execute.
• JavaScript does not preempt currently executing synchronous code with async callbacks.
• Promise microtasks also wait until the current stack is empty.
• The guarantee applies to the current handler, not to all future callback ordering.
• Use explicit async control flow when callback order matters to the program.