Google recently announced its intent to ship two new WICG proposals in a future version of Chrome. KV Storage (Key-Value storage) attempts to bring the convenience of LocalStorage but with better performance. The intent is to deliver this as the first example of a built-in module, leveraging the import maps proposal.
The JavaScript ecosystem has had a somewhat fractured approach to storing and caching data locally. As explained by Philip Walton, a software engineer at Google working on the Web Platform,
Browser vendors and web performance experts have been saying for the better part of the last decade that localStorage is slow, and web developers should stop using it. To be fair, the people saying this are not wrong. localStorage is a synchronous API that blocks the main thread, and any time you access it you potentially prevent your page from being interactive. The problem is the localStorage API is just so temptingly simple, and the only asynchronous alternative to localStorage is IndexedDB, which (let’s face it) is not known for its ease of use or welcoming API.
The Web Incubator CG (WICG) recently promoted KV Storage to be part of the W3C IndexedDB specification. KV Storage similar to localStorage in utility, but more modern and gets layered on top of IndexedDB. The specification mandates that it gets implemented by browser vendors as a built-in module, and use IndexedDB as its backing store.
Example usage of the KV Storage API as provided by the specification:
import { storage } from "std:kv-storage"; // specifier prefix not final
(async () => {
await storage.set("mycat", "Tom");
console.assert(await storage.get("mycat") === "Tom");
for await (const [key, value] of storage.entries()) {
console.log(key, value);
}
// Logs "mycat", "Tom"
await storage.delete("mycat");
console.assert(await storage.get("mycat") === undefined);
})();
A KV Storage polyfill exists for browsers which support IndexedDB.
The KV Storage module gets resolved as defined in the JavaScript Standard Library initiative and its support for import maps.
Import maps are not a new concept, and were part of earlier JavaScript module systems, such as AMD and module systems in other programming languages. Their inclusion with standard ES Modules is new. This import maps proposal provides control over the URLs getting fetched by JavaScript import statements and import() expressions, and allows the mapping to get reused in non-import contexts. Import maps allow for simplified import statements, fallback module resolutions, polyfills for built-in modules, and sharing of contexts between fetch, image and link tags, and more.
Successful implementation of these two new highly anticipated features should significantly improve the process by which features get added to future versions of JavaScript and to provide additional convenient web APIs. Import maps and built-in modules strive to solve a missing piece of the extensible web manifesto.
Developers looking to experiment today with KV Storage may leverage the polyfill, or install a Chrome Dev or Canary version of Chrome 74. Before the mainstream release of these features, developers can make these features available to all Chrome 74+ users for specific domains by registering interest in the KV Storage origin trial.