- Both indexedDB and local storage are key value stores. What is the
advantage of having two key/value stores? - indexedDB is asynchronous, but joins (the most time-consuming thing)
are manual. They appear to run in the same thread as the async calls
were made. How will this not block the UI? - indexedDB allows a larger store. Why not increase the size of the
HTML5 store? - I’m scratching my head. What is the point of indexedDB?
Both indexedDB and local storage are key value stores. What is the advantage of
Share
IndexedDB is not a key-value store in the same way that Local Storage is. Local storage just stores strings, so to put an object in local storage the usual approach is to JSON.stringify it:
This is fine for finding the object with key
uniq, but the only way to get the properties of myObject back out of local storage is to JSON.parse the object and examine it:This is fine if you only have one, or a few objects, in local storage. But imagine you have a thousand objects, all of which have a property
b, and you want to do something just with those ones whereb==2. With local storage you’ll have to loop through the entire store and checkbon each item, which is a lot of wasted processing.With IndexedDB you can store stuff other than strings in the value: “This includes simple types such as DOMString and Date as well as Object and Array instances.” Not only that, but you can create indexes on properties of the objects that you stored in the value. So with IndexedDb you can put those same thousand objects in it but create an index on the
bproperty and use that to just retrieve the objects whereb==2without the overhead of scanning every object in the store.At least that’s the idea. The IndexedDB API isn’t very intuitive.
Asynchronous is not the same thing as multi-threaded, JavaScript, as a rule, is not multi-threaded. Any heavy processing you do in JS will block the UI, if you want to minimize blocking the UI try Web Workers.
Because, without proper indexing, it would get increasingly slower the larger it got.