Frontend & browser·topic 12 of 13
Storage and platform APIs
The browser's own standard library: four ways to keep data on the device and a set of observers that answer questions a scroll handler used to answer badly. Picking the right one is usually a question about lifetime.
Read in order · tick what you already know
- 01
the value went out with every single request to that domain, whether it was needed or not.
Cookie
- 02
you saved the preference and it was still there a week later, on that browser only.
localStorage
- 03
the value survived a refresh and vanished when the tab was closed, and the other tab never saw it.
sessionStorage
- 04
you needed to keep megabytes of structured data on the device, so key-value strings were not enough.
IndexedDB
- 05
the cached data disappeared on its own because the device was low on space.
Storage quota
- 06
a script you are not running sits between the page and the network and answers requests itself.
Service worker
- 07
you stored whole request and response pairs so the service worker could answer them without the network.
Cache Storage
- 08
the app opened and worked on a train with no signal, then synced when the connection came back.
Offline-first
- 09
you stopped the polling when the tab went to the background and started it again when it came back.
Page visibility
- 10
you found out when the element scrolled into view without running any code on scroll.
IntersectionObserver
- 11
you reacted to the element changing size instead of listening for the window resizing.
ResizeObserver
- 12
you needed to know when someone else's script changed the DOM, so you watched the subtree.
MutationObserver
- 13
your page's stylesheet had no effect inside the widget because its DOM was in a separate tree.
Shadow DOM
- 14
you defined a tag with a dash in it and used it in HTML like any built-in element.
Custom element
- 15
you checked whether the API existed rather than checking which browser you were in.
Feature detection