localStorage
is…
- Good! It’s an incredibly easy API to use.
localStorage.setItem('name', 'Chris'); let name = localStorage.getItem('name');
localStorage
is a synchronous API that blocks the main thread, and any time you access it you potentially prevent your page from being interactive.
Chrome has an idea (here’s the proposal) for reinventing it. Ultimately the API is even simpler:
import { storage } from 'std:kv-storage';
storage.set('name', 'Chris');
storage.get('name');
But! It’s async, so I can use await
before I do those things without blocking anything. This demo will work in Chrome Canary right now:
See the Pen
eXadrq by Chris Coyier (@chriscoyier)
on CodePen.
What in all heck is up with this line?
import { storage } from 'std:kv-storage';
They are calling it a “built-in module.” In other words, something you can import but it makes no network request because it’s built into the browser. Pretty interesting approach.
Philip continues:
Not exposing built-in modules globally has a lot of advantages: they won’t add any overhead to starting up a new JavaScript runtime context (e.g. a new tab, worker, or service worker), and they won’t consume any memory or CPU unless they’re actually imported. Furthermore, they don’t run the risk of naming collisions with other variables defined in your code.
This is built on top of indexedDB, so if you’re playing with it and need to clear the values or whatever, you do it there (DevTools > Application > Storage > IndexedDB). It’ll be fascinating to see if this catches on and whether new JavaScript features are shipped as built-in modules. I have no sense of whether other browsers think this is a good idea or not.
So localStorage makes no network request… so unless your computer is extremely slow, would you even notice the delay?
And since the justification for localStorage being a problem is from 2012, here’s some other info from 2012 that seems to refute it. Wonder what the benchmarks would say now?
https://www.webdirections.org/blog/localstorage-perhaps-not-so-harmful/
How it will behave on IOS incognito?
(not to fall into the same trap as LocalStorage: https://stackoverflow.com/questions/14555347/html5-localstorage-error-with-safari-quota-exceeded-err-dom-exception-22-an)
So here’s a big problem with localStorage that drives me absolutely nuts: Many, many developers access it without a try/catch. This happens all over the place, often in frameworks and polyfills as well. It needs to stop.
I don’t know if this is strictly a Firefox thing, but Firefox will choke with a security error if you try to access localStorage or indexedDB on a site that isn’t allowed to use cookies. For the ultra security-conscious who only whitelist cookie domains and leave the rest disabled, this breaks a lot of sites. Most such sites will fail to render at all because the security error interrupts the loading of other vital components.
The moral: Never, ever try to access localStorage, sessionStorage, or indexedDB without a try/catch. The same applies to any future advances that might come around. Always wrap.
does also not work in canary:
Error:
Mixed Content: The page at ‘https://css-tricks.com/’ was loaded over HTTPS, but requested an insecure script ‘std:kv-storage’. This request has been blocked; the content must be served over HTTPS.
how to solve this?