DEV Community

CodeWithIshwar
CodeWithIshwar

Posted on

`setTimeout()` Is NOT Part of JavaScript

Most developers write this code every day:

```js id="e9u2xa"
setTimeout(() => {
console.log("Hello");
}, 2000);




and assume JavaScript is responsible for the timer.

But that’s not actually true.

## The surprising reality

JavaScript engines like V8 do **not** have built-in timer functionality.

V8 only knows how to:

* parse JavaScript
* compile JavaScript
* execute JavaScript

That’s it.

Functions like:

* `setTimeout()`
* `fetch()`
* `addEventListener()`
* `console.log()`

are **not provided by JavaScript itself**.

They come from the runtime environment:

* Browsers
* Node.js
* Native system libraries

---

# What happens when `setTimeout()` runs?

When you execute:



```js id="n5lf4v"
setTimeout(callback, 2000);
Enter fullscreen mode Exit fullscreen mode

the flow is roughly:

```text id="38dxux"
JavaScript

V8 Engine

Runtime Bindings

Native C/C++ APIs

Operating System




The runtime delegates the timer to native code.

In browsers:

* Web APIs handle timers

In Node.js:

* libuv handles timers and async I/O

The OS performs the actual waiting.

Once the timer completes:

1. The callback enters the task queue
2. The event loop detects it
3. JavaScript executes it when the call stack is empty

---

# Simplified internal implementation

Browser/runtime internals conceptually look like this:



```cpp id="8b45pi"
void SetTimeoutCallback(args) {
  StartTimer(delay, [=]() {
    task_queue.push(jsCallback);
  });
}
Enter fullscreen mode Exit fullscreen mode

The important takeaway:

➡️ The timer itself never runs inside JavaScript.


Why JavaScript feels asynchronous

JavaScript is single-threaded.

So how can it handle:

  • timers
  • networking
  • file systems
  • user events

without blocking?

Because the expensive work happens outside the JS engine entirely.

JavaScript delegates async operations to native runtime systems.

The event loop simply coordinates completed work back into JS execution.


This architecture powers almost everything

API Backed by
fetch() Native networking stack
addEventListener() Browser event system
console.log() Native stdout handling
fs.readFile() OS file system calls
Timers Browser APIs / libuv

Why understanding this matters

Once you understand this model, concepts like:

  • Event Loop
  • Async/Await
  • Promises
  • Node.js internals
  • Browser APIs
  • Performance bottlenecks

become much easier to reason about.

One of the biggest mindset shifts in JavaScript is realizing:

JavaScript itself is actually a very small language.

Most of the “magic” developers use daily comes from the runtime around it.

Top comments (0)