I feel like using localStorage to cache stuff that could be handled by http caching is probably a mistake. I'm in the process of caching a bunch of our application in localStorage because a quirk in our client-side architecture means I need to know if something is cached before making an asynch request for content, (which you can't do with the standard http cache). That means I'm reinventing a cache invalidation scheme -- which we all know is hard, right? Plus the space allocated for localStorage is pretty small, so I have to have a way to prioritize the cache and bump out old stuff to make way for new. It's all rather convoluted.<p>IMHO, edge cases aside, most people shouldn't do this.
Be aware that localStorage is synchronous and browsers currently load the entire localStorage for a domain into memory to satisfy the first request. Shouldn't be a problem here but something to be aware of.
Hey guys - I wrote this. Just to point out: this project is really just a proof of concept. I haven't personally seen any figures to suggest that localStorage caching is more optimal than standard browser caching, but once these benchmarks are available (hoping to get them up on jsPerf), they'll be posted to the same page.
Please don't use local storage. It's synchronous and will hang the entire browser or tab while the script is loading: <a href="http://paul.kinlan.me/we-need-to-kill-off-the-localstorage-api" rel="nofollow">http://paul.kinlan.me/we-need-to-kill-off-the-localstorage-a...</a>