Meet the engines

What a JavaScript engine does

You met engines and hosts in Engines, runtimes & hosts. Then you met Node, Deno, Bun, and edge runtimes in Runtimes. This lesson starts a new stage, called Inside the engine. The stage looks at what happens inside the engine itself. This first lesson gives you the big picture. Later lessons look at each part up close.

The last lesson was Finding memory leaks. There you used tools that look at a program from the outside. This lesson names the parts on the inside. The next lesson, Scanning source text, covers the very first step: turning characters into tokens.

Most web developers meet three big engines:

• V8 is built by Google's V8 project. It runs in Chrome, Edge, Node.js, and Deno.
• SpiderMonkey is built by Mozilla. It runs in Firefox.
• JavaScriptCore is the engine of WebKit, the browser engine behind Safari. Bun uses it too.

Each engine runs code in tiers. A tier is one way of running code. A low tier starts quickly but runs slowly. A high tier takes longer to prepare but runs fast. The tier names in the table below were checked against each engine's own docs in September 2026. Engine teams rename and replace tiers often, so use the names as a rough map.

1const prices = [4, 6];2const total = prices.reduce((sum, price) => sum + price, 0);3console.log(total);

Line 1 makes an array of two prices, 4 and 6. Line 2 adds them up with reduce. The reduce method walks through the array and keeps a running total, starting at 0. Line 3 prints 10. Every engine must give this same result. Inside, each engine may use different instructions to get there. That is allowed, as long as the result your code sees is the same.

Read each row from left to right: the engine, who builds it, where you meet it, and how it runs code.

You don't need to remember the tiers. Keep this pattern instead. An engine first runs code in a tier that starts quickly. While the code runs, the engine takes notes about the values it sees. When some code runs many times, the engine spends extra time to make it faster. Later lessons explain each tier. They also explain why fast code must be able to fall back to a slower tier.

Hermes, QuickJS & embedded engines

The big three are not the only engines. Smaller engines make different choices. Some start up faster. Some use very little memory. Some fit inside a Java program. Some exist to test the language rules. They are useful when JavaScript runs inside something else: a phone app, a small device, a test tool, or a program written in another language.

Each row names an engine, where it usually runs, and what it is good at.

1const status = { ready: true };2console.log(JSON.stringify(status));

Line 1 makes a plain object. Line 2 uses JSON.stringify, which turns the object into text, and prints {"ready":true}. JSON is part of the language. So every engine provides it, even with no web page around. The same goes for objects, arrays, and promises. Picking a different engine changes speed, memory use, and tools. It must not change the language rules.

Engines differ inside, but they follow similar steps. Together the steps form a pipeline: the output of one step is the input of the next.

1. The scanner reads the source text and splits it into tokens.
2. The parser checks the grammar and builds a tree called an AST (abstract syntax tree). It may skip the inside of a function until that function is needed. This is called lazy parsing.
3. The engine turns the tree into bytecode: simple instructions made for the engine, not for the computer's chip.
4. An interpreter runs the bytecode, one instruction at a time.
5. While the code runs, the engine keeps feedback: notes about the types and objects it sees.
6. A JIT compiler ("just in time") turns code that runs often into fast machine code. It uses the feedback to guess what the code will see next.
7. If a guess turns out wrong, the engine drops the fast code and goes back to a slower tier. This is called deoptimization, or "deopt" for short.

Beside all these steps, the garbage collector frees memory that your program can no longer reach.

1function formatReceipt(total) {2  return "Total: " + total;3}4console.log("shop ready");

Line 1 declares formatReceipt, but nothing calls it. Line 4 prints shop ready, and that is the only output. A function that never runs is called cold. The engine must still check the whole file for grammar mistakes. But it may wait to fully parse or compile a cold function until something calls it. Each engine picks its own way to do this, and your code can't tell the difference.

1console.log("before");2const price = ;3console.log("after");

Line 2 has nothing after =. That breaks the grammar, so the parser throws a SyntaxError before any line runs. So neither before nor after is printed. A runtime error is different. It happens while the code runs, so the lines before it have already run.

The walkthrough below runs these steps on a small sum, 2 + 3 * 4.

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 holds the tokens from the scanner. Line 3 holds the type of the node at the top of the tree, from the parser. Line 4 holds teaching bytecode. It is made up for this lesson. It is not the bytecode of V8 (called Ignition), SpiderMonkey, or JavaScriptCore. It is tiny on purpose, so you can see the idea before later lessons show real engine bytecode.

