How is indexedDB conceptually different from HTML5 local storage?

Question

1. Both indexedDB and local storage are key value stores. What is the advantage of having two key/value stores?
2. 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?
3. indexedDB allows a larger store. Why not increase the size of the HTML5 store?
4. I'm scratching my head. What is the point of indexedDB?

Answer 1

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:

myObject = {a: 1, b: 2, c: 3}; localStorage.setItem("uniq", JSON.stringify(myObject)); 

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:

var myStorageObject = JSON.parse(localStorage.getItem("uniq")); window.alert(myStorageObject.b); 

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 where b==2. With local storage you'll have to loop through the entire store and check b on 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 b property and use that to just retrieve the objects where b==2 without the overhead of scanning every object in the store.

At least that's the idea. The IndexedDB API isn't very intuitive.

They appear to run in the same thread as the async calls were made. How will this not block the UI?

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.

indexedDB allows a larger store. Why not increase the size of the HTML5 store?

Because, without proper indexing, it would get increasingly slower the larger it got.

Answer 2

I came across this good article discussing about localstorage vs indexeddb and other possible options.

(all the below values are in milliseconds)

https://nolanlawson.com/2015/09/29/indexeddb-websql-localstorage-what-blocks-the-dom/

To summarize from the article (entirely author's views),

1. In all three of Chrome, Firefox, and Edge, LocalStorage fully blocks the DOM while you’re writing data 2. The blocking is a lot more noticeable than with in-memory, since the browser has to actually flush to disk.
2. Not surprisingly, since any synchronous code is blocking, in-memory operations are also blocking. The DOM blocks during long-running inserts, but unless you’re dealing with a lot of data, you’re unlikely to notice, because in-memory operations are really fast.

3. In both Firefox and Chrome, IndexedDB is slower than LocalStorage for basic key-value insertions, and it still blocks the DOM. In Chrome, it’s also slower than WebSQL, which does blocks the DOM, but not nearly as much. Only in Edge and Safari does IndexedDB manage to run in the background without interrupting the UI, and aggravatingly, those are the two browsers that only partially implement the IndexedDB spec.

4. IndexedDB works swimmingly well in a web worker, where it runs at roughly the same speed but without blocking the DOM. The only exception is Safari, which doesn’t support IndexedDB inside a worker, but still it doesnt block the UI.

5. localmemory is ideal if data is simple and minimal