Node now provides globals that were once browser-only, such as `fetch`, `AbortController`, `URL` and `structuredClone`. How should shared JavaScript code decide what it is allowed to call?

## Why the old sniffing habits stopped working For years the shorthand worked well enough: `typeof window !== 'undefined'` meant browser, `typeof process !== 'undefined'` meant Node, and the presence of `fetch` was a browser fingerprint. Every one of those has since become unreliable. Node has steadily adopted web-standard globals: `URL` and `URLSearchParams`, `TextEncoder`/`TextDecoder`, `AbortController` and `AbortSignal`, `structuredClone` (Node 17), a global `fetch` with `Request`/`Response`/`Headers` (Node 18, stable in 21), `queueMicrotask`, `performance`. Code that treated any of those as a browser marker now mis-detects. The converse holds too: - A browser **worker** context has no `window` — but it is unambiguously a browser, with `fetch`, `URL` and `structuredClone` all present. - A jsdom-style **test environment** installs `window` and `document` inside a Node process, so a `window` check reports "browser" while `process` and the filesystem are right there. - Other **JavaScript runtimes** exist — server runtimes and edge environments that implement web APIs without being a browser and without being Node. Binary host detection has no correct answer for them. The deeper problem is that a host check answers a question you did not ask. Your next line does not need to know what the host is; it needs to know whether a specific function exists. ## Detect the capability ```js const canFetch = typeof fetch === 'function'; const canClone = typeof structuredClone === 'function'; const canStore = typeof localStorage !== 'undefined'; const canObserve = typeof IntersectionObserver === 'function'; ``` Three properties make these better than host guesses. They are **local** — the condition sits next to the call it protects, so a reader sees exactly why the branch exists. They are **stable** — when a runtime gains the feature, the check simply starts returning `true` and the good path runs, with no code change. And they are **honest** — they claim only what they tested. Prefer `typeof X === 'function'` over truthiness for callables: it rejects a non-callable stand-in and does not throw on an undeclared name. ## When a host check is still the right check Some questions genuinely are about the host, because no polyfill makes them ambiguous in practice: - "Is there a document to render into or listen on?" — `typeof document !== 'undefined'`. - "Do I have a filesystem and a process to read configuration from?" — this is where `process` legitimately appears. Even then, prefer the narrowest phrasing. `typeof document !== 'undefined'` says "a DOM exists", which is what your code needs; `isBrowser()` says something broader that you cannot actually verify. And be aware that `typeof process !== 'undefined'` is not proof of Node — browser bundles sometimes carry a small `process` stand-in so that `process.env` references survive, which is enough to fool a naive check. ## Decide what the missing branch does A capability check is only half a design; the other half is the fallback, and it should be a deliberate choice rather than a silent `return`: - **Degrade**: return a sensible default and carry on (`getTheme()` returns `'light'` where there is no storage). - **Defer**: do nothing now and let the browser-side lifecycle run it later — right for effects like measuring, focusing or observing. - **Delegate**: take the capability as a parameter. A module that accepts `{ fetch }` from its caller has no detection code at all, is trivially testable, and works in any runtime the caller can satisfy. Delegation is the senior move: it converts an environment question into an ordinary dependency, and dependencies can be substituted, mocked and reasoned about. ```js export function createClient({ fetch: fetchImpl = globalThis.fetch } = {}) { if (typeof fetchImpl !== 'function') { throw new TypeError('createClient requires a fetch implementation'); } return { get: (url) => fetchImpl(url).then((r) => r.json()) }; } ``` Note the default read through `globalThis`, which is safe in every host, and the loud failure when nothing satisfies the requirement — far better than an obscure `undefined is not a function` three layers deeper. ## Version-sensitivity, stated honestly If your code relies on `fetch` being global rather than injected, you are declaring a Node floor of 18. That belongs in the package's stated engine range and in your CI matrix, not in a comment. Capability detection tells you what is there at runtime; the supported-version statement tells your users what you promise. Both are needed, and conflating them is how a library ends up silently degrading on the very versions it advertises. ## The answer in one breath Ask what you need, not where you are. Capability checks age well, host checks age badly, and the best shared modules avoid the question entirely by accepting the capability from their caller.