DEV Community: Parsa Jiravand

Five tabs open, one refresh token — the race nobody noticed

Parsa Jiravand — Sat, 15 Aug 2026 06:44:54 +0000

A user reports that they keep getting logged out. Not immediately — after a while, randomly, always mid-task. You can't reproduce it. You check the server logs and find something stranger than a bug report: the same refresh token, submitted four times in the same eleven-millisecond window, from the same user, same IP, same session. The server does what any reasonable auth server does with a reused refresh token — it assumes theft and revokes the whole session.

The user didn't do anything wrong. They just had four tabs open.

Why one user becomes four requests

Your access token expires. Every tab that's currently open holds its own copy of the JavaScript running your app, and every one of those copies is watching the same clock. The moment the token goes stale, each tab's fetch wrapper notices independently and does the sensible thing: call the refresh endpoint before retrying the failed request.

Four tabs, four independent "sensible things," at nearly the same instant. The server sees four refresh attempts for one token. Depending on how strict your rotation policy is, the second one in either succeeds and burns the token for the other three, or the server flags it as replay and kills the session outright. Either way, the user gets logged out for the crime of having your app open twice.

The fix that looks right and isn't

The instinct is to reach for localStorage as a shared flag, since it's the one thing every tab on the origin can already see:

// Looks like a mutex. Isn't one.
async function refreshIfNeeded() {
  if (localStorage.getItem('refreshing') === 'true') {
    await waitForFlagToClear();
    return;
  }
  localStorage.setItem('refreshing', 'true');
  await refreshToken();
  localStorage.removeItem('refreshing');
}

This passes every manual test you run by clicking around in two tabs, because you're slower than the bug. The problem is that "check the flag, then set the flag" is two separate operations, and nothing stops two tabs from both running the check before either of them runs the set. localStorage reads and writes aren't atomic across tabs — there's no lock on the lock. You've built the exact race you were trying to prevent, just with extra steps and a waitForFlagToClear polling loop bolted on.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

The actual fix: `navigator.locks`

The Web Locks API gives you what localStorage was pretending to be: a real, origin-scoped mutex that the browser itself arbitrates, shared across every tab, iframe, and worker on that origin.

async function refreshIfNeeded() {
  return navigator.locks.request('refresh-token', async (lock) => {
    // Only one tab's callback runs at a time for this lock name.
    // Everyone else queues here until it's their turn.
    if (tokenIsStillValid()) return; // by the time we got the lock, someone else already refreshed
    await refreshToken();
  });
}

navigator.locks.request(name, callback) returns a promise that resolves once your callback's own returned promise settles — and the lock is held for exactly that long. Call it from all four tabs at once and the browser queues three of them. The first one through does the actual refresh; by the time the second tab gets its turn, the token check at the top short-circuits and it does nothing. No polling, no flag to forget to clear, no window where two tabs both think they're first.

The mode option is where it earns its name: exclusive (the default) allows one holder, shared allows many readers at once as long as no writer is waiting — the same read/write distinction you'd reach for with any mutex. Pass { ifAvailable: true } if you want to try the lock without waiting, or a signal if the wait itself needs to be cancellable.

Where else this shows up

Token refresh is the clearest case, but the pattern is "N tabs, one shared resource, exactly-once semantics" — and that shows up more than you'd think:

IndexedDB migrations. A schema upgrade that runs once per version, not once per open tab.
Single-flight cache fills. Five tabs all miss a cache entry at once; you want one network request, not five.
Cross-tab leader election. One tab should own a websocket or a polling interval; the rest should just listen. Hold a lock for as long as the tab is "leader," and release it (close the tab, or explicitly) to let another tab take over.

Each of these is a version of the same bug: code that's correct for one execution context quietly breaks the moment a user does something completely reasonable, like opening a second tab.

What this isn't

navigator.locks doesn't send data between tabs — that's BroadcastChannel's job, and the two pair well together (grab the lock, do the work, broadcast the result to whoever's waiting). Locks answer "who goes first," not "who else needs to know." Confusing the two gets you either a mutex trying to carry a payload, or a message channel trying to enforce mutual exclusion — both are the wrong tool wearing the other one's hat.

Browser support

navigator.locks shipped in Chrome 69 (2018), Firefox 96 (2022), and Safari 15.4 (2022) — all three major engines have had it for years, so it's safe to reach for directly rather than feature-detecting a fallback.

🧠 Test yourself

Think it clicked? Take the 8-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

If your app has ever logged a user out for no reason they could explain, check whether the fix you'd reach for — a flag in localStorage, a "just add a delay" hack — is really a mutex, or just something that looks like one until two tabs hit it at the same millisecond. navigator.locks.request() is the browser handing you a real one, for free, scoped exactly where you need it: across every tab your user happens to have open.

Have you shipped a bug that only showed up with multiple tabs open? What was it, and how long did it take to reproduce?

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

You copy and reverse the array to find the last match. `findLast()` searches from the end directly.

Parsa Jiravand — Fri, 14 Aug 2026 07:38:34 +0000

Here is a pattern that shows up in almost every codebase:

const lastActive = [...users].reverse().find(u => u.status === 'active');

It works. But it creates a full copy of the array, reverses that copy in place, and then walks it from the start. All to get one element near the end. The bigger the array, the more wasteful this is — and the less obvious the intent becomes to the next reader.

ES2023 added findLast() to handle this directly.

How `findLast()` works

findLast() takes the same callback as find() — a predicate that receives the current element, its index, and the array — but it starts at the last index and works backward:

const lastActive = users.findLast(u => u.status === 'active');

The original array is not copied. It is not reversed. The method walks backward in a single pass and returns the first element for which the predicate returns true — which is the last such element from the array's perspective.

const transactions = [
  { id: 1, type: 'credit', amount: 100 },
  { id: 2, type: 'debit',  amount: 40  },
  { id: 3, type: 'credit', amount: 200 },
  { id: 4, type: 'debit',  amount: 75  },
];

const lastCredit = transactions.findLast(t => t.type === 'credit');
// { id: 3, type: 'credit', amount: 200 }

Like find(), it returns undefined if no element matches.

`findLastIndex()` for when you need the position

findLast() returns the element. findLastIndex() returns its index — useful when you need to slice, splice, or reference the position rather than the value:

const lastCreditIndex = transactions.findLastIndex(t => t.type === 'credit');
// 2

// Example: everything from the last credit onward
const tail = transactions.slice(lastCreditIndex);

When no element matches, findLastIndex() returns -1, matching the behavior of findIndex():

transactions.findLastIndex(t => t.type === 'refund'); // -1

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

Real-world patterns

Audit logs and event histories. You often want the most recent event matching a condition — the last failed login, the last status change, the last error before a success:

const lastFailure = auditLog.findLast(e => e.level === 'error');
if (lastFailure) {
  showErrorBanner(lastFailure.message);
}

Undo stacks. Finding the most recent reversible operation without rebuilding the stack:

const lastUndoable = history.findLast(entry => entry.undoable);

Form field arrays. Finding the last populated row in a dynamic form:

