Inside a dedicated Web Worker in the browser, why can you not touch the page's DOM, and which browser APIs are still available on the worker's global scope?

## What a dedicated worker is `new Worker('/parse.js')` asks the browser to fetch a script and run it on a separate thread with a separate JavaScript realm. "Dedicated" means exactly one page owns it: the worker is reachable only from the document that created it, and it is destroyed when that document goes away. It is not a sandboxed copy of your page — it is a different global environment that happens to share the page's origin. That second realm has its own global object. In a document the global is a `Window`; in a dedicated worker it is a `DedicatedWorkerGlobalScope`. You reach it as `self` (and as `globalThis`), never as `window`. ```js // worker.js console.log(typeof window); // "undefined" console.log(typeof document); // "undefined" console.log(self === globalThis); // true ``` ## Why the DOM is missing The DOM is a mutable tree with a huge amount of derived state hanging off it: computed styles, layout boxes, the accessibility tree, selection, focus. Every one of those is maintained on the assumption that only one thread is reading and writing at a time. If a worker could call `element.remove()` while the main thread was mid-layout, the browser would need locks — or at least fine-grained synchronization — around essentially every DOM operation, which would slow down the common single-threaded case for everyone. The platform chose the other side of that trade: workers are *shared-nothing* by default. They do not see the page's objects at all; the two sides exchange copies of data as messages. Because nothing is shared, no locking is needed, and a worker can never corrupt the page's tree or leave it half-updated. The practical rule is: **a worker computes, the page renders.** ## What is actually available A worker global is far from empty. Typically present in a dedicated worker: - Networking: `fetch`, `XMLHttpRequest`, `WebSocket`, `EventSource` - Storage: `indexedDB`, `caches` - Timers and scheduling: `setTimeout`, `setInterval`, `queueMicrotask` - Crypto and encoding: `crypto` (including `crypto.subtle`), `TextEncoder`, `TextDecoder`, `atob`, `btoa` - Measurement and logging: `performance`, `console` - Environment: `navigator` (a `WorkerNavigator`, with members such as `navigator.userAgent` and `navigator.hardwareConcurrency`), `location` (a `WorkerLocation`) - Graphics without a DOM: `OffscreenCanvas`, `createImageBitmap` - Module loading: `importScripts` in a classic worker; static and dynamic `import` in a module worker Notably absent, besides the DOM itself: `alert`/`confirm`/`prompt`, `localStorage` and `sessionStorage` (synchronous storage is a `Window`-only API), and `document.cookie`. If a worker needs persistent storage it uses `indexedDB` or `caches`, both of which are asynchronous and worker-safe. ## Consequences for how you structure code The "no DOM" rule shapes what a worker is good for. Good candidates are self-contained transformations: parsing or diffing a large payload, running a search index, compressing an upload, decoding a binary format, image processing on an `OffscreenCanvas`. Bad candidates are anything whose real cost is DOM work — building thousands of elements, measuring layout, or animating — because that must happen on the main thread anyway. It also constrains libraries. A dependency that reaches for `window` or `document` at module-evaluation time will throw the moment you import it into a worker, even if the code path you wanted never touches the DOM. Feature-detect rather than assume: ```js const inWorker = typeof importScripts === 'function' || (typeof WorkerGlobalScope !== 'undefined' && self instanceof WorkerGlobalScope); ``` ## Debugging Workers get their own execution context in browser devtools — a separate entry in the sources/thread list, with its own console output and its own breakpoints. If your `console.log` calls seem to vanish, you are almost certainly looking at the page's context instead of the worker's. Uncaught errors inside the worker also surface on the page as an `error` event on the `Worker` object, which is worth wiring up: ```js const worker = new Worker('/parse.js'); worker.addEventListener('error', (event) => { console.error('worker failed:', event.message, event.filename, event.lineno); }); ``` One more constraint that trips people up: the worker script URL must be same-origin with the page. You cannot point `new Worker()` straight at a third-party CDN; the usual workaround is to fetch the source yourself and construct the worker from a `blob:` URL you create.