Meet the engines

Set the engine map for the stage

You already learned the beginner split in Engines, runtimes & hosts, then met Node, Deno, Bun, and edge runtimes in Runtimes. This expert stage looks inside the engine itself. It starts with the big picture so later lessons can zoom into scanners, parsers, bytecode, inline caches, garbage collection, and tiered compilation without redefining every moving part.

The previous lesson was Finding memory leaks. That lesson used tooling from the outside. This one names the inside. The next lesson, Scanning source text, follows the very first arrow: characters becoming tokens.

Most web developers meet three production engine families. V8 is built by the V8/Chromium project and runs in Chrome, Edge, Node.js, and Deno. SpiderMonkey is Mozilla's JavaScript engine in Firefox. JavaScriptCore is WebKit's engine in Safari and WebKit, and Bun uses JavaScriptCore for its runtime.

Tier names below are a snapshot verified against primary sources in September 2026. Treat them as a map, not a contract: engine teams rename tiers, replace backends, and move work between interpreter, baseline, and optimizing tiers.

Do not memorize every tier yet. The point for this first lesson is orientation: engines usually start with a lower-latency interpreter or baseline tier, collect feedback, then spend more compile time on hotter code. Later lessons unpack why each tier exists and why optimized code must still be able to bail out.

Hermes, QuickJS & embedded engines

The big three are not the whole ecosystem. Smaller engines make different trade-offs: startup over peak throughput, tiny memory over browser compatibility, Java embedding over DOM work, or research and conformance over market share. These engines are especially useful when JavaScript is embedded inside an app, a device, a test harness, or another language.

Engines differ internally, but they share a recognizable path: source text becomes scanner tokens, tokens become a parse tree or AST, functions may be lazily parsed, executable bytecode is produced, an interpreter starts running it, inline caches and type feedback record what actually happened, optimizing JITs compile hot paths, guards deoptimize back to lower tiers when assumptions fail, and the garbage collector runs alongside everything to reclaim unreachable objects.

1const sourceText = "2 + 3 * 4";Run2const tokens = ["num:2","+/-:+","num:3","*:*","num:4"];3const astRoot = "BinaryExpression";4const bytecode = ["PUSH 2","PUSH 3","PUSH 4","MUL","ADD"];5const result = 14;6console.log(result);

Line 2 is the scanner story. Line 3 is the parser story. Line 4 is a teaching bytecode, not V8's Ignition bytecode, SpiderMonkey bytecode, or JavaScriptCore bytecode. It is deliberately tiny so you can see the same shape before later lessons introduce real engine-specific details.

This playground runs in your browser. Acorn produces the token stream and an ESTree-compatible AST excerpt. A small compiler in this lesson accepts only arithmetic expressions and emits stack bytecode. The bytecode is a model you can step through; it is not copied from any production engine.

1const sourceText = "2 + 3 * 4";2const tokens = ["num:2","+/-:+","num:3","*:*","num:4"];3const astRoot = "BinaryExpression";4const bytecode = ["PUSH 2","PUSH 3","PUSH 4","MUL","ADD"];5const result = 14;6console.log(result);

{
  "type": "BinaryExpression",
  "start": 0,
  "end": 9,
  "operator": "+",
  "left": {
    "type": "Literal",
    "start": 0,
    "end": 1,
    "value": 2,
    "raw": "2"
  },
  "right": {
    "type": "BinaryExpression",
    "start": 4,
    "end": 9,
    "operator": "*",
    "left": {
      "type": "Literal",
      "start": 4,
      "end": 5,
      "value": 3,
      "raw": "3"
    },
    "right": {
      "type": "Literal",
      "start": 8,
      "end": 9,
      "value": 4,
      "raw": "4"
    }
  }
}

Try (7 - 1) / 3 and 5 * (2 + 6). Notice that parentheses and precedence change the AST shape before bytecode is emitted. That is why the scanner and parser lessons come before bytecode and JIT lessons in this stage.

Interpreters are good at getting code running quickly. JIT compilers spend CPU time to generate machine code for hot code. Optimizing JITs rely on speculation: if calls have seen numbers, object shapes, and stable property accesses, optimized code can guard those assumptions and run faster. If a later call breaks an assumption, the engine deoptimizes to a lower tier that can handle the general case correctly.

1function add(a, b) {Run2  return a + b;3}4 5const feedback = [];6feedback.push(typeof 1 + "+" + typeof 2);7const first = add(1, 2);8const optimizedFor = feedback[0];9const later = add("3", 4);10const outcome = typeof later === "number"11  ? "stay in optimized code"12  : "deopt to a lower tier";13console.log(first);14console.log(outcome);

Garbage collection is not a final stage after execution. It is a partner beside the pipeline. Values, objects, functions, closures, bytecode, feedback vectors, optimized code, and host references all affect memory pressure. That is why memory lessons and engine lessons meet again when you read heap snapshots or investigate leaks.