const lastFilledIndex = rows.findLastIndex(row => row.value.trim() !== '');
const rowsToSubmit = rows.slice(0, lastFilledIndex + 1);

In all of these, the intent — "the most recent X that satisfies Y" — maps directly onto findLast. The [...arr].reverse().find() workaround buries that intent behind three operations.

TypeScript types

TypeScript has typed findLast() and findLastIndex() since version 4.9 — the same release that added the satisfies operator. The return type mirrors find():

interface User {
  id: number;
  status: 'active' | 'inactive';
}

const users: User[] = [...];

const last = users.findLast(u => u.status === 'active');
// type: User | undefined

const lastIndex = users.findLastIndex(u => u.status === 'active');
// type: number

No extra configuration needed. The types live in lib.es2023.array.d.ts and are included automatically when your tsconfig targets ES2023 or later — or when you add "ES2023" to your lib array explicitly.

Browser support

findLast() and findLastIndex() are Baseline 2022: Chrome 97 (January 2022), Firefox 104 (August 2022), Safari 15.4 (March 2022). Node.js has supported them since version 18. There is nothing to install and no polyfill needed for any actively maintained runtime.

🧠 Test yourself

Think it clicked? Take the 6-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for reverse().find( and reverse().findIndex(. Each one is a findLast() or findLastIndex() in disguise — wrapped in a copy that exists only to flip the direction. Replace them and the intent reads directly: start from the end, return the first match you find.

find() and findIndex() search from the front. findLast() and findLastIndex() search from the back. They're symmetric, they're in every modern runtime, and there's no longer a reason to reach for the workaround.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

Your `fetch()` in `beforeunload` is being silently dropped. Use `navigator.sendBeacon()`.

Parsa Jiravand — Thu, 13 Aug 2026 07:40:47 +0000

When a user closes a tab, submits a form, or clicks an external link, you often need to send one last piece of data — a session duration, the last scroll position, an unhandled error report, an A/B test completion event. The natural instinct is to fetch() inside a beforeunload handler. The problem: modern browsers cancel in-flight requests the moment the page begins to unload. Your data never arrives, and you never find out.

Why `fetch` in `beforeunload` fails

The browser's job during a page unload is to navigate away as fast as possible. Keeping a page alive to wait for a network response directly conflicts with that goal. Modern browsers — Chrome, Firefox, Safari — cancel async requests that are in-flight during unload. The beforeunload handler runs, fetch() is called, and the request is silently aborted before it reaches the server.

// This looks correct, but the request is often cancelled
window.addEventListener('beforeunload', () => {
  fetch('/api/session-end', {
    method: 'POST',
    body: JSON.stringify({ duration: getSessionDuration() }),
  });
  // The browser navigates away. Fetch is cancelled. Data is lost.
});

The old workaround was a synchronous XMLHttpRequest, which blocks the page from closing until the request completes. That approach worked — and also made every tab close feel sluggish. Browsers deprecated synchronous XHR in unload contexts because it reliably degraded user experience. Chrome has been logging warnings about it since 2019.

The API

navigator.sendBeacon() is built for exactly this case:

window.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    navigator.sendBeacon('/api/session-end', JSON.stringify({
      duration: getSessionDuration(),
      page: location.pathname,
    }));
  }
});

The browser queues the request and delivers it asynchronously, even after the page has been discarded. The tab can close, the browser can background-suspend the tab, the user can navigate away — the beacon is still delivered. You get no response object back; sendBeacon returns true if the data was successfully queued, false if the payload is too large or the browser rejected it. There is no callback, no .then(), no await. That's intentional: the call is fire-and-forget by design.

Why `visibilitychange` instead of `beforeunload`

beforeunload has a reliability problem beyond network requests: on mobile, it often doesn't fire at all. When the OS suspends a browser tab or the user swipes the app away, there's no beforeunload event — the page just disappears.

document.visibilitychange with document.visibilityState === 'hidden' is more reliable:

window.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    // Page is backgrounded, tab switched, device locked, or tab closing
    navigator.sendBeacon('/api/beacon', payload);
  }
});

The hidden event fires whenever the page leaves the foreground — including on mobile when the user switches apps. It's not a perfect signal for "tab is closing specifically," but it's the closest reliable approximation, and it fires in situations where beforeunload is completely absent.

What you can send

sendBeacon accepts a BodyInit — the same types that fetch accepts as a body:

// String (Content-Type: text/plain)
navigator.sendBeacon('/api/log', 'user-exited');

// JSON string (still text/plain — set Content-Type via Blob)
const blob = new Blob([JSON.stringify({ event: 'exit', ts: Date.now() })], {
  type: 'application/json',
});
navigator.sendBeacon('/api/log', blob);

// FormData (Content-Type: multipart/form-data)
const form = new FormData();
form.append('event', 'exit');
navigator.sendBeacon('/api/log', form);

// URLSearchParams (Content-Type: application/x-www-form-urlencoded)
navigator.sendBeacon('/api/log', new URLSearchParams({ event: 'exit' }));

The Blob approach with an explicit type is the most useful — it lets you send JSON while controlling the Content-Type header so your server receives it correctly. Without the Blob wrapper, a stringified JSON payload arrives as text/plain, and any middleware expecting application/json will reject or misparse it.

The `keepalive` fetch alternative

If you need a response from the server, or you want to add custom headers, fetch with keepalive: true is the modern alternative:

window.addEventListener('visibilitychange', () => {
  if (document.visibilityState === 'hidden') {
    fetch('/api/session-end', {
      method: 'POST',
      keepalive: true,
      headers: { 'Content-Type': 'application/json', 'X-Auth': token },
      body: JSON.stringify({ duration: getSessionDuration() }),
    });
  }
});

keepalive: true tells the browser to keep the request alive even if the page is discarded. Unlike sendBeacon, you can set headers and use any HTTP method. The trade-off: total keepalive payload per page is capped at 64 KB across all requests. sendBeacon has the same limit. For analytics payloads, 64 KB is effectively unlimited — but for large error dumps, be aware of it.

Use sendBeacon when you don't need custom headers and want the simplest possible fire-and-forget. Use keepalive fetch when you need headers, a specific HTTP method, or want to handle a response.

Browser support

navigator.sendBeacon() is Baseline 2022: Chrome 39 (2014), Firefox 31 (2014), Safari 11.1 (2018). It has been available in every supported browser for years and works in Web Workers. There is nothing to polyfill for any currently-maintained target.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

🧠 Test yourself

Think it clicked? Take the 8-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for fetch or XMLHttpRequest inside beforeunload or unload handlers. If you find them, the data they send is being silently dropped in a meaningful percentage of page exits. Replace them with navigator.sendBeacon() on visibilitychange, or a keepalive fetch if you need headers. The API is one line, the delivery is reliable, and the browser handles the timing without blocking navigation.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

Search your codebase for storage event listeners paired with a localStorage.setItem that immediately gets removed. That pattern is cross-tab messaging through a storage side-channel — exactly what BroadcastChannel exists to replace

Parsa Jiravand — Thu, 13 Aug 2026 07:27:44 +0000

Avoids localStorage cleanup bugs

Parsa Jiravand

Aug 9

