Not Many Threads—But Many Moments: Understanding Concurrency in JavaScript

At first, JavaScript seems limited.

It runs on a single thread.

One thing at a time.

One call stack.

And yet, it can:

• fetch data
• respond to user input
• animate UI
• handle multiple requests

All without freezing.

It feels like many things are happening at once.

But they aren’t.

At least—not in the way you might expect.

The Illusion of “At the Same Time”

JavaScript does not run multiple pieces of code simultaneously.

It doesn’t split execution across threads.

Instead, it creates the illusion of concurrency.

Not by doing more—

but by deciding when to do things.

The Role of the Event Loop

At the center of this illusion is the event loop.

There is always a single flow:

• execute what’s on the call stack
• take the next task from the queue
• execute again

And repeat.

But while JavaScript is busy with one task, other operations—like network requests—are handled elsewhere.

When they finish, they don’t interrupt.

They wait.

They enter a queue.

And only when JavaScript is ready does it pick them up.

Not All Tasks Are Equal

Some tasks are treated with higher priority.

Promises, for example, are handled before timers.

This creates a subtle ordering:

• synchronous code runs first
• microtasks (like Promise.then) run next
• macrotasks (like setTimeout) run after

This ordering is what makes the system predictable.

And sometimes surprising.

Concurrency Is About Coordination

Because JavaScript doesn’t run things in parallel, concurrency becomes a matter of coordination.

Consider two requests:

await fetchA()
await fetchB()

This is sequential.

One waits for the other.

But if you start them together:

const a = fetchA()
const b = fetchB()

await a
await b

Now they overlap.

Not because JavaScript is running them at the same time—

but because it doesn’t wait before moving on.

The difference is not in execution.

It’s in timing.

When Timing Becomes a Problem

This is where things get interesting.

If two asynchronous operations finish in an unexpected order, you get a race condition.

An older request might overwrite newer data.

The system doesn’t fail.

It just becomes inconsistent.

And the fix is not to make things faster—

but to make them coherent.

To decide which result should matter.

Blocking: The Enemy of Concurrency

Because everything runs on one thread, blocking that thread stops everything.

A long loop.

A heavy calculation.

And suddenly:

• no UI updates
• no event handling
• no progress

Concurrency depends on one principle:

Never block the flow

Controlling the Flow

Sometimes, you don’t want everything to run freely.

You want control.

• limit how many requests run at once
• delay execution until input stabilizes
• prevent repeated triggers

This is where patterns like throttling and debouncing appear.

They don’t make things faster.

They make them manageable.

A Different Perspective

It helps to stop thinking of concurrency as:

“doing many things at once”

And start thinking of it as:

“deciding what gets to run next, and when”

JavaScript is not parallel.

It is scheduled.

Where It All Connects

You’ve seen this idea before.

• Vue schedules updates
• the browser schedules rendering
• the event loop schedules execution

Different layers.

Same idea.

Everything is about timing.

A Final Thought

JavaScript doesn’t gain power by splitting into many threads.

It gains power by staying single-threaded—

and becoming extremely good at managing time.

What feels like concurrency is not simultaneous execution.

It’s carefully ordered progress.

And once you see that,

you stop asking:

“How do I run things at the same time?”

And start asking:

“How do I let things happen without getting in each other’s way?”