localStorage and indexedDB are used for offline storage of data in HTML5. What are their key differences and which one is preferable in what situations?
How is localStorage different from indexedDB?
database;html5;offline
On the surface the two technologies may seem directly comparable, however if you spend some time with them you'll soon realize they are not. They were designed to achieve a similar goal, client side storage, but they approach the task at hand from significantly different perspectives and work best with different amounts of data.localStorage, or more accurately DOM Storage, was designed for smaller amounts of data. It's essentially a strings only key - value storage, with a simplistic synchronous API. That last part is key. Although there's nothing in the specification that prohibits an asynchronous DOM Storage, currently all implementations are synchronous (i.e. blocking requests). Even if you didn't mind using a naive key - value storage for larger amounts of data, your clients will mind waiting forever for your application to load.indexedDB, on the other hand, was designed to work with significantly larger amounts of data. First, in theory, it provides both a synchronous and an asynchronous API. In practice, however, all current implementations are asynchronous, and requests will not block the user interface from loading. Additionally, indexedDB, as the name reveals, provides indexes. You can run rudimentary queries on your database and fetch records by looking up theirs keys in specific key ranges. indexedDB also supports transactions, and provides simple types (e.g. Date).At this point, indexedDB might seem the superior solution for every situation ever. However, there's a penalty for all its features: Compared to DOM Storage, its API is quite complicated. indexedDB assumes a general familiarity with database concepts, whereas with DOM Storage you can jump right in. If you have ever worked with cookies, you won't have an issue working with DOM Storage. Also, in general you'll need to write more code in indexedDB to achieve exactly the same result as in DOM Storage (and more code == more bugs). Furthermore, emulating DOM Storage for browsers that don't support it is relatively straightforward. With indexedDB, the task wouldn't be worth its time. Lastly, before you dive into indexedDB, you should first take a look at the Quota API.At the end of the day, it's completely up to you if you use DOM Storage or indexedDB, or both, in your application. A good use case for DOM Storage would be to store simple session data, for example a user's name, and save you some requests to your actual database. indexedDB's additional features, on the other hand, could help you store all the data you need for your application to work offline. 