Stop using the localStorage hack to sync browser tabs. BroadcastChannel does it natively.

#javascript #webdev #frontend #api

4 min read

You're blocking touchmove events to contain scroll. `overscroll-behavior` does it natively.

Parsa Jiravand — Wed, 12 Aug 2026 07:38:53 +0000

When a user scrolls to the bottom of a modal and keeps scrolling, the page behind it starts moving. This is scroll chaining — the browser passes the scroll gesture up through the DOM when the focused container runs out of room. The traditional fix is JavaScript: intercept touchmove events, check whether the container has hit its boundary, and call preventDefault(). There's a CSS property for this.

The property

overscroll-behavior controls what happens when a scroll gesture reaches the edge of a scrollable container. Three values:

auto — the default; scroll chains to the parent element
contain — stops chaining at this element; overscroll effects (bounce, glow highlight) still render
none — stops chaining and suppresses the overscroll effect entirely

.modal-body {
  overflow-y: auto;
  overscroll-behavior-y: contain;
}

One property on one element. The browser's own scroll machinery handles containment — no event listener, no JavaScript.

What it replaces

Here's the JavaScript approach, written carefully enough to actually work:

// Before — fragile, performance-hostile
let touchStartY = 0;

modal.addEventListener('touchstart', (e) => {
  touchStartY = e.touches[0].clientY;
}, { passive: true });

modal.addEventListener('touchmove', (e) => {
  const delta = touchStartY - e.touches[0].clientY;
  const atBottom = modal.scrollTop >= modal.scrollHeight - modal.clientHeight;
  const atTop    = modal.scrollTop <= 0;

  if ((atBottom && delta > 0) || (atTop && delta < 0)) {
    e.preventDefault(); // ← requires passive: false
  }
}, { passive: false }); // ⚠️ kills scroll performance

passive: false is the problem. Browsers optimistically start compositing the scroll on the GPU — when a listener is passive, they don't wait for it. The moment you declare passive: false, the browser has to park the entire scroll gesture, wait for your handler to finish, then decide whether to scroll. You pay that cost on every touchmove event, on every device, whether the user is anywhere near the edge or not. Chrome logs a warning about this in DevTools.

With CSS:

/* After — one declaration, no event listener */
.modal-body {
  overflow-y: auto;
  overscroll-behavior-y: contain;
}

No passive penalty. No edge-case bugs where the user simultaneously hits the top and bottom boundary during a fast flick. No listener to clean up when the modal unmounts.

Pull-to-refresh and browser navigation

overscroll-behavior controls two other native gestures besides scroll chaining.

Pull-to-refresh on mobile Chrome. Overscrolling past the top of the page triggers the refresh gesture. If you've built a custom refresh indicator, or you're shipping an app shell where the native gesture doesn't belong, disable it on the document:

body {
  overscroll-behavior-y: none;
}

Use this deliberately. Pull-to-refresh is a familiar gesture — suppressing it at the body level surprises users on pages that function as documents. Reserve it for true app shells.

Back-navigation swipes on horizontal carousels. On macOS trackpads and some mobile browsers, swiping past the last card in a horizontal scroll container triggers browser back/forward navigation. This is almost never what you want:

.carousel {
  overflow-x: auto;
  overscroll-behavior-x: contain;
}

The carousel scrolls freely within its bounds; going past the last slide does nothing instead of navigating away.

The shorthand and axis properties

There are two axis-specific variants and a shorthand:

/* Both axes */
overscroll-behavior: contain;

/* Axis-specific */
overscroll-behavior-x: contain;
overscroll-behavior-y: none;

/* Shorthand: x-value then y-value */
overscroll-behavior: contain none;

The most common pattern is overscroll-behavior-y: contain on vertically scrollable panels — modals, drawers, sidebars, dropdown bodies — where you want scroll to stay inside the component without disabling anything horizontally.

Browser support

overscroll-behavior is Baseline 2019: Chrome 63 (December 2017), Firefox 59 (March 2018), Safari 16 (September 2022). iOS Safari was the last major holdout, shipping support in late 2022. It's been broadly available for several years across browsers, Node.js-powered WebViews, and PWA contexts.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

🧠 Test yourself

Think it clicked? Take the 7-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for touchmove listeners that call e.preventDefault() to stop scroll from escaping a container — those are scroll-chaining patches. Replace the listener with overscroll-behavior: contain on the scrollable element and delete the JavaScript. While you're at it, add overscroll-behavior-x: contain to any horizontal scroll container where you don't want browser navigation triggered at the edges. The CSS path doesn't touch the browser's scroll machinery, scales to every device with no tuning, and removes a passive-false listener that was slowing down every scroll gesture regardless of whether it hit the boundary.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

You're polling setInterval to detect DOM changes. `MutationObserver` fires when they happen.

Parsa Jiravand — Tue, 11 Aug 2026 15:48:01 +0000

The DOM can change in ways your code didn't trigger — a third-party widget injects a node, a library adds a class, a rich text editor updates its content. The common response is polling: setInterval(() => checkIfThingChanged(), 100). It works until it doesn't. You tune the interval, miss changes that happen between ticks, and pay CPU cost whether anything changes or not. MutationObserver is the built-in answer.

The API

const observer = new MutationObserver((mutations) => {
  for (const mutation of mutations) {
    console.log(mutation.type);         // 'attributes' | 'characterData' | 'childList'
    console.log(mutation.target);       // the node that changed
    console.log(mutation.addedNodes);   // NodeList (for childList mutations)
    console.log(mutation.oldValue);     // previous value (if requested)
  }
});

observer.observe(document.getElementById('app'), {
  childList: true,              // watch for added/removed child nodes
  subtree: true,                // include all descendants, not just direct children
  attributes: true,             // watch attribute changes
  characterData: true,          // watch text node content changes
  attributeOldValue: true,      // record the previous attribute value
  characterDataOldValue: true,  // record the previous text content
});

// Stop watching:
observer.disconnect();

Two steps: create an observer with a callback, then call .observe(node, options). The callback fires asynchronously after a batch of mutations completes — never mid-update — with an array of MutationRecord objects, one per change.

What it replaces

Here's the typical "wait for a class to appear" pattern using an interval:

// Before — fragile, always running
let seen = false;
const timer = setInterval(() => {
  const el = document.querySelector('.widget-loaded');
  if (el && !seen) {
    seen = true;
    clearInterval(timer);
    initWidget(el);
  }
}, 50);

The 50 ms interval means you catch changes up to 50 ms late, it burns CPU on every tick even when nothing is happening, and if you forget to clearInterval, it runs indefinitely. With MutationObserver:

// After — fires immediately when the node appears
const observer = new MutationObserver(() => {
  const el = document.querySelector('.widget-loaded');
  if (el) {
    observer.disconnect();
    initWidget(el);
  }
});

observer.observe(document.body, { childList: true, subtree: true });

No timer, no polling overhead, no missed windows.

Real-world use cases

Third-party widget lifecycle. When you embed a chat widget or payment form from a third party, you have no hook into when it finishes rendering. MutationObserver on the container gives you that hook without touching the third-party script.

