Using a JSON object vs. localStorage/sessionStorage/IndexedDB/WebSQL/etc.?

Question

I've got a web app which gets a couple dozen items at boot. All these items are JSON and are smaller then 1kb.

Now there are a number of storage options as seen in the Question.

I was thinking of just storing these objects inside a variable in the browser JS. I don't really see why I would want to use any of these browser storages?

So what would be reasons to use any of the browser-based storage instead of a variable inside JS. Could be that from a certain data size it is preferable to use browser storage, e.g. from 100kb onwards it's better to not use a JS variable.

var myModel = {}

NOTE

Every time the user enters the app he will get fresh content from the server. The content is too realtime for caching. `

Answer 1

localStorage , globalStorage and sessionStorage:

These features are ready in browsers that have implemented the "Web Storage", they all refer to a kind of HashMap, a map between string keys and string values. but the life is different. once the active page is closed sessionStorage would be cleaned but the localStorage is permanent.(MDN DOM Storage guide)

• There is a point about globalStorage, which is its being obsolete since Gecko 1.9.1 (Firefox 3.5) and unsupported since Gecko 13 (Firefox 13), since then we should use localStorage. the difference between these 2 was just the HTML5 scope support(scheme + hostname + non-standard port).

These could be useful for you to:

-Share your objects between your different pages, in your site.

-Offline programming.

-Caching large object

-Or whenever you need to a local persistent storage.

---

IndexedDB:

IndexedDB is useful for applications that store a large amount of data (for example, a catalog of DVDs in a lending library) and applications that don't need persistent internet connectivity to work (for example, mail clients, to-do lists, and notepads)

based on this quote from MDN you can easily find your answer out, regarding using IndexedDB, if you don't know whether IndexedDB is useful for you or not, just answer these questions:

Do you store a large amount of data on client? if yes, so consider using it.

Does your app need to be offline enabled? if yes, so consider using IndexedDB.

Does your app need to a persistent internet connectivity? If yes, it stays still an option, based on the other factors.

---

So other than working offline as far as you don't need it, I guess, because as you said:

The content is too realtime for caching.

These have some features like sharing objects, and managing large amount of data, which you should be the one to decide.

Answer 2

localStorage and sessionStorage are solving a caching problem; think of them as cookies. You've said you don't want caching, so you can ignore them.

JavaScript objects behave basically like O(1) lookup tables (see How is a JavaScript hash map implemented?, and make sure you read both the top two answers, as both have something useful to say), and there is no maximum memory limit that I am aware of, or a point where another solution becomes a better choice

The only reason I can think of that you should bother with the extra step of inserting the data in an IndexedDB is if you need O(1) lookups on a field that is not the object key you are using.