All bites
The whole library, newest first. Filter by what you are here for, or pick a topic if you already know.
8668 bites
Page 261
Canvas 2D Context: The API for Drawing on the Web
The Canvas 2D Context is your digital paintbrush and ruler for drawing on a web page. You get this object from a <canvas> element to draw shapes, text, and images for data visualizations or simple games. The key footgun: it's a state machine.
HTMLMediaElement: The Remote Control for Browser Media
HTMLMediaElement is the shared "remote control" API for <audio> and <video> tags, letting you programmatically play, pause, and seek. Use it for custom players or syncing animations. Footgun: Browsers often block autoplay, so never assume it will work.
Web Push API: Engage Users When Your App is Closed
The Web Push API lets servers send messages to users even when your site is closed. A service worker receives these pushes, making it ideal for notifications. The main footgun: the subscription endpoint is a secret key that must be protected.
Background Sync API: Send Data When the Network Returns
The Background Sync API lets your app defer work until the network is back. You register a task, and the browser wakes your service worker to run it when connectivity returns. Use it to reliably send data submitted while offline, like form posts or chat.
Transferable Objects: Zero-Copy Data for Web Workers
Transferable Objects move resource ownership between contexts, like threads, instead of copying data. This enables fast, 'zero-copy' transfers for large memory blocks. Use it with postMessage() to send an ArrayBuffer to a Web Worker.
Shared Workers: One Background Script for Multiple Tabs
A SharedWorker is a single background script shared across multiple tabs or windows from the same origin. Use it to manage a single WebSocket connection or sync state between pages. The footgun: each tab must call port.start() on its own message port.
Intercept Network Requests with the `fetch` Event
The fetch event turns your Service Worker into a programmable network proxy. Use it to intercept outgoing requests to serve assets from a cache for offline support or to synthesize custom responses.
The Service Worker Lifecycle: Register, Install, Activate
A service worker is a background proxy that lets your app work offline. Its lifecycle—register, install, activate—governs how it takes control of pages. The biggest footgun: a new worker waits for old clients to close before activating, delaying updates.
Service Worker Registration: Claiming Your Control Scope
Registering a service worker is like assigning a security guard (your script) to a specific area (the scope) of your site for offline support. The footgun: by default, a worker can only control its own directory, not the whole site.
Web Workers: Keep Your UI Responsive During Heavy Tasks
A Web Worker is like a background helper, running heavy JavaScript tasks in a separate thread so your UI never freezes. Use it for complex calculations or data fetching. The main footgun: workers cannot directly manipulate the DOM.
The `popstate` Event: Handling Browser History Navigation
The popstate event lets your app react to browser back/forward clicks. It's key for SPAs to update views without a full reload. The main footgun: the event fires before the document is fully updated, so your handler might read a stale DOM.
Manipulate Browser History with pushState and replaceState
Make a single-page app feel like a multi-page site. pushState changes the URL without a full page reload, creating a new browser history entry. This is essential for SPAs to enable shareable links and a working back button.
Cache API: Manual Control Over Network Responses
The Cache API is a key-value store for network requests you control directly, unlike the browser's automatic HTTP cache. Use it in service workers for offline support or to pre-cache app assets.
IndexedDB Versioning: The 'upgradeneeded' Gatekeeper
IndexedDB uses a version number to manage schema changes. Incrementing the version in indexedDB.open() triggers a special upgradeneeded event, which is the only context where you can create or modify object stores and indexes.
IndexedDB Cursors: Iterate Large Datasets Efficiently
An IndexedDB cursor is a pointer for walking through records one by one, avoiding loading a whole dataset into memory. Use it to efficiently process large browser databases.
IndexedDB Indexes: Fast Queries in the Browser
An IndexedDB index is like a book's index, letting you quickly find records by a specific property without scanning the entire dataset. It's essential for fast queries on non-primary keys, like looking up a user by email.
Choosing the Right Client-Side Storage
Client-side storage turns the browser into a mini-database for faster loads and offline access. It's used for remembering user preferences or caching assets.
IndexedDB Transactions: The Gatekeepers of Data
An IndexedDB transaction is a short-lived container for all database operations, ensuring data integrity. Use it for any read or write. The main footgun: transactions auto-commit if idle, so you must queue all requests synchronously without waiting.
IndexedDB Object Stores: Your Browser's NoSQL Table
An IndexedDB Object Store is like a NoSQL table in your browser, holding JavaScript objects by key. Use it for offline data like to-do lists or cached API responses. The main footgun: you can only create stores during a database version upgrade.
IndexedDB: A NoSQL Database in Your Browser
Think of IndexedDB as a NoSQL database in the browser, built for large structured data that localStorage can't handle. It's ideal for offline apps or caching large assets. The footgun: browsers can evict your data, so it's not permanent storage.