Auto-resizing a textarea. The input event doesn't fire on programmatic changes. Observing characterData on the textarea's text node catches every content change regardless of source:

function autoResize(textarea) {
  const resize = () => {
    textarea.style.height = 'auto';
    textarea.style.height = `${textarea.scrollHeight}px`;
  };

  resize();

  const observer = new MutationObserver(resize);
  observer.observe(textarea, { characterData: true, subtree: true });
  textarea.addEventListener('input', resize);

  return () => observer.disconnect();
}

Accessible live announcements. Screen readers miss DOM updates that don't go through an aria-live region. A MutationObserver on a dynamic feed can forward new content to an announcer element, making additions audible without a framework:

const announcer = document.getElementById('sr-announcer'); // aria-live="polite"

const observer = new MutationObserver((mutations) => {
  for (const mutation of mutations) {
    for (const node of mutation.addedNodes) {
      if (node.textContent?.trim()) {
        announcer.textContent = node.textContent.trim();
      }
    }
  }
});

observer.observe(document.getElementById('feed'), { childList: true });

Batching and performance

MutationObserver delivers changes in batches. If a loop adds 500 nodes in one synchronous operation, you get one callback with 500 records — not 500 callbacks. This is intentional: the observer is low-overhead even on large, active DOM trees.

A few things to keep in mind:

Narrow the target. Observing document.body with subtree: true watches every node in the page. Prefer the smallest relevant container.
Always disconnect. The observer holds a reference to the target node, which can delay garbage collection. Call observer.disconnect() when you're done.
takeRecords() for early cleanup. This flushes any pending, undelivered records synchronously — useful when you need to process remaining mutations before disconnecting without waiting for the next callback.

Browser support

MutationObserver is Baseline 2015: Chrome 26 (2013), Firefox 14 (2012), Safari 7 (2013). It has shipped in every major browser and runtime for over a decade, including Web Workers.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

🧠 Test yourself

Think it clicked? Take the 9-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for setInterval calls that check a DOM condition and clear themselves once it's true — that's polling for a DOM change. MutationObserver replaces the pattern with a callback that fires the moment the change occurs, with zero cost in between. It completes the browser's built-in observer trio: IntersectionObserver for element visibility, ResizeObserver for element size, and MutationObserver for everything the DOM itself changes. Once you know all three, most "watch the DOM" problems reduce to picking the right one.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

You're importing pako to gzip data. `CompressionStream` does it natively.

Parsa Jiravand — Mon, 10 Aug 2026 07:49:27 +0000

Compressing data before writing it to IndexedDB or sending it over a slow connection is a real optimization. When a cached API response is too large for reliable storage, or when you need to shrink a JSON payload before POSTing it, pako.gzip() is the standard reach. But pako is a pure-JavaScript port of zlib — written in user space to fill a gap the browser had at the time. The CompressionStream API is that gap closing.

The API

CompressionStream is a transform stream — data goes in one end, compressed data comes out the other. The constructor takes a format string: 'gzip', 'deflate', or 'deflate-raw'.

const stream = new CompressionStream('gzip');

DecompressionStream is the mirror:

const stream = new DecompressionStream('gzip');

The Streams plumbing to feed data in and collect it out is the verbose part. Wrap it once:

async function compress(input, format = 'gzip') {
  const stream = new Blob([input]).stream().pipeThrough(new CompressionStream(format));
  return new Uint8Array(await new Response(stream).arrayBuffer());
}

async function decompress(input, format = 'gzip') {
  const stream = new Blob([input]).stream().pipeThrough(new DecompressionStream(format));
  return new Response(stream).text();
}

Blob.stream().pipeThrough() feeds the data into the transform stream; new Response(stream) collects the result. The idiom is three lines of plumbing written once, then call sites that read plainly.

Replacing pako

A direct swap for the most common pako usage patterns:

// Before — pako
import pako from 'pako';

const compressed = pako.gzip(jsonString);       // Uint8Array
const restored   = pako.ungzip(compressed, { to: 'string' });

// After — native
const compressed = await compress(jsonString);           // Uint8Array
const restored   = await decompress(compressed);         // string

The output is the same gzip-format Uint8Array. Any system that accepts pako's output accepts the native output — the wire format is identical.

Real-world patterns

Storing large JSON in IndexedDB:

async function putCompressed(store, key, data) {
  const compressed = await compress(JSON.stringify(data));
  return store.put(compressed, key);
}

async function getCompressed(store, key) {
  const compressed = await store.get(key);
  if (!compressed) return null;
  return JSON.parse(await decompress(compressed));
}

A 200 KB JSON object typically compresses to 15–30 KB with gzip. For quota-constrained storage like IndexedDB on mobile browsers, that difference matters.

Compressing in a Web Worker:

// worker.js
self.onmessage = async ({ data }) => {
  const compressed = await compress(JSON.stringify(data.payload));
  self.postMessage({ compressed }, [compressed.buffer]);
};

CompressionStream works in Web Workers and Service Workers — the same API, the same two-function wrapper, no restrictions. Offloading compression to a worker keeps the main thread free.

Format reference

The three supported formats map directly to pako's methods:

`CompressionStream` format	pako equivalent	When to use
`'gzip'`	`pako.gzip` / `pako.ungzip`	HTTP transport, file storage — the standard
`'deflate'`	`pako.deflate` / `pako.inflate`	zlib-wrapped deflate
`'deflate-raw'`	`pako.deflateRaw` / `pako.inflateRaw`	raw DEFLATE, no wrapper header

'gzip' is the right default for most use cases. Use 'deflate-raw' only when interoperating with a system that expects unwrapped DEFLATE.

Performance

CompressionStream calls into the browser's native zlib implementation — the same C code path used when the browser decompresses HTTP responses with Content-Encoding: gzip. pako re-implements that algorithm in JavaScript. The native path is measurably faster on large inputs:

For small payloads (< 10 KB), the difference is negligible.
For large payloads (100 KB+), native compression is typically 3–10× faster than pako, because there's no JavaScript overhead and the engine can use SIMD instructions.
There's also no bundle cost: pako adds ~45 KB minified to your bundle; CompressionStream adds zero.

Node.js

CompressionStream and DecompressionStream are available in Node.js 18.0 as part of the Web Streams implementation. The two-function wrapper above works unchanged in Node 18+ — useful for isomorphic utilities that run in both browser and server environments without branching on the environment.

Node's older zlib module (zlib.gzipSync, zlib.gunzipSync) is still more ergonomic for Node-only server code. But if you're writing a shared utility that must work in both contexts, CompressionStream is the right choice.

Browser support

CompressionStream is Baseline 2023: Chrome 80 (February 2020), Firefox 113 (May 2023), Safari 16.4 (March 2023), Node.js 18. The API has been in Chromium since early 2020; Firefox and Safari joined in 2023. It's available in all currently-supported browser and runtime versions, including Web Workers and Service Workers.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

🧠 Test yourself

Think it clicked? Take the 9-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your package.json for pako. If it's there and the use case is "compress a string or buffer before storing or sending it," the native API covers you. Replace pako.gzip and pako.ungzip with the two-function wrapper above, remove the dependency, and get native compression speed and zero bundle cost. The Streams API is verbose on its own — the wrapper absorbs that cost once so every call site stays clean.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

