⏳ Synchronous vs Asynchronous Code

Two Ways to Run Code

Every line of code you write eventually has to run. The question this lesson answers is a simple one with huge consequences: does the program stop and wait for a task to finish, or does it start the task and move on? Those two answers are called synchronous and asynchronous execution.

☕ A coffee-shop analogy. In a synchronous café, each customer orders and then stands at the counter until their drink is finished before the next person can even order. In an asynchronous café, you order, get a buzzer, and step aside — the barista starts several drinks at once and buzzes you when yours is ready. Same barista, dramatically different throughput.

Neither model is "better" in the abstract — each fits different jobs. The skill you're building is recognizing which one a situation calls for.

Synchronous: One Thing at a Time

In synchronous code, statements run in order, top to bottom, and each one must finish completely before the next begins. While a synchronous operation is running, nothing else can happen — we say it blocks.

Key characteristics

• Blocking: a long operation holds up everything behind it.
• Predictable order: the code runs in exactly the sequence you read it.
• Easy to reason about: there is no "later" — line 3 always happens after line 2.

A blocking example

console.log('Starting');

function sumTo(n) {
  let sum = 0;
  for (let i = 1; i <= n; i++) {
    sum += i;
  }
  return sum;
}

// A huge loop that keeps the CPU busy for a noticeable moment
const result = sumTo(2_000_000_000); // blocks here
console.log('Result:', result);
console.log('Finished'); // will NOT print until the loop above is done

Run this in a browser and the tab freezes while sumTo churns: you can't scroll, click, or type. The string 'Finished' only appears once the loop completes, because the single thread is fully occupied.

Synchronous, everyday analogies: reading a book page by page, standing in a single-file line, or a one-lane road where a slow truck delays everyone behind it.

Asynchronous: Start Now, Finish Later

Asynchronous code lets you kick off a task and immediately continue with the rest of your program. When the task eventually finishes, its follow-up code runs. The program never stands around waiting.

Key characteristics

• Non-blocking: slow work happens "in the background," so the main thread stays free.
• Deferred: the follow-up code runs after the current work finishes, not in source order.
• Responsive: the UI keeps reacting to the user the whole time.

The classic surprise

console.log('Starting');

setTimeout(() => {
  console.log('This runs after ~2 seconds');
}, 2000);

console.log('This runs immediately');

// Console output:
// Starting
// This runs immediately
// This runs after ~2 seconds   (about 2s later)

Notice the output order does not match the source order. setTimeout hands its callback to the browser to run later, then execution moves straight on to the next line. The 2000 is a minimum delay, not a guarantee — the callback only runs once the main thread is free (you will see exactly why in the next lesson on the event loop).

Asynchronous, everyday analogies: sending an email and carrying on with your day, or starting a washing machine and cooking dinner while it runs.

Why This Matters in JavaScript

Here is the crux: JavaScript in the browser runs your code on a single main thread — and that same thread is responsible for painting the screen and reacting to clicks, scrolls, and keypresses. If you block it with a long synchronous task, the page cannot repaint or respond. It freezes.

Async work you meet constantly

• Network requests — fetching data from an API or server
• Timers — setTimeout and setInterval
• User events — clicks, keystrokes, scrolls
• File and database access — reading, writing, and querying (especially in Node.js)
• Animations — smooth visual changes over time

Worked Example: Loading a Profile

Imagine a page that needs a user's data and their profile image from a server. Let's contrast a naive blocking design with a responsive asynchronous one.

The blocking version (don't do this)

console.log('App started');

// Pretend these are synchronous, blocking network calls.
// In real code they do not exist — this is the anti-pattern.
const userData = getUserDataBlocking();   // imagine 2 seconds, UI frozen
console.log('User data loaded');

const userImage = getUserImageBlocking(); // imagine 3 more seconds, still frozen
console.log('User image loaded');

renderProfile(userData, userImage);
// Total: ~5 seconds of a completely unresponsive page

For five whole seconds the user cannot do anything. Most people assume the app has crashed.

The asynchronous version (do this)

console.log('App started');

// Modern async: fetch returns a Promise; await pauses THIS function
// without blocking the main thread.
async function loadProfile() {
  const [userData, userImage] = await Promise.all([
    fetch('/api/user').then((res) => res.json()),
    fetch('/api/user/avatar').then((res) => res.blob()),
  ]);

  renderProfile(userData, userImage);
  console.log('Profile rendered');
}

loadProfile();
console.log('UI is interactive while data loads…');

App started
UI is interactive while data loads…
Profile rendered        (once both requests resolve)

Two important wins: the page stays responsive the entire time, and by requesting both resources with Promise.all they load concurrently instead of one-after-another. You'll study fetch, Promises, and async/await in depth soon — for now, notice the shape: start the slow work, don't block, react when it's done.

When to Use Each

Async is powerful, but it adds complexity — execution order becomes less obvious. Reach for it deliberately, not reflexively.

Hands-on Exercise

Summary & Quiz

📚 Further Reading

• MDN — Asynchronous JavaScript
• JavaScript.info — Introduction: callbacks
• MDN — setTimeout()

🚀 What's Next?

You now know that async code runs later — but how does JavaScript decide the exact moment a deferred callback runs? That's the job of the event loop, and it's next.