6.1 — Sync vs async
A fact that shapes everything in this phase: JavaScript runs your code on one single thread — one worker, one call stack, one line executing at any instant. When that thread is busy, everything else on the page waits: clicks go dead, animations freeze, typing vanishes into the void. You've seen this — every "page unresponsive" dialog ever.
So how does one thread handle slow things — a network reply taking 2 seconds, a timer, a file? By refusing to wait. Asynchronous means "not now — later": hand the waiting to the environment, keep the thread moving, and deal with the result when it arrives.
This lesson shows the problem raw; the next one reveals the beautiful machinery that makes "later" actually work.
console.log("order placed");
const until = Date.now() + 3000;
while (Date.now() < until) {
// the only thread is TRAPPED here
}
console.log("3 seconds of nothing else");One thread = one call stack, the tower from 3.6. Every click handler, every animation frame, every line of yours — ALL of it must take turns on this single tower. Keep that image; it makes everything else in this phase obvious.
The deeper story, with the real names for things — this part is what turns “I saw it” into “I can explain it.”
Vocabulary, precisely: synchronous code runs now, in order, each line waiting for the previous — everything you've written until today.
Asynchronous code is scheduled now but runs later, when its moment comes (timer done, reply arrived) and the stack is free.
Blocking is synchronous code that takes long enough to hurt — the thing async exists to avoid. JavaScript's design bet: never block; always schedule.
Why one thread at all? Simplicity that pays daily. Your code never runs at the same instant as other code. So two functions can never modify the same object at the same moment — a whole universe of multithreading bugs (locks, races) cannot happen. The price is discipline: keep every turn on the stack SHORT.
Fun fact: a busy restaurant runs on this model. One waiter (the thread) never waits at your table while the kitchen cooks — that is blocking. They take the order, hand it to the kitchen (the environment), serve other tables, and return when the bell rings. One waiter, forty tables, nobody starves — as long as the waiter never stirs a pot personally.
⌨️ prove the thread never waits
Write three prints where the MIDDLE one is scheduled for later — and the output order proves the thread sailed past it without waiting.
requirements:
- Print
"start". - Schedule a function that prints
"ding"to run after50milliseconds — scheduled now, executed later. - Print
"end"immediately after scheduling. The console must show start, end, ding — in that order. If ding comes second, the thread waited, and you’ve missed the point.
when you press RUN, the console must show exactly:
✏️ Quick check 1
Type the LAST line this prints:
console.log("A");
setTimeout(() => console.log("C"), 1000);
console.log("B");✏️ Quick check 2
JavaScript executes your code on how many threads? Type the number.
✏️ Quick check 3
While a long while-loop spins on the stack, a user clicks a button. Does its handler run during the loop? Type yes or no.
🗣️ Now teach it back
Explain to a friend: what does “JavaScript is single-threaded” mean, what is blocking and why is it so bad in a browser, and how does setTimeout let one thread handle waiting without standing still?
Write it as if your friend is sitting next to you. Saved to your journal — future-you will use these notes to teach others.