Web Locks API

Original Article ↗ Hacker News Discussion ↗

Browsers’ Web Locks API, which lets scripts coordinate access to shared resources across tabs and workers on the same origin, is drawing attention for concrete use cases like safely refreshing OAuth tokens, serializing IndexedDB writes, or sharing a single WebSocket connection. Commenters debate its ergonomics versus lower-level Atomics and SharedArrayBuffer, how to express explicit acquire/release patterns in async JavaScript, and whether giving web developers locking primitives will encourage deadlocks or misuse. There is also discussion of security constraints (HTTPS-only), performance concerns, and how features like this interact with multi-tab user experiences and SPA design.

Performance & benchmarking

  • One user asks for performance benchmarks, especially vs Rust’s Tokio mutex in WASM.
  • Others suggest writing custom benchmarks and recommend a JS microbenchmarking tool (mitata).
  • Point made that many existing uses aren’t time‑critical, so users may not have measured performance in detail.

API design & ergonomics

  • Several comments criticize the callback-based navigator.locks.request(name, async (lock) => ...) and the lack of an explicit release(); they find “hold until callback resolves” awkward when you want to keep a lock across wider scopes.
  • Others defend the design as safer in a language without RAII, reducing the chance of forgetting to release.
  • Multiple patterns are proposed to emulate acquire() / release() via promises and wrappers; some find these clumsy.
  • Debate over hypothetical using / RAII-style syntax: some view it as clearer, others find RAII “too clever” and prefer explicit blocks or the existing callback.

Relation to Atomics and single-threaded JS

  • Some argue the existing Atomics + SharedArrayBuffer APIs already cover low-level synchronization.
  • Counterpoint: Web Locks are higher-level, origin-wide, and coordinate across tabs/workers without manual postMessage or shared memory, which is less error-prone.

Use cases discussed

  • Coordinating OAuth refresh tokens across multiple SPA tabs so a one-time refresh token isn’t used twice.
  • Guarding IndexedDB writes where transaction isolation is seen as insufficient.
  • Sharing a single WebSocket/SSE connection via a worker.
  • Preventing multiple crypto-mining tabs from competing for CPU.
  • Preventing Edge “sleeping tabs” by holding a lock.

Locks vs leases and deadlocks

  • One view: leases (locks with time limits) are preferable to avoid stale locks.
  • Others argue timeouts introduce non-determinism and unsafe “stealing” of locks; better to detect and handle long waits explicitly.
  • Concern raised that giving JS developers locks may increase deadlocks; response notes these locks don’t block threads, just leave promises unresolved, though affected app code is still broken.

Security, scope & naming

  • Locks are origin-scoped and require secure contexts; commenters link this to modern “secure by default” design and to preventing MITM from abusing same-origin APIs.
  • Worry about DoS if common lock names become well-known and pages intentionally hold them.
  • Some think global lock names are risky; others say global naming matches the “super-global resource” concept.
  • Questions about behavior across separate browsers or private sessions remain unanswered in the thread.