This playground runs in your browser. It uses Acorn, a JavaScript parser written in JavaScript. Acorn gives the real tokens and a real tree. The tree follows ESTree, a shared format for JavaScript trees that many tools use. Then a small compiler from this lesson turns the tree into bytecode. It only accepts arithmetic, such as 2 + 3 * 4. That bytecode is a teaching model you can step through. It is not copied from any real 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), and watch the tree change shape. Brackets and the order of operations (* before +) decide the shape of the tree before any bytecode is made. That is why the scanner and parser lessons come before the bytecode and JIT lessons in this stage.

An interpreter starts running code quickly, but it runs slowly. A JIT compiler needs time to build machine code, but that code runs fast. So engines only use the JIT for hot code: code that runs many times.

The JIT makes a guess from the feedback. For example: "this function has only seen numbers, so it will keep getting numbers." The fast code checks the guess each time it runs. This check is called a guard. If a later call breaks the guess, the guard fails. The engine then deoptimizes: it drops the fast code and goes back to a slower tier that handles every case correctly.

1function userLabel(user) {2  return user.name + ": " + user.score;3}4console.log(userLabel({ name: "Asha", score: 3 }));5console.log(userLabel({ name: "Mina", score: 4 }));

Lines 4 and 5 call userLabel with two objects. Both objects have the same keys, name and score, made in the same order. An object's shape is its list of keys in that order. Line 4 prints Asha: 3, and line 5 prints Mina: 4. Seeing the same shape again and again gives the engine useful feedback, so it may make this function faster. That is not a promise. Don't make your data harder to read just to keep shapes the same.

The walkthrough below is a small model of feedback and deopt. A warm-up call teaches the engine to expect numbers. Then a later call either sends numbers again or sends a string.

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 last step after the code finishes. It runs beside the pipeline the whole time. Many things use memory: your values, objects, functions, and closures (functions that remember the variables around them). The engine's own bytecode, feedback, and fast code use memory too, and so do objects from the host. That is why memory lessons and engine lessons meet again when you read heap snapshots or look for leaks.

Three parts work together when JavaScript runs:

• The language. ECMA-262 defines the grammar, the values, the objects, how code runs, and built-in tools such as Promise and Array.prototype.map. Engines build all of this.
• The host. It connects JavaScript to the outside world. In a browser, the HTML standard defines the event loop, timers, the page (called the DOM), and how modules load. Node defines process, file modules, how packages are found, and its own rules.
• The embedder. This is the program that starts the engine, usually written in C++, Rust, or Java. It calls the engine's own functions to make an isolate (one copy of the engine with its own memory) and a context (one global world for code to run in). It also picks which outside objects JavaScript can use.

In a browser or in Node, one program is both the host and the embedder. The two words name two jobs: adding the extras, and setting up the engine.

Each row lists some names, who provides them, and how to think about them.

The short check below uses only names from the language. So it runs both in the browser editor and in Node. It uses nothing from the page and nothing that only Node has.

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

typeof gives the kind of a value, as text. Each line asks for the kind of one built-in name: Array.prototype.map, globalThis (the global object), and Promise.

1const hasPageApis = typeof document !== "undefined";2console.log(hasPageApis ? "page APIs available" : "no page APIs");

Line 1 uses typeof to check whether this host has a document. A plain read of a missing name throws an error, but typeof does not. In the lesson editor, line 2 prints page APIs available. In plain Node, it prints no page APIs. Checking for the feature itself is safer than checking the engine's name. V8 runs in both Chrome and Node, so the engine name can't tell you if there is a page.

Embedder code looks different, because it is not normal page code. It is the program around the engine. It makes a copy of the engine and a context, adds outside objects, and only then runs the user's 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)");

Line 1 is a comment: real embedder code is written in C++, Rust, or Java. Line 2 makes an isolate. Line 3 makes a context and hands it console. Line 4 runs one line of JavaScript inside that context.

Engine tools are useful, but each one depends on the version you have installed. Here is what each tool does:

• d8 is V8's own shell: a small program that runs JavaScript on V8, with no browser around it.
• jsvu downloads recent engine shells, so you don't have to build them yourself.
• eshost-cli runs the same code in several engines, so you can compare the results.
• node --v8-options lists the V8 settings, called flags, that your Node build lets you turn on.
• Test262 is the official test suite for the language. Engine teams run it to check that they follow ECMA-262.

