Lazy parsing and the pre-parser

Two parsers, not one

The previous lesson described “the parser” as a single thing. In reality V8 ships two parsers that share a scanner. Knowing which one runs — and when — is what lets you reason about startup cost rather than just guessing:

• The full parser. Builds a complete AST, resolves variable scopes, allocates scope objects — everything the bytecode generator needs. This is the expensive one.
• The PreParser. A deliberately incomplete parser that skims a function body fast. It does not build an AST and does not allocate scopes. Its job is narrow: find where the function ends (so the engine knows the byte range to come back to), and detect early errors — syntax errors and a handful of SyntaxError-class problems (a return outside a function, a duplicate parameter in strict mode) that the spec requires reported even for code that never runs.

On a cold load, V8 does not fully parse most function bodies. It pre-parses them: skim, record the source span and a little metadata, move on. The full parse of a given function is deferred until the moment the function is first called. This is lazy parsing, and it is the single biggest startup win in the front-end pipeline, because most functions in a typical bundle are never called on the cold path.

The trap: a called function is parsed twice

Lazy parsing is a bet. The bet pays off for functions that are never called: you spent one cheap skim instead of one expensive full parse. But for a function that is called, you lose the bet — you pay the pre-parse skim and then the full parse. That is the double-parse problem: a lazily-parsed function that later runs costs roughly 2× the parse work of a function that had been parsed eagerly once.

For most code this is the right trade: the savings on the never-called majority outweigh the double cost on the called minority. But on the hot startup path — the functions that you know run immediately, like your framework’s bootstrap or a module’s top-level initialiser — paying for two parses is pure waste. You would rather V8 just parse those eagerly, once.

The eager-parse heuristic: parentheses mean “run me now”

V8 has a heuristic to opt a function out of lazy parsing: if a function expression is wrapped in parentheses, V8 parses it eagerly, because the parentheses are the classic signal of an Immediately Invoked Function Expression (IIFE) — a function the author intends to call right away.

// Eagerly parsed: the parens signal "this runs immediately".
(function () {
  bootstrapTheApp();
})();

// Lazily parsed by default: looks like a definition to call later.
function maybeLater() {
  doExpensiveThing();
}

A function written to look like an IIFE — even with the parens but invoked separately — is called a PIFE (Possibly-Invoked Function Expression), and V8 treats the leading ( as the eager-parse hint. This is exactly the trick the old optimize-js tool exploited: it mechanically wrapped module-bootstrap functions in parentheses so V8 would parse them eagerly and skip the double-parse on the startup path. Modern bundlers (webpack, Rollup) emit IIFE/PIFE wrappers around module factories for the same reason — it is a real, measurable startup optimisation, not folklore.

Inner functions ride along with their outer function

There is a structural subtlety: when V8 fully parses an outer function, it pre-parses the inner functions nested inside it — it does not fully parse them too. So a deeply nested helper is pre-parsed when its enclosing function is fully parsed, and only fully parsed when that inner helper is itself first called. The laziness is recursive: each level defers the next. This is why a giant module-scope function with many nested closures can still start cheaply — the nesting is skimmed, not fully built, until each piece runs.