Synchronous vs Asynchronous Execution

1Synchronous Execution

In synchronous code, each statement finishes completely before the next one starts. Nothing else can happen while a synchronous operation is running — the entire program is blocked.

console.log("1");
console.log("2");
console.log("3");
// always prints 1, 2, 3 — strictly in order, nothing can interleave

2Why Asynchronous Execution Exists

JavaScript is single-threaded — only one line of code executes at any given instant. If a slow operation (reading a file, waiting for a network response, a timer) blocked that single thread, the entire program — including UI rendering in a browser — would freeze until it finished.

Asynchronous operations let JavaScript start a slow operation, immediately move on to other code, and come back to handle the result later, once it's ready — without blocking anything in the meantime.

console.log("1: start");
setTimeout(() => console.log("3: timer finished"), 1000);
console.log("2: end");
// prints: 1: start, 2: end, 3: timer finished
// "2: end" runs BEFORE the timer callback, even though setTimeout was called first

3Blocking vs Non-Blocking

// BLOCKING — synchronous, freezes everything until done
function blockingWait(ms) {
  const start = Date.now();
  while (Date.now() - start < ms) {} // busy-loop, wastes CPU, blocks the thread
}
console.log("before");
blockingWait(2000); // nothing else can run for 2 seconds — the whole program is frozen
console.log("after");

// NON-BLOCKING — asynchronous, lets other code run in the meantime
console.log("before");
setTimeout(() => console.log("after (async)"), 2000);
console.log("other code runs immediately, unblocked");

4The Three Ways to Write Async Code (Overview)

All three are ultimately built on the same underlying mechanism — the event loop (its own topic) — which decides when queued async callbacks actually get to run.

5Synchronous Code Always Runs to Completion First

A critical rule: all currently-running synchronous code finishes completely before any queued asynchronous callback gets a turn — no matter how short the async delay was set to.

console.log("A");
setTimeout(() => console.log("C"), 0); // even 0ms delay doesn't mean "immediately"
console.log("B");
// always: A, B, C — never A, C, B

setTimeout(fn, 0) does not mean "run fn right now" — it means "run fn as soon as possible after the current synchronous code finishes and the call stack is empty."

fetch() / http.request()   → OS-level async I/O (epoll/kqueue) → NO extra thread consumed
fs.readFile() / fs.stat()   → libuv's fixed-size thread pool (default 4 threads)

⚠️ Common Pitfalls

1. Assuming setTimeout(fn, 0) runs immediately — it always waits for the current synchronous block to finish first, however brief the delay.
2. Writing blocking loops for delays — a busy-wait loop like blockingWait above freezes the entire program (and, in a browser, the UI); always prefer setTimeout/Promises for delays.
3. Expecting async operations to complete in the order they were started — without proper sequencing (await, .then() chains), multiple async operations started together can finish in any order, depending on how long each actually takes.
4. Forgetting synchronous code inside an async callback still blocks — once an async callback does start running, any synchronous code inside it still runs to completion before yielding control again.

📋 Quick Reference

sync    → blocks, runs top to bottom, one thing at a time, no gaps
async    → starts an operation, returns control immediately, result handled later
setTimeout(fn, 0)  → "as soon as possible after current sync code finishes," not "now"

🎤 Interview Q&A

🛠️ Practice exercises

Each exercise is a file in this topic folder. Code exercises are self-checking: run them and make the checks pass.

Source: js_sync_vs_async_execution_theory.md · generated by tools/build_lessons.py