Browser Storage and Its Limits

Why this matters

An order list that vanishes on reload is a demo; one that persists is a tool the bakery can actually use on one counter tablet. Browser storage gives that persistence with zero accounts and zero servers. Its limits matter equally: promising multi-device sync from browser storage is the fastest way to betray a user's trust.

Concepts

The pattern: load on start, save on change. When the page opens, read the saved entries (or start with an empty list). Every successful submit appends and saves; every delete re-saves. List, save and load are three small functions with one shared key name. Lesson M05L17's echo proves the entry; storage proves it survives.

The three limits, stated to users. Stored data lives in this browser on this device; it does not follow the user to a phone or another computer. Browsers and cleaners can erase it; it is convenient memory, not a vault. Capacity is small (a few megabytes); order lists fit, photo archives do not. Your page should say this in one line near the list ("saved in this browser on this device") so expectations match reality.

Corrupt and missing data. Stored text can be edited, truncated or from an older version. Load defensively: missing key means empty list, unparseable means empty list plus a note, wrong shape means the entry is skipped, never a crash. An app that greets damaged storage with a blank stare teaches visitors to fear reloads.

Never store secrets or other people's sensitive data. Passwords, tokens, customer phone lists and health notes stay out of browser storage exactly as they stay out of prompts (M01L4). Practice data is invented; real personal data needs real infrastructure with real consent, which is beyond this course's scope by design.

Worked example

Bakery order list: entries render from storage on load; submit validates, appends, saves, re-renders; delete removes and re-saves. Reload mid-day: orders stand. Open on a second device: list is empty, correctly, because the page said "saved in this browser". Corrupt the stored text once on purpose: page loads an empty list with a note instead of dying. Four behaviors, three functions, one honest line of copy.

Expected result: your list persisting across reloads with the limits line visible and corrupt-data handling verified once.

The common wrong move

Treating storage as a database: storing everything forever with no delete, then wondering why the page slows and visitors cannot remove mistakes. Lists need delete plus re-save from day one.

Lab and next step

Lab A15 wires the persistent order list with delete and the limits line. Next, lesson 20 asks the backend question: does your project need an API or server at all, and how to decide honestly.