How the Engine Runs Your Code: Parse, Bytecode, JIT

David writes a ten-line program that prints a small sales report. The first line is console.log("Starting the report..."), so he expects at least that to appear. He presses Run, and nothing prints at all. The Playground says "Compile error" and shows SyntaxError: Unexpected token ')', pointing at line 10.

Line 10 is the last line. How can the last line stop the first one from running? The engine had not even reached line 10 yet. Or had it?

It had. Before an engine runs a single line, it reads the whole file. This lesson follows a line of code through everything the engine does to it. By the end, David's empty output makes sense, and so will most error messages you meet.

What an engine is

An engine is the program that reads JavaScript text and runs it. Lesson 02 called it the box in the middle of the four sockets. There are three engines that matter, each made by a different organisation.

All three follow the same rulebook, ECMAScript, so your code behaves the same in each. Inside, they are built differently and name their parts differently. This lesson uses V8's names, because V8 runs your Playground code.

So an engine is a program, and three of them run the JavaScript in nearly every browser and server.

Stage 1: the parser reads the whole file first

The first part of the engine is the parser. It reads your text and checks that it follows the grammar of JavaScript. It does this for the whole file before anything runs.

The parser works in two small steps. First it cuts the text into tokens, the words and symbols of the language: return, price, *, count, ;. Then it arranges the tokens into a parse tree, a picture of what the line means.

If the tokens cannot form a valid tree anywhere in the file, the parser stops and reports a SyntaxError. A syntax error means "this is not grammatical JavaScript". Since nothing has run yet, nothing prints. That is exactly what happened to David.

So a SyntaxError comes from stage 1, and it stops the whole file, not just its own line.

Stage 2: bytecode, run by an interpreter

Next, the engine turns the tree into bytecode: a list of tiny, simple instructions, much smaller than JavaScript statements. V8's part that makes and runs bytecode is called Ignition. It is an interpreter, a program that carries out instructions one at a time.

You can see real bytecode. Node.js can print it with a flag, on your own machine. This is what Node 22 printed for the line in Figure 1, inside the small function of Example 1 below:

Ldar a1
Mul a0, [0]
Return

Three instructions. Ldar a1 loads the second argument, count, into a working slot called the accumulator. Mul a0, [0] multiplies it by the first argument, price. Return gives the result back. The [0] points to a slot where the engine notes which types it saw, which matters in stage 3.

The widget below steps one line through the whole journey. Press the step button to move from one stage to the next.

So bytecode is the engine's own short instruction list, and the interpreter runs it straight away.

Stage 3: the JIT compiles the busy code

Running bytecode one instruction at a time is quick to start but not the fastest way to run. A processor runs its own machine code much faster. So V8 watches which functions run often. When one gets "hot", a second part, the optimising compiler called TurboFan, turns it into machine code.

That is what JIT means: just-in-time compilation. The engine compiles code while the program runs, and only the code that is worth it. V8 also has two middle tiers, Sparkplug and Maglev, between Ignition and TurboFan. Other engines have similar tiers under other names.

TurboFan makes guesses to go fast. If price and count were always numbers, it builds machine code for numbers. If a string suddenly arrives, the engine throws that machine code away and goes back to bytecode. Your program still gives the right answer; it only runs slower for a moment.

So the JIT is a compiler that works during the run, and only on the code that runs often.

Interpreted or compiled? Both, and both half right

You will read "JavaScript is an interpreted language" and also "JavaScript is compiled". Each is half true. Every line is interpreted first as bytecode. The busy parts are later compiled to machine code. Neither label describes the whole engine.

The useful difference is when the compiling happens. A C compiler turns the whole program into machine code before it runs, once. A JavaScript engine starts running at once and compiles the hot parts during the run. That is why a JavaScript program starts instantly and then speeds up.

So JavaScript is neither "just interpreted" nor "compiled ahead of time"; it is compiled just in time.

Two errors, two stages

Every error message names its class first. Two classes are worth placing on the pipeline today, because they come from different stages.

A SyntaxError comes from the parser. The file is not grammatical, so nothing runs, not even line 1. Here is David's program with its mistake:

console.log("Starting the report...");
const shop = "Bob's Books";
const sold = 12;
const price = 250;
const total = sold * price;
console.log(shop);
console.log("Books sold: " + sold);
console.log("Price each: " + price);
console.log("Total: " + total);
console.log("Done." +);

The Playground marks the run as a Compile error and prints this in its Compile output tab:

/box/main.js:10
console.log("Done." +);
                     ^

SyntaxError: Unexpected token ')'

The Playground checks your file with the parser before it runs it, which is why it says "compile". The + promised a second value and found ) instead. /box/main.js is the name your code gets inside the Playground's box, and :10 is the line. Node adds two internal lines and its version number under the message; they are left out here.

A ReferenceError comes while the code runs. The grammar was fine, so the program started. Then it reached a name that does not exist. Everything before that line has already run, as Example 2 shows.

So a SyntaxError means "nothing ran", and a ReferenceError means "it ran until this line".

function total(price, count) {
  return price * count;
}

console.log(total(250, 3));

750

console.log("Line 1 runs.");
const total = 5;
console.log(totl);
console.log("Line 4 never runs.");

Line 1 runs.

/box/main.js:3
console.log(totl);
            ^

ReferenceError: totl is not defined

function add(a, b) { return a + b; }
for (let round = 1; round <= 5; round++) {
  const start = process.hrtime.bigint();
  let sum = 0;
  for (let i = 0; i < 100000; i++) sum = add(sum, i);
  const micros = Number(process.hrtime.bigint() - start) / 1000;
  console.log("Round " + round + ": " + micros.toFixed(0) + " microseconds");
}

Round 1: 5415 microseconds
Round 2: 4376 microseconds
Round 3: 4169 microseconds
Round 4: 492 microseconds
Round 5: 147 microseconds

const total = 750;
console.log(Total);

function total(price, count {
  return price * count;
}

console.log("Line 1");

function neverCalled() {
  console.log("inside");
}

function alsoNeverCalled() {
  const x = 1;
  return x +;
}

console.log("Line 1");

function neverCalled() {
  console.log("inside");
}

function alsoNeverCalled() {
  const x = 1;
  return y + x;
}

node --print-bytecode --print-bytecode-filter=total total.js

Next you run your own first line, in three places, and get the same answer from all three.