1$ node --version2$ node -p "process.versions.v8"3$ node --v8-options | grep -- --print-bytecode

Line 1 prints the Node version. Line 2 prints the version of V8 inside this Node. Line 3 lists all V8 flags, and grep keeps only the line for --print-bytecode. That flag makes V8 print the bytecode it builds.

To find the V8 version in Chrome, open chrome://version in Chrome and read the JavaScript line. Chrome, Node, Deno, and a d8 shell can each have a different V8 version, so don't assume they match.

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

You can't run these commands on this page. The editor here is not a terminal, and most engine shells are not installed. The lesson's tests do run the Node commands above. They check that Node 22 has V8 12.4 inside and offers --print-bytecode. The last part of a version number changes from one install to the next, so use the values your own computer prints.

Where engine knowledge helps

You rarely need to write code for one tier. But knowing the steps tells you where to look when something is slow or broken. Start with the simplest win: a good way to store your data.

1const pricesByItem = new Map([["tea", 3], ["cake", 5]]);2console.log(pricesByItem.get("tea"));

Line 1 makes a Map: a list of keys, each with a value. Here each key is an item name and each value is a price. Line 2 asks for the price of tea directly and prints 3. As the list of items grows, a good data structure like this usually helps more than changing small bits of code to please one JIT. Measure the real program, including loading, parsing, network, drawing the page, and memory use.

Here is where engine knowledge helps in real work:

• A page starts slowly. Ask how much code must be downloaded, scanned, parsed, compiled, and run before the user can click.
• A profile shows one slow function. Measure first. Then look for a better algorithm, or for fewer new objects.
• A heap snapshot shows objects that should be gone. Follow the links from closures and host objects back to the roots. The roots are the starting points the garbage collector always keeps, such as global variables.
• Code moves between the browser, Node, Deno, Bun, or a small device. Separate the language rules from the host's extras.

Keep Runtime overview, Manuals & specs, and The event loop close. They explain the host side, which the engine does not own.

Common misconceptions

• “V8 is the JavaScript standard.” V8 is one engine that follows the standard. The standard is ECMA-262.
• “A JIT always makes code faster.” Building fast code takes time and memory. Code that runs only a few times may never leave the first tiers.
• “Bytecode is the same in every engine.” Each engine has its own bytecode and its own tiers. This lesson's bytecode is only a teaching model.
• “The engine owns timers and the page.” The host adds timers, page drawing, files, network, and most global objects around the engine.
• “Garbage collection fixes leaks by itself.” The garbage collector only frees objects that nothing can reach. If your code or a host object still points to some data, that data stays.
• “Engine flags are safe to use in real apps.” Flags are tools for studying engines. They can change, disappear, or act differently in the next version.

These four words are easy to mix up. Each row says what the word means and what it does not mean.

Think about the pipeline steps and about who provides each feature. Code answers are real JavaScript output.

Key takeaways and what comes next

• V8, SpiderMonkey, and JavaScriptCore are the big browser engines. Hermes, QuickJS, Boa, LibJS, JerryScript, XS, and GraalJS serve other needs, such as phone apps and small devices.
• The shared steps are: source text, tokens, tree (AST), bytecode, interpreter, feedback, JIT tiers, and sometimes deopt. The garbage collector runs beside all of them.
• ECMA-262 defines the language. Hosts add the page, timers, files, modules, the event loop, and globals. Embedders start the engine and hand it outside objects.
• d8, jsvu, eshost-cli, Node's V8 flags, and Test262 are tools for studying and testing engines. Don't depend on them in a real app.
• Engine knowledge helps you find slow start-up, memory, and speed problems. Measuring still matters more than tips you heard somewhere.

In one line: the engine runs the language, the host adds the world around it, and measuring beats guessing.

The next lessons in this stage, and what each one explains:

Further reading from the engine teams

• V8 Ignition docs, Sparkplug, Maglev, and TurboFan.
• Mozilla SpiderMonkey source docs, with overviews of the parser, bytecode, tiers, bailouts, and the garbage collector.
• WebKit's FTL JIT overview and the JavaScriptCore post on guessing (speculation).
• 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 stream of characters becomes tokens.