DEV Community

Mohamed Idris
Mohamed Idris

Posted on

"Concurrency" vs "Parallelism": One Cook Juggling vs Two Cooks Cooking

#webdev #beginners

Everyone uses these two words like they mean the same thing. They don't, and the
difference is actually kind of beautiful once it clicks. Let's make it click.

The idea in one line

Concurrency = dealing with many things at once by switching between them.
Parallelism = doing many things at once, truly at the same instant.

The metaphor: the kitchen 

CONCURRENCY                         PARALLELISM
one cook, many dishes               two cooks, two dishes
stirs soup, then chops, then        each cooking at the same
back to the soup...                 real moment
= juggling, fast switching          = literally simultaneous
Enter fullscreen mode Exit fullscreen mode

One cook can handle three dishes by switching: stir the soup, while it
simmers go chop veggies, pop back to the soup. They're never doing two things in
the same instant, but they keep all three moving. That's concurrency.

Two cooks each working a dish at the very same moment? That's
parallelism. Real simultaneous work, which needs more than one worker.

So: concurrency is about structure (juggling many tasks), parallelism is
about execution (more than one happening at the literal same time).

How it shows up in code

JavaScript is famous for being a single cook (one main thread) that is great
at concurrency. While it waits on a slow thing, it goes does other work.

// Concurrency: one thread, but it doesn't freeze while waiting
const [user, posts] = await Promise.all([
  fetch("/user"),    // start this...
  fetch("/posts"),   // ...and this, without waiting for the first to finish
])
// While the network is busy, the one thread is free to handle other stuff.
Enter fullscreen mode Exit fullscreen mode

The single cook fired off both orders, then handled other things while waiting.
That's concurrency without parallelism: one worker, no freezing.

True parallelism needs more workers. In the browser that's Web Workers; on a
server it's multiple threads or processes running on multiple CPU cores at once.

CPU core 1:  [ resize image A ]      <- these two really run
CPU core 2:  [ resize image B ]         at the same instant = parallel
Enter fullscreen mode Exit fullscreen mode

A real case

  • Waiting on slow stuff (network, disk, database)? You want concurrency. One worker stays busy instead of freezing. This is most web code.
  • Heavy number crunching (resize 1000 images, crunch big math)? You want parallelism, real extra workers on extra CPU cores.

A useful line: concurrency is great for waiting, parallelism is great for
working.

Gotchas juniors hit

1. Thinking async/await makes things parallel.
It doesn't. It makes them concurrent. One thread, not frozen while waiting. Real
parallel work needs more workers.

2. Awaiting things one by one when they could overlap.
Two await fetch() lines run one after the other. Promise.all lets them
overlap. Same single cook, but smarter juggling.

3. Assuming more workers always means faster.
Coordinating many cooks has its own cost (and shared data brings race
conditions). Sometimes one well-organized cook wins.

Recap

  • Concurrency = juggling many tasks by switching (one cook, no freezing).
  • Parallelism = truly doing many at once (multiple cooks, multiple cores).
  • JS is a single cook that's great at concurrency.
  • Concurrency shines for waiting; parallelism shines for heavy work.

Your turn

Look at code where you await two slow calls back to back. Could they overlap
with Promise.all? That tiny change is concurrency working for you. Then explain
"one cook juggling vs two cooks cooking" to a friend.

Top comments (0)