3 ms·
I’ve used it. There isn’t much to discuss honestly. It’s a bit faster in my experience than local storage is, and it can handle more than just string types nati
by no_wizard 7y ago
I’ve used it. There isn’t much to discuss honestly. It’s a bit faster in my experience than local storage is, and it can handle more than just string types natively (like ArrayBuffers).
It also has a concept of versioning that’s really clean.
However, all your data is dead if you ever clear your cache or migrate machines. You should really consider that as a huge downside. Databases have an important use case and you don’t have to just use a SQL solution either.
Something like CouchDB would work fine if you only want some Storage. PouchDB + CouchDB is a good combo That would give you some nice abstractions here without having to put all the onerous on the end user to have some continuity in their data
Also see https://developers.google.com/web/fundamentals/instant-and-offline/web-storage/indexeddb-best-practices https://developers.google.com/web/fundamentals/instant-and-o...
- deleted 7y ago[deleted]
- throwaway9103 7y agoThank you for your input. I recall reading somewhere before about a chrome update that (accidentally?) wiped out data stored through indexeddb. Have you heard or experienced anything like this? That case is more concerning to me than when a user clears their own data, because any copies of the data across many machines would all be wiped out around the same time.
- no_wizard 7y agoI’ve experienced updates in every browser go awry in this way one way or another. It’s really built to be a source of ephemeral storage not the sole provider for an application, that’s just the reality of it. There’s no continuity guarantees.
- throwaway15392 7y agoI see... that’s not good