Browser & BOM
JavaScript in the browser does not run in a vacuum — around it sit the global window object and a layer of browser APIs historically called the BOM (Browser Object Model). That is location, history, navigator, timers, storage, and workers — everything the ECMAScript language spec omits but the browser provides as a host.
The spine of the whole topic is the security model around the origin and the concurrency model around the single main thread. The same-origin policy decides what a page is allowed to read; the event loop and workers decide what runs and when without blocking rendering. Each layer below unpacks one of these mechanisms.
Topic map
- The BOM and the window object — what
windowis, how it differs fromdocument, and whatlocation,history,navigatorprovide. - Navigation and page lifecycle — moving through URLs, the History API for SPAs,
DOMContentLoaded/load,defer/async. - The same-origin policy — what an origin is, what the SOP forbids, and how CORS and
postMessagerelax it deliberately. - Timers and scheduling —
setTimeout/setInterval,setTimeout(fn, 0),requestAnimationFrame, debounce and throttle. - Web storage and cookies —
localStorage,sessionStorage, cookies and their attributes, differences in lifetime, size, and scope. - Web workers — a background thread with no DOM access, communicating via
postMessageand structured clone.
Common traps
| Mistake | Consequence |
|---|---|
Treating window and document as one object | document is a child of window (the DOM tree), not a synonym for the global object |
Assuming setTimeout(fn, 0) runs immediately | It queues fn as a macrotask after the current synchronous code, not right away |
Believing sub.site.com and site.com are one origin | An origin is the triple scheme + host + port; a different host is a different origin |
Not checking event.origin in a message handler | Any page can post to you — without the check it is an XSS channel |
Storing a token in localStorage and calling it safe | Any script on the page can read localStorage — XSS steals it; a session needs an HttpOnly cookie |
Expecting a Web Worker to see document | A worker has no DOM, window, or document — only message passing |
| Doing heavy computation on the main thread | It blocks rendering and events; heavy work belongs in a worker |
Interview relevance
The browser layer is asked to check whether you understand the platform beneath the language — the origin model (security) and the single-thread model (concurrency). A candidate who explains postMessage as a deliberate hole in the same-origin policy that requires an event.origin check immediately gets ahead of one who recites a method list.
Typical checks:
- The difference between
windowanddocument, and the purpose oflocation/history/navigator. - What an origin is made of and what exactly the same-origin policy forbids.
- What
setTimeout(fn, 0)really does and whyrequestAnimationFrameis better for animation. - How
localStorage/sessionStorage/cookies differ in lifetime, size, and being sent to the server. - Why a worker never touches the DOM and how message passing via structured clone works.
Common wrong answer: "setTimeout(fn, 0) runs the function right away". In fact it only queues it as a macrotask — it runs only after the current synchronous call stack empties (and when nested the browser clamps the delay to ~4 ms).