Web Platform & APIs
On top of the language, the browser provides a set of platform APIs for talking to the outside world: the network (XMLHttpRequest, fetch), storage (localStorage, IndexedDB), background threads (web workers, service workers), and channels between contexts (postMessage, server-sent events). This is the layer where most of the "real" application code is written.
The thread running through the topic is asynchrony and isolation. Almost every one of these APIs either does not block the main thread (promises, events, transactions) or moves work off it entirely (workers). Understanding who does not block whom, and who exchanges data with whom, matters more than knowing signatures. Each layer below unpacks one API.
Topic map
- AJAX and XMLHttpRequest — the classic request API,
readyState, callbacks, and whyfetchdisplaced it. - The Fetch API — promise-based requests,
Response, whyfetchdoes not fail on a 404, and how to cancel it. - Client storage — web storage vs IndexedDB, synchronous string vs asynchronous transactional.
- postMessage — safe messaging between windows and iframes across the same-origin policy.
- Service workers — a network proxy, the lifecycle, cache and offline, the basis of a PWA.
- Worker threads — background threads, message passing, and Transferable objects.
- Server-sent events — one-way server push via
EventSourceand how it differs from WebSocket.
Common traps
| Mistake | Consequence |
|---|---|
Expecting fetch to reject on a 404 | fetch rejects only on a network failure; a 404/500 is a successful resolve — check response.ok |
Thinking fetch(url) returns data | It resolves to a Response when headers arrive; the body is read separately via .json()/.text() |
Storing large structured data in localStorage | Web storage is synchronous, strings only, and ~5 MB; IndexedDB is the async store for this |
Not checking event.origin in message | Any page can post to you — it is an XSS channel |
| Keeping state in service-worker globals | The worker is killed on idle and restarted; state belongs in IndexedDB or a cache |
| Confusing a service worker with a plain worker | The first is an origin-level network proxy; the second is a background thread for CPU work |
| Choosing WebSocket where SSE would do | For one-way server push SSE is simpler and auto-reconnects itself |
Interview relevance
Web platform APIs are asked to gauge whether you have built real apps, not just tutorials. A candidate who remembers that fetch does not reject on a 404 and that a service worker tolerates being killed on idle has clearly met these in practice.
Typical checks:
- How
fetchimproves on XHR and its two traps — no reject on an HTTP error and reading the body separately. - The difference between web storage and IndexedDB in synchrony, size, and data types.
- Why you check
event.origininpostMessage. - The service-worker lifecycle and how it enables offline.
- When SSE is enough and when you need a WebSocket.
Common wrong answer: "if the server returns 404, fetch throws into catch". In fact the fetch promise resolves on both 404 and 500 — only a network failure counts as an error, and you must check the status yourself via response.ok.