Engines, runtimes & hosts

One program, three layers around it

JavaScript can feel mysterious because people use the same word for several things. They say “JavaScript runs in Chrome,” “JavaScript runs in Node,” and “JavaScript has document.querySelector.” Those sentences point at different layers.

The engine is the part that understands the JavaScript language: variables, functions, arrays, objects, JSON.parse, Promise, and the rules from the ECMAScript standard. The host is the larger program around that engine: a browser tab, Node.js, Deno, Bun, or another environment. The host gives your code extra powers such as a page to change, files to read, timers to schedule, or a console to print to.

This lesson connects the history you just learned to the practical setup coming next. You will not install anything here; the next lesson, Setting up your tools, handles that. Today, your browser itself is enough.

An engine is an implementation of the JavaScript language. It reads your source code, checks that the syntax makes sense, creates values and functions, runs statements, and returns results. Different browser makers build different engines, but they aim at the same ECMAScript standard from the previous lesson.

Engine names matter when you read release notes, debug compatibility, or hear that a runtime is “built on V8.” They do not mean you must write three different versions of ordinary JavaScript. For beginner code, the language features are shared far more often than they differ.

A browser host gives JavaScript a page and browser features: window, document, localStorage, alert, and many web APIs. A server runtime host gives JavaScript server features: command-line arguments, file access, environment variables, and tools for running programs outside a page.

The clearest proof is to ask the host what globals exist. Run this experiment in your real browser. Notice especially that window and document exist here, while process normally belongs to Node.js. globalThis is the standard name that works across modern hosts.

1const info = {2  window: typeof window,3  document: typeof document,4  process: typeof process,5  globalThis: typeof globalThis,6  userAgent: navigator.userAgent,7};8console.table(info);

The engine guess uses navigator.userAgent, a string the browser reports about itself. It is useful for a friendly clue, not a courtroom witness: user agents can be shortened, frozen, or spoofed. The reliable lesson is not “trust this exact string”; it is “the same language runs inside different hosts.”

When code “works in JavaScript,” ask a sharper question: is this part of the language, or did a host provide it? Language features travel with JavaScript itself. Host APIs depend on where the code runs.

This distinction prevents a common beginner frustration. Array.prototype.map works in Node and in a browser because arrays are language values. document.querySelector works in a browser because the browser gives you a document. Try the same line in plain Node.js and there is no page to query.

1const host = "browser";Run2function describeHost(place) {3  const kitchen = place + " host";4  return "JavaScript running in a " + kitchen;5}6const summary = describeHost(host);7console.log(summary);

JavaScript code in a browser tab normally runs on one main thread: one path of execution that does one thing at a time. The host can have other helper threads behind the scenes, but your ordinary script statements do not all run at once. A function call pauses the surrounding script, runs the function, then returns.

Try the demo. The counter is driven by the host asking the page to repaint. The blocking button runs a tight loop for about 1.5 seconds. During that loop, the counter and clicks freeze. The chunked button does about the same total busy work in small slices with setTimeout, so the host gets chances to repaint between slices.

1let frame = 0;2function tick() {3  frame = frame + 1;4  requestAnimationFrame(tick);5}6 7function blockFor(milliseconds) {8  const end = performance.now() + milliseconds;9  while (performance.now() < end) {10    // Busy work keeps the main thread occupied.11  }12}13 14function chunkedWork(milliseconds) {15  const end = performance.now() + milliseconds;16  function slice() {17    const sliceEnd = Math.min(performance.now() + 25, end);18    while (performance.now() < sliceEnd) {}19    if (performance.now() < end) setTimeout(slice, 0);20  }21  slice();22}

This is not the full event loop lesson. Later, The event loop will explain tasks, callbacks, and scheduling in depth. For now, remember the beginner rule: while your synchronous JavaScript is running, the main thread cannot do something else for your page.

Where you’ll use this

This mental model turns confusing errors into useful clues. If the console says document is not defined, you probably ran browser code in a server host. If it says process is not defined, you probably ran Node-specific code in a browser. If an older browser does not understand a new method, you are dealing with language or API compatibility rather than a typo.

• When reading MDN, check whether a page describes a JavaScript language feature or a Web API.
• When choosing a package, check whether it expects Node APIs, browser APIs, or both.
• When a page feels frozen, look for long synchronous work on the main thread.
• When comparing Node.js, Deno, and Bun, ask both “which engine?” and “which host APIs?”

Common misconceptions

Check the model. Every answer explains why it is right or wrong.

Key takeaways

• V8, SpiderMonkey, and JavaScriptCore are engines: software that runs the JavaScript language.
• Browsers, Node.js, Deno, and Bun are hosts or runtimes: they embed an engine and add APIs.
• Language features such as arrays, JSON, Math, and Promise are different from host APIs such as document, process, timers, and storage.
• Ordinary JavaScript on a page runs one main-thread task at a time. Long synchronous work freezes the interface.
• When code fails, ask whether you used the wrong host, an unsupported feature, or a blocking chunk of work.

Up next: Setting up your tools.