21 — Web APIs — The Browser's Built-in Toolbox

"Web API" sounds like a URL you hit and get JSON back, which is why I confused it with REST for so long. In the browser context where the roadmap groups them, it's something else entirely: an interface the browser exposes that lets my JavaScript reach beyond the language itself — into the page, the network, the disk, the device. [1] The model that made it click: the browser is a toolbox, and a Web API is each capability inside it, handed to my code as an object.

Here's the whole toolbox laid out, grouped by what each capability lets the code touch:

DOM and the page

The first capability the browser hands over is the page itself. The DOM — the tree of meaning the browser built from the HTML — is exposed as the global document object [1][3]. Every querySelector, every addEventListener, every element.textContent = ... is a call into that object. The wider environment lives one level up as window — the browser tab, its history (window.history), its URL (window.location), the screen size. The mental move I had to make: when I write document.querySelector('.btn'), I'm not doing "JavaScript stuff." I'm calling a method on an object the browser built and gave me. Without the browser host, document doesn't exist — pure JavaScript has no DOM.

Network

The next drawer is reaching out across the wire from inside the page. fetch() is the modern interface — a promise-based function that takes a URL and returns the response [1][4]. Its older sibling, XMLHttpRequest, still powers a lot of legacy code and libraries; I reach for fetch unless I have a reason not to. This is the corner where the name collision bites hardest: fetch is a Web API, and it does call network endpoints, so "Web API" in this sense overlaps with "an API on the web." The distinction I keep straight now: the endpoint on the server is the thing I'm calling; fetch is the browser capability that lets me call it. The first lives on someone's server; the second is built into my tab.

Storage

Then there's the disk — or rather, a small sandboxed slice of it the browser lets my code write to. Three flavors, picked by how much I need to store and how long it should last [1][4]:

• localStorage — small (a few MB), synchronous (it blocks until the write is done), survives forever until cleared. Good for a theme toggle or a dismissed banner.
• sessionStorage — same API, wiped when the tab closes.
• IndexedDB — a real NoSQL database inside the browser (NoSQL just means it's not the traditional table-and-rows kind), asynchronous (works in the background without blocking), handles large structured data. The one to reach for when "save this for offline" gets serious.

Cookies sit adjacent but aren't really this layer — they're sent with every request, more a network contract than a storage API.

Device

The drawer I find most surprising is the one that touches hardware. The browser mediates the camera and microphone through navigator.mediaDevices, reads location through navigator.geolocation, senses battery level, vibration, clipboard, fullscreen, notifications [1]. What makes this safe to expose at all is that every one of these is permission-gated — the browser prompts the user, the user grants or denies, and my code only ever sees the answer. That mediation is the whole point: my JavaScript never talks to the camera driver directly. It asks the browser, the browser asks the user, the browser reports back.

Background

The last drawer is the one that breaks the page's default model — that JavaScript runs on a single thread and stops the moment the tab closes. Web Workers let me spin up a separate thread for heavy computation, so sorting ten thousand rows doesn't freeze the UI [1]. Service Workers are stranger: they run independent of any page, can intercept network requests, and are the engine behind offline-first apps and push notifications [4]. Both are still JavaScript, but they live in a different scope than the page — self instead of window — because there's no DOM in a worker. They're a glimpse of the browser as more than a renderer.

One thing they share

Every drawer above shares a single trait that took me a while to notice: these interfaces are not JavaScript. They're defined by standards bodies (W3C, WHATWG), implemented by each browser, and surfaced to whatever scripting language the browser happens to host [2]. fetch, document, localStorage, geolocation — they exist in the browser whether I write the page in JavaScript, TypeScript, or a language compiled to WASM (WebAssembly — a low-level format browsers can run). My JS calls them; it didn't bring them. That's why their availability is a browser-support question, not a language one.

How I use this

The payoff of the toolbox model is mostly diagnostic. When a feature "doesn't work," I now ask which capability is missing, instead of flailing:

• fetch returns undefined or a CORS error → Network drawer, and the issue is usually the server's headers, not my call. (CORS is the browser's rule about which servers a page is allowed to call.)
• Data disappears on refresh → Storage drawer, and I picked the wrong one (probably sessionStorage when I meant localStorage).
• Geolocation silently fails → Device drawer, and the user denied the prompt (or the page isn't served over HTTPS — most device APIs require it).
• UI janks during a big compute → Background drawer, and I should offload to a Worker.

Naming the drawer before reaching for a fix turned "the browser is broken" into a question with a small, finite answer set. That's the whole reason I wrote these notes down.

References

[1] Mozilla, "Web APIs," MDN Web Docs, 2024. [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/API

[2] Refsnes Data, "Web APIs - Introduction," W3Schools, 2024. [Online]. Available: https://www.w3schools.com/js/js_api_intro.asp

[3] Mozilla, "Document Object Model (DOM)," MDN Web Docs, 2024. [Online]. Available: https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model

[4] Google, "Fundamentals of Service Workers," web.dev, 2023. [Online]. Available: https://web.dev/articles/service-workers