Synchronous vs asynchronous

Now or later: the main idea

JavaScript runs your code one line at a time. Most lines finish at once, and then the next line runs. But some jobs take time, like waiting for a timer or for data from a server. This lesson is about one question: does your code wait for the job right now, or does it keep going and deal with the result later?

Two words name the two ways:

• Synchronous code ("sync" for short) runs now. The next line waits until it is done.
• Asynchronous code ("async" for short) starts a job now and deals with the result later. The next line does not wait.

In a browser, your JavaScript runs on the main thread. The main thread is the one worker that runs your code. The browser uses the same worker to draw the page and to handle clicks. So if your code keeps the main thread busy, the page can't do anything else.

You met the host in Engines, runtimes & hosts. The host is the program that runs JavaScript, such as a browser or Node. You saw how the host lines up waiting work in The JavaScript runtime at a glance. This lesson uses both ideas with everyday code: timers, click handlers, and callbacks. A callback is a function you pass to other code, so that code can call it. You met callbacks in Function expressions & callbacks.

Blocking means JavaScript keeps the main thread so busy that the browser can't do its own jobs. While the main thread is blocked, the browser can't:

• draw changes on the page,
• scroll smoothly,
• respond to clicks or key presses.

Any long job in JavaScript does this. A long calculation blocks. So does a loop that does nothing but wait. So does JSON.parse on a huge piece of text. (JSON.parse turns JSON text into a JavaScript value.) In each case, JavaScript is busy now, so everything else waits.

Try it below. The kitchen experiment has two ways to "bake":

• The synchronous bake runs a loop for just under a second. The loop keeps checking the clock until the time is up.
• The asynchronous bake asks the host's timer to wait instead. JavaScript stays free.

Watch the counter. It tries to go up ten times a second. The loop is kept short on purpose, so it can't freeze the page for long.

