62. Parsing JavaScript for real

Most of the code is never called

Drip’s compiler from chapter 48 works on a whole program in one go: every function is parsed and turned into bytecode before anything runs. For a test script that’s fine.

A web page is different. It might ship a framework, a date library and the code for a settings dialog nobody opens today, and it has to start fast. In 2019 the V8 team listed the costs of compiling such code eagerly: CPU time that delays the code that is needed, memory for the bytecode, and disk space in the cache. Parsing and compiling sit on the critical path of page startup^[1]. So the cheapest parse is the one you never do.

Lazy parsing

All major browsers parse JavaScript lazily^[1]. When V8’s parser reaches a function body, it can hand it to the preparser, a stripped-down copy of the parser that skims the body without building a syntax tree. When the function is called for the first time, V8 parses it properly and compiles it then. Step through a small file:

function used() { return 1; }
function unused() { return 2; }
const eager = (function () {
  return 3;
});
used();

This is no simulation. V8 can log these events. Here is the same file:

// lazy.js
function used() { return 1; }
function unused() { return 2; }
const eager = (function () {
  return 3;
});
used();

// node --log-function-events
//   --logfile=fe.log lazy.js
// Node v22.23.4, V8 12.4.254.21
// event, start, end, name (lines for
// the whole file left out)
preparse-resolution  13  29 used
preparse-resolution  45  61 unused
full-parse           86 104
interpreter          86 104 eager
full-parse           13  29 used
parse-function       13  29 used
interpreter          13  29 used
first-execution      13  29 used

The numbers are character positions in the file. used and unused were preparsed. The parenthesized function was fully parsed and compiled straight away. When used() ran, it got its full parse and its bytecode (the interpreter event). unused never got past the preparser.

Skimming is harder than it looks

Why not just jump to the matching }? Because finding it means understanding the syntax. A brace can sit inside a string, a comment, a regular expression or a template literal. In 2025 the V8 team put it bluntly: there is no shortcut of counting curly braces; the grammar is too complex^[2].

const src = '{ return "}"; } more';
let depth = 0, end = -1;
for (let i = 0; i < src.length; i++) {
  if (src[i] === '{') depth++;
  if (src[i] === '}') depth--;
  if (depth === 0) { end = i; break; }
}
console.log(end, src.slice(0, end + 1));
// It stopped at the } in the string.

The preparser also has to keep some information. Remember closures from chapter 57: a variable that an inner function captures must outlive its function call, so V8 stores it in a heap-allocated context instead of on the stack. Whether a variable needs that depends on the functions nested inside, so the preparser tracks the variables each skipped body declares and refers to^[1].

And because the language demands it, a syntax error inside a function nobody calls still stops the whole script:

const src = `
function never() {
  return 1 +;
}
return 'ran';`;
try {
  const f = new Function(src);
  console.log(f());
} catch (e) {
  console.log(e.name);
}
// never() is never called, but the
// whole thing still fails to load.

Guessing what will be called

Lazy parsing has a cost when it guesses wrong. A function that is preparsed and then called gets parsed twice: once to skim, once for real. Since V8 6.3 (Chrome 63, 2017) it’s at most twice, however deeply the function is nested^[1].

So V8 guesses. A function written in parentheses, (function () {…}), is usually an immediately-invoked function, so V8 parses and compiles it eagerly as soon as it sees (function. The team calls these PIFEs, possibly-invoked function expressions^[1]. That’s why eager was compiled before anything ran.

Developers can give hints too. In 2025 the team wrote that Chrome 136 compiles every function in a file eagerly if the file starts with the magic comment //# allFunctionsCalledOnLoad, and warned to use it sparingly, because compiling too much costs time and memory^[2].

Don’t compile it again: bytecode caches

Lazy parsing saves work on the first visit. A bytecode cache saves it on the next one. V8 can serialize compiled code into bytes, and a later compile of the same script can rebuild it from those bytes instead of parsing and compiling^[3]. Chrome uses this in three steps^[5]:

Since Chrome 66 (2018) the cache is made after the script’s top level has run, so it also holds lazy functions that ran during startup^[4]. Node exposes the same machinery through vm.Script^[6]:

const vm = require('node:vm');
const src = `
function add(a, b) { return a + b; }
function sub(a, b) { return a - b; }
add(1, 2);`;
const s = new vm.Script(src);
const before = s.createCachedData();
s.runInThisContext();
const after = s.createCachedData();
console.log(before.length, after.length);

const s2 = new vm.Script(src,
  { cachedData: after });
console.log(s2.cachedDataRejected);
const s3 = new vm.Script(src + ' ',
  { cachedData: after });
console.log(s3.cachedDataRejected);

Node v22.23.4, V8 12.4.254.21
528 672
false
true

After running, the cache grew: add had been compiled by then, so its bytecode came along, while sub stayed lazy. The cache was accepted for the identical source, and rejected when one space was added. A cache is only good for exactly the code it came from.

Your turn

function findBodyEnd(src, i) {
  let depth = 0;
  for (; i < src.length; i++) {
    if (src[i] === '{') depth++;
    if (src[i] === '}') depth--;
    if (depth === 0) return i;
  }
  return -1;
}

function looksInvoked(src, i) {
  const c = src[i - 1];
  return c === '(' || c === '!';
}

What you learned

• Lazy parsing skims function bodies with a preparser and parses and compiles them fully only when they are first called.
• The preparser can’t just count braces, and must still check syntax and track the variables that closures capture.
• A called lazy function is parsed twice, so V8 parses likely-called functions (like (function) eagerly.
• A bytecode cache stores compiled code so the same script can skip compiling next time; any change to the source invalidates it.
• In Node, vm.Script and the module compile cache expose the same machinery.

Next: what V8 does with an object once it exists. Shapes.