Which Web APIs Matter Most?

Most jobs only need a handful, and they fall into four groups.

Networking. The fetch function for HTTP requests, the WebSocket constructor for a persistent connection, and the EventSource constructor for server-sent events. In Node, the WebSocket and EventSource classes now exist as globals too, which is worth knowing if you write code that runs in both places.

Storage and state. Local storage and session storage for small pieces of text, the Cache API for storing responses, and the IndexedDB API for structured, sizeable data that survives a reload.

Timers and scheduling. The timer functions, the animation frame request for work tied to the display, and the idle callback for work that can wait.

Device and platform. The clipboard API, the geolocation API, the media devices API for cameras and microphones, the notifications API, and the share API for the system share sheet.

// Feature detection tells you what the runtime can do.
const features = {
  fetch: typeof fetch !== "undefined",
  localStorage: typeof localStorage !== "undefined",
  clipboard: typeof navigator !== "undefined" && Boolean(navigator.clipboard),
  notifications: typeof Notification !== "undefined",
  webSocket: typeof WebSocket !== "undefined",
  intersectionObserver: typeof IntersectionObserver !== "undefined",
};

for (const [name, supported] of Object.entries(features)) {
  console.log(name, supported ? "available" : "not available");
}

The pattern in the snippet is the one to remember. Feature detection with the typeof operator tells you what the current runtime supports, which is more reliable than sniffing the user agent string. A user agent check tells you what the browser claims to be, and it is wrong often enough that it causes real bugs.

Two categories are deliberately missing from that list. The first is anything that needs a secure context, such as the clipboard and the geolocation, which only work on a secure origin. The second is anything that is asynchronous about permission, such as the notifications and the media devices, where the API existing does not mean you have permission to use it. Both need their own handling at runtime.

The Intl API gives you locale-aware formatting without shipping your own tables of strings. It is built into the language, so it works in browsers and in Node.

// Numbers.
console.log(new Intl.NumberFormat("en-GB", { style: "currency", currency: "GBP" }).format(1234.5));
// "£1,234.50"
console.log(new Intl.NumberFormat("en-GB", { style: "percent" }).format(0.256));
// "26%"

// Dates.
console.log(new Intl.DateTimeFormat("en-GB", { dateStyle: "medium" }).format(new Date("2026-03-01T12:00:00Z")));
// "1 Mar 2026"

// Relative time.
console.log(new Intl.RelativeTimeFormat("en", { numeric: "auto" }).format(-3, "day"));
// "3 days ago"

// Lists.
console.log(new Intl.ListFormat("en", { style: "long" }).format(["closures", "promises"]));
// "closures and promises"

Why this matters more than it looks. Hand-rolled formatting, such as joining thousand separators with a regular expression, gets the separators right but the ordering, the decimal separator and the currency placement wrong for most of the world. The Intl API delegates to the platform's own locale data, so a Japanese or Indian locale is correct without you writing a line of special cases.

Two performance notes. Every constructor is relatively expensive, so create the formatter once and reuse it rather than creating one per call in a loop. And you can pass a list of locales to the constructor, and it will pick the first one that is supported, which is exactly what you want for a user whose preferences are in one of several languages.

The plural rules API is worth knowing as well, because it tells you which plural category a number falls into for a language, and languages have more than the two forms that English has. If you are building anything with translated strings and counts, that is the piece that stops your translations from looking wrong.