Stop using the localStorage hack to sync browser tabs. BroadcastChannel does it natively.

Parsa Jiravand — Sun, 09 Aug 2026 07:02:41 +0000

When a user logs out in one tab, the other tabs should follow. When they update their cart, every open window should reflect it. The common solution is a localStorage trick: write a sentinel value, listen for the storage event, read it, parse it, check if it's "for you," and clean it up. It works — but it's a side-channel communication pattern built on a persistence API that was never meant for messaging. The Broadcast Channel API is the direct path.

The API

// Sender (any tab, worker, or iframe on the same origin)
const channel = new BroadcastChannel('app-sync');
channel.postMessage({ type: 'LOGOUT' });

// Receiver (every other context subscribed to the same name)
const channel = new BroadcastChannel('app-sync');
channel.onmessage = (event) => {
  console.log(event.data); // { type: 'LOGOUT' }
};

Two steps: open a channel by name, then send or listen. Any tab, worker, or iframe on the same origin that opens a channel with the same name receives every message sent on it — including messages sent after they subscribed. The sender does not receive its own messages.

Close the channel when you're done to release the listener:

channel.close();

What the localStorage approach actually looks like

The typical cross-tab sync pattern using storage events:

// Sender
localStorage.setItem('__broadcast', JSON.stringify({ type: 'LOGOUT', t: Date.now() }));
localStorage.removeItem('__broadcast'); // clean up immediately

// Receiver
window.addEventListener('storage', (event) => {
  if (event.key !== '__broadcast') return; // filter noise
  if (!event.newValue) return;             // ignore the removeItem
  const message = JSON.parse(event.newValue);
  if (message.type === 'LOGOUT') { /* handle */ }
});

Every part of this is load-bearing workaround: the timestamp prevents deduplication if the same value is sent twice; the removeItem triggers a second storage event that must be filtered out; JSON.stringify/JSON.parse is required because storage only holds strings. BroadcastChannel replaces the entire block with a postMessage call.

Real-world use cases

Logout across all tabs. When the user logs out, invalidate the session in every open window simultaneously:

// auth.js — runs in every tab
const syncChannel = new BroadcastChannel('auth');

export function logout() {
  clearSession();
  syncChannel.postMessage({ type: 'SESSION_ENDED' });
  redirect('/login');
}

syncChannel.onmessage = (event) => {
  if (event.data.type === 'SESSION_ENDED') {
    clearSession();
    redirect('/login');
  }
};

Cart sync in an e-commerce app. Add to cart in one tab, see the count update in the header of every other tab:

const cartChannel = new BroadcastChannel('cart');

function addToCart(item) {
  const updated = updateLocalCart(item);
  cartChannel.postMessage({ type: 'CART_UPDATED', cart: updated });
  renderCart(updated);
}

cartChannel.onmessage = (event) => {
  if (event.data.type === 'CART_UPDATED') {
    renderCart(event.data.cart);
  }
};

Live config refresh. When an admin changes a feature flag in a settings tab, broadcast the update so every other open tab picks it up without a page reload.

What you can send

BroadcastChannel uses the structured clone algorithm — the same one used by structuredClone() and postMessage() on workers. That means you can send:

Plain objects and arrays (including nested)
Date, Map, Set, ArrayBuffer, Blob
Primitive values — strings, numbers, booleans, null

You cannot send functions, DOM nodes, or anything not serializable by structured clone. If you try, the call throws a DataCloneError. For the message payloads most apps actually use — event objects with typed fields — structured clone covers everything without the JSON roundtrip.

Scope and limits

BroadcastChannel is scoped to same-origin contexts — same protocol, hostname, and port. A channel named 'app-sync' on https://example.com is completely isolated from a channel with the same name on https://staging.example.com. You cannot use it to communicate between different origins.

The channel name is your namespace. If multiple features in your app use BroadcastChannel, give each a distinct name ('auth', 'cart', 'notifications') rather than sharing a single 'app' channel and multiplexing message types through it — separate channels are cleaner and don't require filtering.

Browser support

BroadcastChannel is Baseline 2022: Chrome 54 (2016), Firefox 38 (2015), Safari 15.4 (March 2022). The API has been in Chromium and Firefox for nearly a decade; Safari joined in 2022. It's available in all currently-supported browser versions and in Web Workers and Service Workers, not just the main thread.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

🧠 Test yourself

Think it clicked? Take the 9-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for storage event listeners paired with a localStorage.setItem that immediately gets removed. That pattern is cross-tab messaging through a storage side-channel — exactly what BroadcastChannel exists to replace. Swap it out: open a channel by name, call postMessage, listen with onmessage. You get structured data without serialization, no storage event noise to filter, and no cleanup sentinel to manage. The intent becomes clear in the code; the runtime handles the delivery.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

You built your modal with a `
` and a focus trap library. The native `` does all of that.

Parsa Jiravand — Sat, 08 Aug 2026 07:00:10 +0000

Building a modal from scratch means writing the same boilerplate every time: a <div> with role="dialog", an aria-modal attribute, a tabindex="-1" to steal focus, a keydown listener to catch Escape, a focus-trap library to keep Tab cycling inside the dialog, and a click listener on the backdrop overlay you rendered yourself. It works, but you're doing the browser's job.

The <dialog> element exists to take that job back.

The baseline API

<dialog id="confirm-dialog">
  <h2>Delete item?</h2>
  <p>This cannot be undone.</p>
  <button id="cancel-btn">Cancel</button>
  <button id="confirm-btn">Confirm</button>
</dialog>

<button id="open-btn">Delete</button>

const dialog = document.getElementById('confirm-dialog');
const openBtn = document.getElementById('open-btn');
const cancelBtn = document.getElementById('cancel-btn');
const confirmBtn = document.getElementById('confirm-btn');

openBtn.addEventListener('click', () => dialog.showModal());
cancelBtn.addEventListener('click', () => dialog.close());
confirmBtn.addEventListener('click', () => {
  deleteItem();
  dialog.close();
});

That's it. The browser handles focus trapping (Tab stays inside), Escape-to-close, and ARIA role. No library. No keydown listener. No backdrop div.

`showModal()` vs `show()`

The element has two open methods and they are meaningfully different.

dialog.show() opens the dialog as a non-modal: it's visible, but the rest of the page is still interactive. Useful for inline panels, drawers, or toasts — not for blocking confirmation flows.

dialog.showModal() opens it as a modal: the browser places the dialog in the top layer — above all other content, including elements with high z-index — and blocks interaction with everything beneath. Focus is trapped inside. Escape closes it. This is what you actually want for a modal dialog.

dialog.show();      // non-modal — rest of page still interactive
dialog.showModal(); // modal — top layer, focus trapped, Escape works

Styling the backdrop

When opened with showModal(), the browser renders a backdrop behind the dialog and above the rest of the page. You style it with the ::backdrop pseudo-element:

dialog::backdrop {
  background: rgb(0 0 0 / 50%);
  backdrop-filter: blur(4px);
}

