Hacker News Reader

Comment by ggregoire | Hacker News Reader

What are the differences with localForage (or similar solutions)? The fallback to cookies if no localStorage?

https://github.com/localForage/localForage

localForage only uses a single datastore. E.g. LocalStorage or SessionStorage or IndexedDB. Thus, stored data is lost forever if the browser unceremoniously purges that datastore due to storage pressure.

https://developers.google.com/web/fundamentals/instant-and-o...

IronDB redundantly stores data in multiple datastores -- cookies, IndexedDB, LocalStorage, and SessionStorage -- and self-heals if the data in any thereof is deleted or corrupted. For example, stored data is safeguarded in the event the user clears their cookies or IndexedDB is purged due to storage pressure.

tl;dr: IronDB is resilient in the face of data deletion. localForage isn't.

Thank you for the great answer. :)

It's kind of ridiculous that a library needs to exist to guard against this browser behavior, although I empathize with the browser vendors' argument, which is that browser storage should essentially be used for caching and that browsers should somewhat aggressively defend against disk space consumption that most users don't even know about.

It would be nice to have an in-between where if a user authorized an app to permanently consume up to X amount of disk space the browser would allow it. But pulling off that user interaction well (i.e., getting the user to make an informed decision rather than blindly clicking yes or no) seems quite hard.

Reply on news.ycombinator.com