What a JavaScript engine is

In the next ten minutes you will see exactly which stage is responsible for “slow JavaScript” — and why fixing it means working with the engine, not around it.

The engine is a program that runs your program

A JavaScript engine is a native program (V8 is roughly two million lines of C++) whose input is JavaScript source text and whose output is CPU work. It is not a black box: it is a pipeline of well-understood stages, and every stage has a performance personality you can observe and influence.

The naive mental model — “JavaScript is interpreted line by line” — has been wrong for over a decade. Modern engines are adaptive: they start cheap (interpret bytecode) and get expensive only where it pays off (compile to optimised machine code for code that runs many times). The whole track is about that adaptive machinery and how to stay on its fast paths.

The five stages

When you see a V8 flame graph or a Node.js profile that names these stages, you will know exactly where to look. Here is what each one does:

1. Parser — reads the source text and builds an Abstract Syntax Tree (AST), the structured representation of your code. It also does a fast “pre-parse” pass to skip function bodies that have not been called yet (lazy parsing).
2. Interpreter (Ignition in V8) — walks the AST once to emit compact bytecode, then executes that bytecode on a register-based virtual machine. This is where all code starts. It is fast to produce and memory-light.
3. Optimising compilers (Sparkplug, Maglev, TurboFan) — for functions that run often (“hot”), the engine compiles bytecode to native machine code, using runtime type observations to specialise. Faster to run, slower and more memory-hungry to produce.
4. Garbage collector (Orinoco in V8) — runs alongside everything, finding objects nothing references anymore and freeing their memory. You never call free(); the GC infers it.
5. The heap and call stack — the memory where your objects (heap) and your function frames (stack) live. The shape and lifetime of what you put here drives the cost of every other stage.

The art of this track is reading those stages: why a function got compiled and then thrown away (deopt), why an object lookup is slow (shape divergence), why memory keeps climbing (a leak the GC cannot collect).

Engine vs runtime — a distinction that trips people up

The engine implements the ECMAScript language: numbers, objects, functions, prototypes, closures, Promise, garbage collection. That is all it implements. It has no idea what a setTimeout, a fetch, a DOM node, or a file handle is.

Those come from the runtime (the host): the browser, Node.js, Deno, Bun. The runtime embeds the engine and injects host objects and the event loop that schedules them. setTimeout is not JavaScript — it is a function the runtime hands to the engine.

This is why the same engine (V8) powers Chrome, Node, Edge, and Deno with completely different capabilities: same language core, different host. We cover the event loop end-to-end in unit 07; for now, fix the boundary: the engine runs the language, the runtime supplies the world.