ECMA-262 defines the language: syntax, values, objects, execution semantics, and built-ins such as Promise and Array.prototype.map. Hosts define how JavaScript meets the outside world: HTML defines the browser event loop, timers, the DOM integration, and module loading behavior; Node defines process, file modules, package resolution, and its runtime policies. Embedders call engine APIs to create isolates, contexts, native bindings, snapshots, and globals.

The short probe below uses only standardized globals, so it runs in the browser editor and in Node. It is intentionally not a DOM or Node-only example.

1console.log(typeof Array.prototype.map);2console.log(typeof globalThis);3console.log(typeof Promise);

An embedder sketch looks different because it is not ordinary page JavaScript. It is the surrounding application creating an engine instance, a context, and host objects before evaluating user code.

1// Pseudocode: embedders call engine APIs from C++/Rust/Java.2const isolate = createIsolate();3const context = isolate.createContext({ console });4context.evaluate("console.log(1 + 2)");

Engine tools are powerful and version-specific. d8 is V8's developer shell. jsvu installs recent engine binaries without compiling them yourself. eshost-cli runs the same snippet across registered engines. node --v8-options lists V8 flags exposed by your Node build. Test262 is the conformance suite engine implementers use to check ECMAScript behavior.

1$ node --version2v22.23.13$ node -p "process.versions.v8"412.4.254.21-node.565$ node --v8-options | grep -- --print-bytecode6  --print-bytecode (print bytecode generated by ignition interpreter)

To find Chrome's V8 version, open chrome://version in that browser and read the JavaScript/V8 entry. Do not assume Chrome, Node, Deno, and an installed d8 shell all ship the same V8 revision.

1# V8's developer shell after building V8 or installing a binary with jsvu2v8 --print-bytecode demo.js3 4# Install current engine shells without compiling them yourself5npx jsvu --engines=v8,spidermonkey,javascriptcore,quickjs,hermes,xs6 7# Register shells and compare behavior across engines8npx eshost-cli --configure-jsvu9eshost -e 'print(1 + 2)'10 11# Run the official ECMAScript conformance suite when building an engine12npm test -- path/to/test262

The commands are non-runnable in the lesson page because the browser editor is not your shell and most engine binaries are not installed here. The tests do run real Node commands and prove that this Node build reports V8 12.4 and exposes --print-bytecode.

Where engine knowledge helps

You rarely need to write code for a specific JIT tier, but this model helps in production work. It tells you where to look when startup is slow, why syntax errors appear before code runs, why a memory leak can keep closures and DOM nodes alive, why one odd call shape can spoil a hot path, and why a browser-only API fails in a server runtime.

• When a page starts slowly, ask how much source must be downloaded, scanned, parsed, compiled, and executed before interaction.
• When a profile shows a hot function, measure before changing code and look for algorithmic or allocation wins first.
• When a heap snapshot shows retained objects, connect those references to closures, host objects, and GC roots.
• When code crosses browser, Node, Deno, Bun, or embedded contexts, separate language semantics from host APIs.

Keep Runtime overview, Manuals & specs, and The event loop nearby. They explain the host side that engine internals deliberately do not own.

Common misconceptions

• “V8 is the JavaScript standard.” V8 is one implementation. ECMA-262 is the language specification.
• “A JIT always makes code faster.” JITs trade compile time and memory for speed on hot paths. Cold code may stay interpreted or baseline-compiled.
• “Bytecode means the same thing in every engine.” Engines use different bytecode formats and tiers. This lesson's bytecode is only a teaching model.
• “The engine owns timers and the DOM.” Hosts wire scheduling, rendering, files, networking, and global objects around the engine.
• “Garbage collection fixes leaks automatically.” GC reclaims unreachable objects. If your code or host objects still reference data, it remains reachable.
• “Engine flags are portable production APIs.” Flags are implementation tools and can change, disappear, or behave differently across versions.

Answer with the pipeline and layer boundaries in mind. Code answers are real JavaScript outputs, not guesses.

Key takeaways and what comes next

• V8, SpiderMonkey, and JavaScriptCore are the big browser engine families; Hermes, QuickJS, Boa, LibJS, JerryScript, XS, and GraalJS serve other embedding needs.
• The shared path is source text to tokens, parser/AST, bytecode, interpreter, feedback, JIT tiers, possible deoptimization, and GC alongside the whole process.
• ECMA-262 defines language semantics; hosts define DOM, timers, files, modules, event loops, and globals; embedders create engine contexts and native bindings.
• Use d8, jsvu, eshost-cli, Node's V8 flags, and Test262 as investigation tools, not as portable production dependencies.
• Engine knowledge is practical when debugging startup, memory, and performance, but measurements matter more than folklore.

Further reading from primary sources

• V8 Ignition docs, Sparkplug, Maglev, and TurboFan.
• Mozilla SpiderMonkey source docs for parser, bytecode, Baseline, Warp, bailout, and GC overviews.
• WebKit's FTL JIT overview and JavaScriptCore speculation post.
• React Native Hermes docs, QuickJS, QuickJS-ng, JerryScript, and Moddable XS.
• V8 d8 docs, jsvu, eshost-cli, and Test262.

Up next: Scanning source text, where the first character stream becomes tokens.