No more position: fixed; inset: 0; background: rgba(0,0,0,0.5) divs. The browser-rendered backdrop is always in the right place, covers the right things, and is animated by the dialog's own open/close transitions.

Animating open and close

The <dialog> element pairs naturally with @starting-style for entry animations. For the exit, you need a small JS helper because the dialog's close() method removes the open attribute before a CSS exit transition can play:

dialog {
  opacity: 0;
  transform: scale(0.95);
  transition: opacity 200ms, transform 200ms, display 200ms allow-discrete;
}

dialog[open] {
  opacity: 1;
  transform: scale(1);
}

@starting-style {
  dialog[open] {
    opacity: 0;
    transform: scale(0.95);
  }
}

With allow-discrete on the display transition (Chrome 117+), the browser holds the dialog in the layout for the duration of the exit transition before hiding it. For older targets, a small setTimeout before dialog.close() is the reliable fallback.

Handling backdrop clicks to close

The backdrop is not a separate element you can listen to directly. The reliable pattern uses the dialog's own click event and checks whether the click landed inside the dialog's bounding box:

dialog.addEventListener('click', (event) => {
  const rect = dialog.getBoundingClientRect();
  const clickedOutside =
    event.clientX < rect.left ||
    event.clientX > rect.right ||
    event.clientY < rect.top ||
    event.clientY > rect.bottom;

  if (clickedOutside) dialog.close();
});

The reason this works: when you click the backdrop, the <dialog> element itself receives the event — the click target is the dialog, not an element inside it. The bounding box check distinguishes backdrop clicks from content clicks cleanly.

Return value from `close()`

dialog.close() accepts an optional string argument that becomes the dialog's returnValue. This lets you communicate why the dialog closed without external state:

confirmBtn.addEventListener('click', () => dialog.close('confirmed'));
cancelBtn.addEventListener('click', () => dialog.close('cancelled'));

dialog.addEventListener('close', () => {
  if (dialog.returnValue === 'confirmed') deleteItem();
});

The close event fires whenever the dialog closes — via close(), Escape, or a <form method="dialog"> submission. Combined with returnValue, it gives you a clean interface for confirmation flows without threading state through callbacks.

The `<form method="dialog">` shortcut

If you put a <form method="dialog"> inside a <dialog>, any submit button closes the dialog automatically and sets returnValue to the button's value attribute — no JavaScript needed for the close logic:

<dialog id="confirm-dialog">
  <form method="dialog">
    <h2>Delete item?</h2>
    <button value="cancelled">Cancel</button>
    <button value="confirmed">Confirm</button>
  </form>
</dialog>

dialog.addEventListener('close', () => {
  if (dialog.returnValue === 'confirmed') deleteItem();
});

The form doesn't submit to a server — method="dialog" is a special value that routes the submission back to the dialog element itself. Useful for simple flows; for complex forms with validation, you'll still handle submission explicitly.

Browser support

<dialog> is Baseline 2022: Chrome 98, Firefox 98, Safari 15.4. Global support is above 95%. You do not need a polyfill for production today. The only missing piece in some older browsers is ::backdrop styling — the functional modal behavior (focus trap, Escape, top layer) is universally supported.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

🧠 Test yourself

Think it clicked? Take the 8-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for role="dialog" and the focus-trap imports that live near it. Each one is a candidate for replacement: <dialog> with showModal() handles focus trapping, Escape, backdrop, and ARIA semantics — a library bought you those because the platform didn't provide them. It does now. Start with the simplest confirmation dialog in your UI, replace it with <dialog> and showModal(), and you'll notice what disappears: the keydown listener, the backdrop div, the z-index war, and the focus-management ceremony. What remains is the logic that was actually yours to write.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

Stop importing `uuid`. `crypto.randomUUID()` has been native since 2021.

Parsa Jiravand — Sat, 08 Aug 2026 07:00:09 +0000

The uuid npm package is one of the most downloaded libraries in the JavaScript ecosystem. The vast majority of those installs exist for one thing: uuid/v4, which generates a random unique identifier in the standard xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx format. The browser — and Node.js — have been doing this natively since 2021. No package needed.

The native API

const id = crypto.randomUUID();
// "110e8400-e29b-41d4-a716-446655440000"

That's the entire API surface. One call, no constructor, no configuration. It returns a v4 UUID string — the same format every UUID library produces, the same format your database expects.

crypto.randomUUID() lives on the Web Crypto API's crypto object, which is globally available in browsers, Node.js, Deno, Bun, and Cloudflare Workers. No import required.

Why it's safe to trust

The uuid/v4 package generates UUIDs using crypto.getRandomValues() internally — the same source crypto.randomUUID() uses. Both draw from the operating system's CSPRNG (cryptographically secure pseudorandom number generator). The native method adds nothing risky; it's the same primitive, one level closer to the metal.

// What uuid/v4 does internally (simplified):
function v4() {
  const bytes = crypto.getRandomValues(new Uint8Array(16));
  // ... set version and variant bits, format as string
  return formatted;
}

// What crypto.randomUUID() does:
const id = crypto.randomUUID(); // same operation, no library

The security profile is identical. The library adds no cryptographic benefit over the native call.

Where it works

crypto.randomUUID() is available in any secure context — HTTPS pages, localhost, Service Workers, Web Workers, and Node.js 14.17+.

// In a Service Worker
self.addEventListener('fetch', event => {
  const requestId = crypto.randomUUID();
  console.log(`[${requestId}] ${event.request.url}`);
});

// In a Web Worker
// Inside worker.js:
const taskId = crypto.randomUUID();
postMessage({ taskId, status: 'started' });

