Web technologies have taken a long time to progress.
A lot of the standards we see today are because browsers decided to implement new features.
HTML5 is now just supposed to be HTML. It is supposed to be a living standard.
Pamela needs an HTML app that helps choose her hair color.
Cookies are used for all types of tracking, but they have issues with security, user trust (can be disabled), performance and size.
In the HTML spec, they considered the issues and came up with the following solutions.
- Key / value pairs – hash table
- Persistent on page reloads
- Avoids HTTP overhead of cookies
- Great for storing user preferences (domain-specific, but it doesn’t matter where the script comes from)
Same as localStorage but…
- Lasts as long as browser is open (session-based)
- Opening page in new window or tab starts new session
- Great for sensitive data (e.g. banking sessions)
Why use a library for localStorage?
- Support check
- Specific use cases (Forms, expiration, etc)
- Browser quirks (modern browser quirks, especially with mobile browsers)
Dangers of using localStorage are that localStorage access is synchronous and
- JSON.parse/JSON.stringify takes CPU time
- Don’t serialize unnecessarily
- Don’t use excessive keys
- Don’t do excessive gets/sets
- Don’t block the UI
Don’t serialize unnecessarily
- Do use strings where possible – jsperf: Primitives vs. Strings jsperf: Optional use of JSON stringify
Don’t use excessive keys
- Do combine keys commonly accessed together – jsperf: 1 long key vs. multiple short keys
Don’t do excessive gets/sets
- Do cache data in local memory or the DOM, and only get/set on window load/unload – Exercise Explorer: Caching in local memory, Hearty Extension: Caching in the DOM
Don’t block the UI
- Do defer using localStorage until onload – Not Blocking the UI in Tight JS Loops
- Do use setTimeout to defer localStorage access – Nicholas Zakas: Responsive Interfaces
- Do throttle or debounce to avoid repetitive gets/sets – Blog Post: 2 LocalStorage Tips, jQuery Throttle/Debounce Plugin
WORSE: A dysfunctional site
- Don’t assume localStorage works or will always work.
- Don’t use key names that collide.
- Object based data store
- In-order retrieval by index or key
- Asynchronous or synchronous API
IndexedDB: Why use a library?
- Not the simplest API.
- Many fundamental differences across browser versions.
- Not supported in all browsers, fallbacks needed.
Storage library: Lawnchair
- Includes serialization, fallbacks (window.name, userData, gears, indexedDB)
- Optional plugins for aggregation, pagination, and queries.
Other IndexedDB Libraries
- IndexedDB Polyfill: Falls back to WebSQL.
- persistence.js: Falls back to localStorage, memory, mySQL on Node, AppEngine
- YDN-DB: Falls back to localStorage, webSQL.
There are many File APIs.
- Reading and manipulating:
File / Blob, FileList, FileReader
FileList & FileReader – See: MDN: Using files from web apps
- Creating and writing:
BlobBuilder, FileWriter, FileSaver
FileWriter – HTML5 Rocks: Exploring the file system API
- Directories and System:
Probably going away or are going to change because IndexDB can do the same things.
SIDE NOTE: Marquee is coming back in CSS.
Which to Use?
- What kind of data can you store?
- How much data can you store? (WebStore support test, Chrome Quota Management API)
- How can you query data? (IndexedDB: Using an Index)
- How well does it perform? (LocalStorage read performance, localStorage performance)
- What browsers does it work in? (caniuse.com: Web Storage, IndexedDB, FileSystem, Mozilla on File Systems API)
- Remember user data
- Retain application state
- Remember form input
- Improve performance
- Help the app work offline