Detailed explanation
Synchronous code executes in sequence: each operation finishes before the next statement runs. On a JavaScript execution thread, a long synchronous operation prevents other JavaScript tasks from running until it completes. For example, with a previously defined future timestamp called end, while (Date.now() < end) {} keeps the thread busy checking the clock. In a browser, this can delay click handlers and rendering, making the page feel frozen. Synchronous code is not inherently bad; ordinary calculations and assignments are usually fast and naturally synchronous.
Asynchronous code lets an operation complete later without requiring the current JavaScript execution to wait for that completion. Browser or Node.js facilities manage operations such as timers and network requests, while JavaScript continues with the remaining synchronous statements. Completion is handled through callbacks, promises, or async/await. Asynchronous does not automatically mean parallel: the JavaScript callback still needs execution time on its thread, even if the runtime performs supporting work elsewhere. CPU-heavy JavaScript does not become non-blocking merely because it is placed inside an async function.
Under the hood, JavaScript executes functions on a call stack. The event loop coordinates when queued work can execute after the current synchronous work finishes. In browsers, a timer such as setTimeout(work, 0) makes its callback eligible for a later task; zero does not mean immediate execution or an exact timing guarantee. Promise reactions and continuations after await use the microtask queue, which is processed before the next task. For example, synchronous console output runs first, a queued Promise.then handler runs next, and an eligible timer callback runs afterwards.
The distinction matters when building responsive interfaces, handling I/O, and reasoning about execution order. Await pauses the surrounding async function until a value or promise settles; it does not block the entire JavaScript thread. Interviewers commonly test whether you can predict output order, explain why timers are delayed, and distinguish waiting for I/O from executing expensive computation. A strong answer connects the blocking loop and timer example while noting that work itself can still block when its callback eventually runs.
Key points to remember
- Synchronous operations finish before execution proceeds to the next statement.
- Asynchronous operations allow completion handling to happen later while current execution continues.
- The event loop coordinates queued work; callbacks cannot interrupt currently running synchronous code.
- Promise handlers and await continuations run as microtasks, before the next timer task.
- Neither setTimeout nor async/await automatically moves CPU-heavy JavaScript to another thread.
Common mistakes candidates make
- Claiming that asynchronous JavaScript always runs in parallel or on a separate thread.
- Saying setTimeout(work, 0) executes immediately rather than scheduling a later callback.
- Assuming await blocks the whole thread or that declaring a function async makes expensive computation non-blocking.
Likely follow-up questions
What runs first: synchronous code, Promise.then, or setTimeout?
For handlers scheduled during the same ordinary script execution, synchronous code finishes first, followed by queued promise microtasks, then eligible timer callbacks. Microtasks queued by other microtasks are also processed before moving to the next task.
Does an async function execute asynchronously from its first statement?
No; its body starts executing synchronously and continues until it reaches an await or completes. After an await, continuation is scheduled as a microtask, even when the awaited value is already resolved.
How can you prevent a CPU-heavy calculation from freezing the interface?
Move suitable computation to a Web Worker so it runs on a separate thread. Alternatively, split the calculation into smaller chunks and yield between them; simply putting the entire calculation inside setTimeout only postpones the blocking.
Interview tip: Start with execution order and blocking, use the loop and timer examples, then explain the event loop and the limitation for CPU-heavy work.