The browser environment

Welcome to the browser host

You already know a lot of JavaScript: values, functions, objects, scope, classes, errors, and asynchronous code. Stage 7 opens a new door. The same language now runs inside a host: the browser. The host gives JavaScript objects that are not part of the language itself, but make web pages possible.

Think of this lesson as the map taped beside the browser console. It answers: what is window, why does document exist, what does people mean by “BOM”, which specs define these things, and why a page script, module script, worker, and Node program do not all have the same globals.

We will link back to Engines, runtimes & hosts and Manuals & specifications instead of repeating them. Today is about the browser-specific surface you are about to use in every DOM lesson.

In a normal page script, the browser exposes a huge object named window. It is both the window-like browser environment and the global object for classic scripts. That is why code can write alert("Hi") instead of window.alert("Hi"): global property lookup finds the property on window.

But there is a sharp edge from the old var lesson: top-level var and top-level function declarations in a classic script create properties on the global object. Top-level let, const, and class create global lexical bindings, but not window properties. The names are still visible to other classic scripts because they share a global lexical scope; they just are not object properties.

1var fruit = "mango";Run2function greet() {3  return "hello from a classic script";4}5console.log("fruit" in globalThis);6console.log(globalThis.fruit);7console.log(typeof greet);

Now let a real sandboxed frame answer the same question. The code is predefined; the parent validates event.source before trusting the message. Toggle to a module script and notice that module top-level declarations are module-scoped: even var fruit no longer creates window.fruit.

1<div id="banner">Named access demo</div>2<script>3var fruit = "mango";4let veggie = "carrot";5function greet() { return "hi"; }6parent.postMessage({7  source: "global-explorer",8  mode: "classic",9  rows: [10    ["'fruit' in window", String("fruit" in window)],11    ["window.veggie", String(window.veggie)],12    ["typeof window.greet", typeof window.greet],13    ["globalThis === window", String(globalThis === window)],14    ["window.window === window", String(window.window === window)],15    ["self === window", String(self === window)],16    ["window.banner exists", String(Boolean(window.banner))]17  ]18}, "*");19</script>

Modern code should use globalThis when it truly needs “the global object, wherever I am.” In a page script, globalThis === window is true; precisely, browsers expose a WindowProxy that forwards to the current window. In a worker, globalThis is the worker global scope and is also available as self. In Node, it is Node’s global object.

The DOM (Document Object Model) is the standard API for representing documents as nodes and letting scripts read or change them. The next lesson, “The DOM tree,” zooms in on that structure. BOM, short for Browser Object Model, is an informal nickname for browser objects that are not the document tree itself: location, history, navigator, screen, dialogs, and more. Most of what people call BOM is specified in the HTML Standard, not in one official “BOM spec.”

1const snapshot = {2  pathname: location.pathname,3  language: navigator.language,4  online: navigator.onLine,5  viewport: innerWidth + " × " + innerHeight,6  screenWidth: screen.width,7  devicePixelRatio,8  historyLength: history.length,9  title: document.title,10  readyState: document.readyState11};

Browser APIs feel like one big object pile, but they come from several standards that coordinate with each other. This matters because it explains why Array.prototype.map works in Node but document.querySelector does not, and why fetch can appear in more than one host without becoming an ECMAScript feature.

You do not need to memorize spec names to write a button click handler. You do need the habit: when a name is missing, ask “is this language JavaScript, a browser API, a worker API, or a Node API?” That question saves hours of confusion.

“JavaScript runs in the browser” is true but incomplete. A classic page script runs with window and document. A module script also runs in the page and can use browser APIs, but its top-level declarations stay inside the module. A Web Worker runs off the main page thread with self and no document. Node runs outside the browser with process and global, not window.

1self.postMessage({2  windowType: typeof window,3  documentType: typeof document,4  selfType: typeof self,5  importScriptsType: typeof importScripts,6  globalThisType: typeof globalThis7});

Where you will use this

Browser-environment thinking shows up whenever code reaches outside the ECMAScript core. The following snippet is ordinary front-end code: it finds an element through the DOM, reads the URL from the browser environment, asks navigator about connectivity, and listens for browser events.

1const status = document.querySelector("#status");2 3function describePage() {4  const path = location.pathname;5  const online = navigator.onLine ? "online" : "offline";6  status.textContent = `You are on ${path} and currently ${online}.`;7}8 9window.addEventListener("online", describePage);10window.addEventListener("offline", describePage);11describePage();

This is why separating “language” from “host” is practical, not trivia. If this snippet fails in a Node test, document is the first suspect. If status is null, the page element is missing or the script ran before it existed. If navigator.onLine seems too optimistic, remember it is a browser hint, not a guarantee that your server is reachable.

• “Everything global is on window.” Top-level let, const, and class are global lexical bindings in classic scripts, not window properties.
• “Modules cannot use browser APIs.” Browser modules can use document, location, and friends. Their own top-level declarations are module-scoped.
• “BOM is an official twin of DOM.” BOM is informal. The real standards are mostly HTML plus related web platform specs.
• “fetch and setTimeout are ECMAScript.” They are host APIs. ECMAScript defines promises; hosts define many operations that create or schedule them.
• “Workers are mini pages.” Workers run JavaScript, but they have no document and cannot directly rearrange page nodes.
• “Named element access is convenient, so I should use it.” It is legacy and collision-prone. Query the document explicitly.

Key takeaways

• ECMAScript is the language core; the browser host adds web APIs around it.
• In page scripts, window is the browser global object and globalThis === window is true.
• Classic top-level var and function declarations create window properties; let, const, class, and module top-level declarations do not.
• The DOM is the document tree API. BOM is an informal nickname for browser environment objects mostly specified by HTML.
• Workers and Node share JavaScript but not the same globals as a page.

Final definition: the browser environment is JavaScript plus the standards-based objects a browser supplies so code can observe and change a web page.

Up next: The DOM tree.