1function bakeSynchronously() {2  const started = performance.now();3  while (performance.now() - started < 1000) {4    // JavaScript is busy here, so the page can't update.5  }6  console.log("sync bake done");7}8 9function bakeAsynchronously() {10  setTimeout(() => {11    console.log("async bake done");12  }, 1000);13}

During the synchronous bake, the counter stops. Even that small number can't be drawn again. The browser may notice your click or key press, but it can't run the code for it until JavaScript is done with the main thread. That is why real websites never wait with a loop like this.

console.log("work starts");
for (let i = 0; i < 3; i = i + 1) {
  console.log("work " + i);
}
console.log("work ends");

Line 1 prints work starts. The loop on lines 2 to 4 prints work 0, work 1, and work 2. Then line 5 prints work ends. Each line waits for the one before it. If the loop ran a million times, the page would wait for all of them.

The JavaScript language itself has no timer, no web page, no files, and no network. The host adds them. A host API is a tool the host gives to JavaScript. Some examples:

• setTimeout runs a function after a delay, in browsers and in Node.
• fetch asks a server for data.
• Node has tools that read files.

When you call a host API, JavaScript hands the job to the host. If you pass a callback, the host keeps it for later. It does not run it yet.

1console.log("1. JS starts the recipe");2setTimeout(() => {3  console.log("3. host puts the callback back");4}, 1000);5console.log("2. JS keeps cooking");

This is how async code keeps a page quick to react. The waiting happens in the host, not in JavaScript. A timer callback, a click handler, and a handler for server data all work the same way: the host hands them back later. Promises are another way to work with a result that comes later. You'll see them further down.

console.log("order placed");
setTimeout(() => console.log("tea ready"), 0);
console.log("next order");

Line 1 prints order placed. Line 2 hands the timer and its callback to the host. JavaScript doesn't wait, so line 3 prints next order. After the script ends, the host hands the callback back, and it prints tea ready.

The waiting happened in the host. The callback itself still runs as JavaScript, on the main thread.

A callback is a function you pass to other code. That other code decides when to call it.

• Some callbacks run right away. array.map calls its callback once for each item, while map is still running.
• Other callbacks run later. A timer callback, an event listener, and a handler for server data all wait until the host has something to report. (An event listener is a function that runs when something happens, such as a click.)

The classic test is setTimeout(..., 0). The 0 is the delay in milliseconds. A delay of zero does not mean "run right now". It means "host, hand this callback back as soon as you can, after the current script ends".

1console.log("A: start");Run2setTimeout(() => {3  console.log("B: timer callback");4}, 0);5console.log("C: end");

Being a function doesn't make a callback async. The code that receives the callback decides when to call it. Knowing this prevents many "why is this value not ready yet?" bugs.

Three ways to run code later

Callbacks, promises, and async/await all do the same thing: start a job now, then deal with its result later. None of them makes the job faster. None of them makes two pieces of JavaScript run at the same time.

function greetLater(callback) {
  setTimeout(() => callback("Asha"), 0);
}
greetLater((user) => console.log("Hello, " + user));
console.log("message sent");

greetLater receives a function called callback and gives it to the timer. So the call to greetLater on line 4 finishes before the callback runs. That is why line 5 prints message sent first, and then the callback prints Hello, Asha.

Promise.resolve("tea").then((drink) => {
  console.log("ready: " + drink);
});
console.log("order placed");

A promise is an object that stands for a result that may arrive later. Promise.resolve("tea") makes a promise that already holds "tea". then attaches a handler: a function that receives the result. Even though the result is already there, then still runs its handler later. That is why the output is order placed, then ready: tea.

async function makeOrder() {
  const drink = await Promise.resolve("tea");
  console.log("ready: " + drink);
}
makeOrder();
console.log("order placed");

The async keyword makes a function return a promise. await pauses that one function until the promise has its result. It does not freeze the whole page. While makeOrder is paused, the rest of the script runs, so line 6 prints order placed first.

Run to completion means JavaScript finishes the code it is running before it starts anything else. A timer can be ready while a loop is running, but it can't cut in. The timer callback waits until the loop and the rest of the script are done.

This rule makes code easier to follow. While your function runs, no callback can jump in and change its variables halfway through.

1setTimeout(() => {Run2  console.log("timer callback");3}, 0);4console.log("loop starts");5for (let i = 0; i < 3; i = i + 1) {6  console.log("loop " + i);7}8console.log("loop ends");

The table below sums up the two ways. Read each row as a question, then the answer for sync code and for async code.

This also explains the old browser pop-up boxes alert and prompt. While the box is open, the whole page waits. The Talking to the user lesson shows how to use them. For now, remember that they block the main thread, so use them with care.

Where you'll use this

The sync/async split shows up whenever code waits for something. Some examples:

• a search box that waits until you stop typing, then searches,
• a loading spinner that spins while data comes back from a server,
• a progress bar while a file uploads,
• a Save button that keeps working while your data is sent to a server.

For example, checking one form field can happen now. Asking a server whether a username is free should be async. Drawing a small part of the page can happen now. Reading a giant reply or filtering a huge list may need splitting, so it doesn't block typing.

function showResults(results) {
  console.log("showing " + results.length + " results");
}

setTimeout(() => showResults(["tea", "toast"]), 0);
console.log("searching...");

Line 6 prints searching... right away. The timer on line 5 stands in for the wait for the server. When the timer is done, its callback passes two items to showResults, which prints showing 2 results. A real app would show the results on the page instead of printing them.

Common mistakes

Read each explanation, even when you got the answer right. A wrong choice often sounds almost right.

Key takeaways

• Synchronous code runs now. The next line waits until it is done.
• Blocking the main thread freezes the page. The browser draws the page and handles clicks on that same thread.
• Host APIs, such as timers, events, fetch, and file reads, do the waiting outside JavaScript.
• Callbacks given to host APIs run later. Callbacks given to map run now.
• Run to completion: a ready callback waits until the current script or callback is done.

Up next: Timers: setTimeout & setInterval.