How Does the JavaScript Engine Run Code?

The pipeline has four stages, and the first two are not what most people expect. Your source text is parsed into a tree that describes the shape of the program. That tree is then compiled into bytecode, and the bytecode is what the interpreter runs first. Only after a function proves that it is used often does the engine promote it to machine code with a just-in-time compiler.

function add(a, b) {
  return a + b;
}

console.log(add(2, 3)); // 5
console.log(add(2, 3)); // 5, and now the engine may optimise it

Two useful details come from the parsing step. The parser is also where syntax errors are reported, so a misplaced brace never reaches the running code. The engine also collects information about each function while it parses, such as which variables the function closes over, and that is how it can set up the right shape of environment without running the code at all.

The promotion to machine code is what makes the language fast in practice. The just-in-time compiler guesses the types it has already seen, copies small functions into their callers, and removes branches that can never run. When one of those guesses turns out to be wrong at runtime, the engine throws the fast version away and goes back to the slower path, which is why a function that behaves in one way for months and then suddenly meets a new type can get slower all at once.

Precompilation and streaming compilation exist because of this pipeline. A browser can parse ahead of execution while the script is still downloading, and a server can compile a module to bytecode, and sometimes to machine code, while the build is running.

Both, and the honest answer is that modern engines do both of them. The word "interpreted" is a poor description of what V8, SpiderMonkey, and JavaScriptCore actually do today.

Here is the short version of the pipeline. The engine parses your source into a tree, compiles that tree into bytecode, and then runs the bytecode with an interpreter. When a function or a loop body turns out to be called very often, the just-in-time compiler translates that bytecode into optimised machine code for the processor you are running on, and it patches the call sites to point at the faster version. If the optimised code meets a case that it did not expect, the engine throws it away, returns to the interpreter, and tries again later.

The correct way to describe it is that JavaScript is always compiled to bytecode first, and hot code is compiled further into machine code while the program runs. That is why a function called in a tight loop a hundred thousand times can end up several times faster than the same function called once, and why benchmarking code with no warm-up phase gives you numbers that mislead.

There is a practical consequence for the way you write code. Consistent types help. If a parameter is always a number, the engine can keep the fast numeric path. If the same place sometimes receives a string and sometimes receives a number, the engine has to keep both paths ready and the optimisation becomes weaker. This is the reasoning behind typed arrays for numeric code, and behind avoiding wildly different object shapes in hot code.

Hidden classes are the engine's private way of describing the shape of an object, which means the order of its properties and the types of their values. Every object points at one of these shapes, and a property lookup walks a linked list of known shapes instead of doing a generic search every single time.

const a = { x: 1, y: 2 };
const b = { x: 1 };
b.z = 3;

// Objects built the same way share a shape:
const c = { x: 1, y: 2 };
console.log(Object.getPrototypeOf(a) === Object.getPrototypeOf(c)); // true
console.log(Object.getPrototypeOf(a) === Object.getPrototypeOf(b)); // false

When you create an object literal, the engine walks a tree of shapes. There is the shape with x, then the shape with x and y, then the shape with x, y, and z. Two objects that are built the same way share one shape, and the engine remembers the answer to each lookup, which is called an inline cache. The second time you read b.z, the engine already knows the answer.

When the shapes drift apart, that memory stops helping you. If some objects have a property and others do not, the place where you read it becomes polymorphic, and if the shapes are very different it becomes megamorphic, where the engine has to fall back to a slower dictionary lookup. That is the real reason megamorphic places are slow in hot code, and it is also why adding a property to an object after it was created costs more than declaring it up front.

You will rarely touch hidden classes directly. Knowing the idea explains two practical rules though. Build your objects with a consistent shape, and prefer an array of values that all have the same type when you are processing a large amount of data.