Parallelism Vs Asynchronicity

I used to treat "parallel" and "async" as two words for the same thing: stuff happening at once. They are not the same claim, and mixing them up hides what your JavaScript is actually doing.

One Register vs Three Registers

Picture a grocery store with one open register. Three customers are waiting, but at any single instant, only one is actually being served. The other two just wait.

Now picture three registers open at once. Three customers get served at the exact same instant, each in their own transaction, none waiting on the others.

ExpandOne register serving customers one at a time versus three registers serving three customers at the same instant.

That second picture is parallelism: two or more things happening at the exact same instant. It needs separate hardware to pull off, separate CPU cores or threads. The first picture, one thing at a time, others waiting their turn, is the one JavaScript actually lives in.

Parallelism Needs Real Hardware

A thread is just a queue of instructions a processor works through. One core runs one thread's instructions while, at that same moment, another core can run a completely different thread's.

Parallelism exists for exactly one reason: speed. Work that doesn't depend on itself finishes faster running at the same instant than running one piece after another.

A modern machine only has a handful of real cores, far fewer than an operating system needs for everything it juggles. A single browser tab alone can easily use ten or more threads just for its own basic work, and a full operating system runs far more than that on top of it.

So the OS fakes the rest, scheduling thousands of "virtual threads" across those few real cores, switching fast enough that you never notice. You never see any of this from your code. You just trust it's handled.

JavaScript Runs on Exactly One Thread

Here's the part that catches people off guard: the browser and the JavaScript engine might use hundreds of threads internally, but your actual JavaScript code only ever runs on one of them.

At any given instant, exactly one line of your code is executing. Two of your own functions are never running at the same instant, the way two customers can be served at the same instant across two registers.

That's not a missing feature. It's why JavaScript never needs locks, semaphores, or any of the defensive machinery multi-threaded languages carry to stop two threads from corrupting the same memory. Only one function ever runs at a time, so there's nothing to protect against.

Web Workers: A Real Second Thread, With a Catch

There is one way to get a real second thread of JavaScript: Web Workers, a browser feature, not a language feature. A worker spins up a whole separate engine instance, on its own thread.

That sounds like real multithreading, and it is, except the two instances share absolutely nothing. No shared variables, no shared functions. Each one might as well not know the other exists.

The only way they exchange anything is through asynchronous messages, the same single-threaded event mechanism the rest of this series already covers. A worker gets you a second thread, not a second way for two threads to talk directly. Everything still passes through events, one message at a time.

The Essentials

1. Parallelism means two or more things happening at the exact same instant, which needs real, separate hardware.
2. Asynchronicity is a different claim: one thread handling work over time, not multiple threads working at once.
3. A JavaScript engine only ever runs one line of code at any instant, no matter how many threads it uses internally for anything else.
4. Single-threaded execution is why JavaScript skips locks and semaphores entirely. Only one function ever runs, so nothing competes for the same data.
5. Web Workers add a real second thread, but not shared memory. The two instances only ever talk through async messages.

Parallelism and asynchronicity are cleared up. Next: what actually happens inside that single thread when JavaScript looks like it's doing several things "at once", which is exactly what concurrency means for a JavaScript developer.