The "secure context" requirement is the only constraint. If your page is served over HTTPS (or you're on localhost), crypto is available everywhere the JavaScript runtime runs in that page — main thread, workers, service worker included.

Replacing the import

A direct swap, wherever you currently use uuid:

// Before
import { v4 as uuidv4 } from 'uuid';
const id = uuidv4();

// After
const id = crypto.randomUUID();

The output format is identical. Whether you're generating IDs in a React component, a route handler, a database model, or a logging utility — it's a one-line change per call site. Once every call is replaced, you can remove the dependency from package.json.

The one case where you still need a library

crypto.randomUUID() generates v4 UUIDs only — random, no namespace. If you need:

v5 UUIDs (namespace + name, SHA-1 hash based): still use uuid/v5
v3 UUIDs (namespace + name, MD5 hash based): still use uuid/v3
Parsing or inspecting UUID bytes, version bits, or variant: still use the library

If you're generating a unique ID for a database row, a request trace ID, a session token, or a UI list item key — v4 is the right choice. That's exactly what crypto.randomUUID() gives you.

Browser support

crypto.randomUUID() is Baseline 2022: Chrome 92 (July 2021), Firefox 95 (November 2021), Safari 15.4 (March 2022), Node.js 14.17 (May 2021). It has been in every supported browser and server runtime for years. There's nothing to polyfill for any currently-maintained target.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

🧠 Test yourself

Think it clicked? Take the 9-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Open your package.json. If uuid is listed and your codebase only uses v4, remove it. Search for uuid/v4, uuidv4(), or import { v4 } and replace each call with crypto.randomUUID(). You get the same string format, the same randomness quality, and zero added bundle weight. For v4 UUIDs — the most common case by a wide margin — the native method is strictly better than the library it replaces.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

You're installing date-fns for 'X hours ago'. `Intl.RelativeTimeFormat` does it natively.

Parsa Jiravand — Fri, 07 Aug 2026 07:22:54 +0000

When a comment timestamp reads "3 hours ago" instead of a raw ISO string, users stay oriented without thinking about it. Most teams reach for date-fns/formatDistanceToNow or moment().fromNow() to get there. Both pull in a full library for something the browser can do natively — and has been able to do since 2020.

The API

const rtf = new Intl.RelativeTimeFormat('en', { numeric: 'auto' });

rtf.format(-3, 'hour');   // "3 hours ago"
rtf.format(1, 'day');     // "tomorrow"
rtf.format(-1, 'day');    // "yesterday"
rtf.format(-2, 'week');   // "2 weeks ago"
rtf.format(3, 'month');   // "in 3 months"

Two arguments: a number (negative = past, positive = future) and a unit string. The constructor takes a locale identifier and an options object. That's the whole surface area.

The `numeric: 'auto'` option

The second constructor argument controls whether you get "1 day ago" or "yesterday". With numeric: 'always' (the default), every value is formatted as a number. With numeric: 'auto', the formatter substitutes natural language when it's available for that locale:

const always = new Intl.RelativeTimeFormat('en', { numeric: 'always' });
const auto   = new Intl.RelativeTimeFormat('en', { numeric: 'auto' });

always.format(-1, 'day');  // "1 day ago"
auto.format(-1, 'day');    // "yesterday"

always.format(0, 'day');   // "in 0 days"
auto.format(0, 'day');     // "today"

always.format(1, 'day');   // "in 1 day"
auto.format(1, 'day');     // "tomorrow"

In most UIs, numeric: 'auto' is what you want. Saying "yesterday" is more natural than "1 day ago" and it costs nothing extra.

Picking the right unit automatically

The API doesn't pick the unit for you — you pass 'hour' or 'week' explicitly. That means you need a helper that looks at the elapsed duration and decides which unit to use. Ten lines:

const rtf = new Intl.RelativeTimeFormat('en', { numeric: 'auto' });

const THRESHOLDS = [
  { unit: 'year',   ms: 365 * 24 * 60 * 60 * 1000 },
  { unit: 'month',  ms:  30 * 24 * 60 * 60 * 1000 },
  { unit: 'week',   ms:   7 * 24 * 60 * 60 * 1000 },
  { unit: 'day',    ms:       24 * 60 * 60 * 1000  },
  { unit: 'hour',   ms:            60 * 60 * 1000  },
  { unit: 'minute', ms:                 60 * 1000  },
  { unit: 'second', ms:                      1000  },
];

function timeAgo(date) {
  const diffMs = date - Date.now();
  for (const { unit, ms } of THRESHOLDS) {
    if (Math.abs(diffMs) >= ms) {
      return rtf.format(Math.round(diffMs / ms), unit);
    }
  }
  return rtf.format(0, 'second'); // "just now"
}

timeAgo(new Date(Date.now() - 2 * 60 * 60 * 1000)); // "2 hours ago"
timeAgo(new Date(Date.now() + 3 * 24 * 60 * 60 * 1000)); // "in 3 days"
timeAgo(new Date(Date.now() - 45 * 1000)); // "45 seconds ago"

You adjust the thresholds to your app's conventions — some UIs show minutes up to 90, others switch to hours at 60. The formatter handles the phrasing; the thresholds handle the unit selection.

Locale support comes for free

The formatter respects locale — the same code that prints "3 hours ago" in English prints "il y a 3 heures" in French, "vor 3 Stunden" in German, and "۳ ساعت پیش" in Persian, without any translation strings in your bundle.

const locales = ['en', 'fr', 'de', 'ja', 'ar'];
const twoHoursAgo = -2;

for (const locale of locales) {
  const rtf = new Intl.RelativeTimeFormat(locale, { numeric: 'auto' });
  console.log(`${locale}: ${rtf.format(twoHoursAgo, 'hour')}`);
}
// en: 2 hours ago
// fr: il y a 2 heures
// de: vor 2 Stunden
// ja: 2 時間前
// ar: قبل ساعتين

Most date libraries ship locale data as separate imports or packages — kilobytes of JSON per language. Intl.RelativeTimeFormat uses the locale data already in the JavaScript engine. Nothing extra to load.

What it doesn't do

Intl.RelativeTimeFormat formats a pre-computed duration. It doesn't parse date strings, calculate diffs, or understand "last Monday." If you need date arithmetic — adding months, finding the start of a week, working with time zones — you still need a library or the upcoming Temporal API. But if you already have two timestamps and just want to display the difference as human text, Intl.RelativeTimeFormat is the right tool.

Browser support

Intl.RelativeTimeFormat is Baseline 2020: Chrome 71 (2018), Firefox 65 (2019), Safari 14 (2020), Node.js 12. It's been in every major environment for years. No polyfill needed for any currently-supported browser.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

🧠 Test yourself

Think it clicked? Take the 9-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for formatDistanceToNow, fromNow(), or any home-grown "X minutes ago" function. If the logic is "compute a diff, format it as human text," replace it with Intl.RelativeTimeFormat and a unit-picking helper. You get correct pluralization, locale-aware phrasing, and natural-language output like "yesterday" and "tomorrow" — with no added dependency and no locale bundle to manage.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

You use `obj.hasOwnProperty(key)` to check property ownership. It can silently fail. `Object.hasOwn()` is the safe replacement.

Parsa Jiravand — Thu, 06 Aug 2026 08:44:20 +0000

Every JavaScript codebase has this pattern somewhere:

if (obj.hasOwnProperty(key)) {
  // ...
}

It's idiomatic, it's readable, and most of the time it works. But there are two specific situations where it silently fails — one throws, one returns wrong results — and they come up more often than you'd expect. Object.hasOwn() is the ES2022 fix.

How `hasOwnProperty` can go wrong

Case 1: null-prototype objects. Objects created with Object.create(null) have no prototype. That's actually why people reach for them — as pure dictionaries where no inherited key can ever accidentally collide with a user-supplied key. The catch: they don't inherit hasOwnProperty either.

const dict = Object.create(null);
dict.name = "parsa";

dict.hasOwnProperty("name"); // ❌ TypeError: dict.hasOwnProperty is not a function

This pattern is common in parsers, caches, and config objects. When you encounter one and call .hasOwnProperty() on it, you get a runtime error, not a boolean.

Case 2: shadowed method. Because hasOwnProperty is inherited from Object.prototype, any object can define its own hasOwnProperty property that overrides the inherited one. This is rarely malicious but it does happen with deserialized data or objects built from untrusted input:

const untrusted = {
  hasOwnProperty: () => true, // overrides the prototype method
  name: "parsa",
};

untrusted.hasOwnProperty("admin"); // ❌ true — completely wrong

The inherited method is gone, replaced by a local property that returns whatever it wants.

The pre-ES2022 workaround

The fix that predates Object.hasOwn() is verbose but correct:

Object.prototype.hasOwnProperty.call(obj, key);

This goes directly to Object.prototype for the real method, then calls it with obj as the receiver. It handles null-prototype objects (the method comes from the prototype explicitly, not from the object) and it can't be shadowed (you're not reading the method from the object at all).

This is also what ESLint's no-prototype-builtins rule has been pushing you toward since 2016. If you've seen that rule flag obj.hasOwnProperty(key) in a project and wondered why — this is the reason.

The problem is that Object.prototype.hasOwnProperty.call(obj, key) is 39 characters and easy to get wrong. It's the kind of code you copy-paste without fully understanding, which is exactly when bugs hide.

`Object.hasOwn()` — the clean version

Object.hasOwn(obj, key);

Same semantics as Object.prototype.hasOwnProperty.call(obj, key), but readable at a glance.

const dict = Object.create(null);
dict.name = "parsa";

Object.hasOwn(dict, "name");    // ✅ true
Object.hasOwn(dict, "admin");   // ✅ false

const untrusted = {
  hasOwnProperty: () => true,
  name: "parsa",
};

Object.hasOwn(untrusted, "admin"); // ✅ false — can't be shadowed
Object.hasOwn(untrusted, "name");  // ✅ true

Because Object.hasOwn is a static method on Object itself, there's nothing on the object being checked that can interfere with it.

Where this comes up in real code

The most common place you'll find this pattern is in loops over object keys:

for (const key in someObject) {
  if (Object.hasOwn(someObject, key)) {
    // skip inherited keys
  }
}

The for...in loop walks the entire prototype chain. When you only care about own properties, you need to filter. Object.hasOwn() is the right tool.

It also turns up in validation logic, where you're checking that a required field actually exists on an incoming payload rather than on the payload's prototype:

function validate(payload) {
  const required = ["id", "name", "email"];
  const missing = required.filter(field => !Object.hasOwn(payload, field));
  if (missing.length) throw new Error(`Missing: ${missing.join(", ")}`);
}

And in generic utility functions that need to handle arbitrary objects, including null-prototype ones:

function pick(obj, keys) {
  return Object.fromEntries(
    keys
      .filter(k => Object.hasOwn(obj, k))
      .map(k => [k, obj[k]])
  );
}

TypeScript note

TypeScript accepts Object.hasOwn() and narrows the type in the same contexts where in narrows:

function process(config: unknown) {
  if (typeof config === "object" && config !== null && Object.hasOwn(config, "timeout")) {
    // TypeScript knows config has a "timeout" property here
    console.log((config as { timeout: number }).timeout);
  }
}

It doesn't give you automatic narrowing of the property's type (that's a separate constraint), but it does narrow the object to non-null.

Browser support

Object.hasOwn() is Baseline 2022: Chrome 93, Firefox 92, Safari 15.4, Node.js 16.9. It's been in every major runtime for nearly four years. There's no polyfill concern for greenfield projects, and even the Object.prototype.hasOwnProperty.call() workaround works identically in older environments if you need it.

ESLint's no-prototype-builtins rule (enabled by eslint:recommended) will flag any direct .hasOwnProperty() call on an object and suggest exactly this migration.

🎮 Try it yourself

▶️ Open the interactive playground →

Runs right in your browser — poke at it and watch the concept react live.

🧠 Test yourself

Think it clicked? Take the 8-question quiz →

Instant feedback, a hint on every question, and an explanation for each answer — right or wrong.

The takeaway

Search your codebase for .hasOwnProperty(. Every match is a candidate for Object.hasOwn(). The swap is mechanical — obj.hasOwnProperty(key) becomes Object.hasOwn(obj, key) — but the result is immune to the two silent failure modes that the old pattern can't handle. If you're writing a library, a plugin system, or anything that accepts external objects as input, this is the version you want.

Thanks for reading! Let's stay connected:

⭐ GitHub — follow me and star the projects: github.com/parsajiravand
💬 Discord — join the frontend best-practices community: discord.gg/d9KRhuAwQ
📸 Instagram — frontend best practices, daily: @bestpractice___
💼 LinkedIn — linkedin.com/in/parsa-jiravand
✉️ Email (work & contract inquiries): bestpractice2026@gmail.com

DEV Community: Parsa Jiravand

Five tabs open, one refresh token — the race nobody noticed

Why one user becomes four requests

The fix that looks right and isn't

🎮 Try it yourself

The actual fix: navigator.locks

Where else this shows up

What this isn't

Browser support

🧠 Test yourself

The takeaway

You copy and reverse the array to find the last match. `findLast()` searches from the end directly.

How findLast() works

findLastIndex() for when you need the position

🎮 Try it yourself

Real-world patterns

TypeScript types

Browser support

🧠 Test yourself

The takeaway

Your `fetch()` in `beforeunload` is being silently dropped. Use `navigator.sendBeacon()`.

Why fetch in beforeunload fails

The API

Why visibilitychange instead of beforeunload

What you can send

The keepalive fetch alternative

Browser support

🎮 Try it yourself

🧠 Test yourself

The takeaway

Search your codebase for storage event listeners paired with a localStorage.setItem that immediately gets removed. That pattern is cross-tab messaging through a storage side-channel — exactly what BroadcastChannel exists to replace

Stop using the localStorage hack to sync browser tabs. BroadcastChannel does it natively.

You're blocking touchmove events to contain scroll. `overscroll-behavior` does it natively.

The property

What it replaces

Pull-to-refresh and browser navigation

The shorthand and axis properties

Browser support

🎮 Try it yourself

🧠 Test yourself

The takeaway

You're polling setInterval to detect DOM changes. `MutationObserver` fires when they happen.

The API

What it replaces

Real-world use cases

Batching and performance

Browser support

🎮 Try it yourself

🧠 Test yourself

The takeaway

You're importing pako to gzip data. `CompressionStream` does it natively.

The API

Replacing pako

Real-world patterns

Format reference

Performance

Node.js

Browser support

🎮 Try it yourself

🧠 Test yourself

The takeaway

Stop using the localStorage hack to sync browser tabs. BroadcastChannel does it natively.

The API

What the localStorage approach actually looks like

Real-world use cases

What you can send

Scope and limits

Browser support

🎮 Try it yourself

🧠 Test yourself

The takeaway

You built your modal with a `` and a focus trap library. The native `` does all of that.

The baseline API

showModal() vs show()

Styling the backdrop

Animating open and close

Handling backdrop clicks to close

Return value from close()

The <form method="dialog"> shortcut

Browser support

The actual fix: `navigator.locks`

How `findLast()` works

`findLastIndex()` for when you need the position

Why `fetch` in `beforeunload` fails

Why `visibilitychange` instead of `beforeunload`

The `keepalive` fetch alternative

You built your modal with a `
` and a focus trap library. The native `` does all of that.

`showModal()` vs `show()`

Return value from `close()`

The `<form method="dialog">` shortcut

The `numeric: 'auto'` option

How `hasOwnProperty` can go wrong

`Object.hasOwn()` — the clean version