All you need to know about client side data storage

There was a time when persisting data for a particular client either means uploading something to the server, or storing it to a server side session variable; or at max saving it to cookie and taking the overhead of transferring continuously in each http request.
But with time, the greed of making better user experience helped the web development world to think of some completely browser based or client side storage systems.

Let’s talk about the history

The journey of client side data storing actually starts from the late childhood of Internet Explorer; when Microsoft engineers included DHTML behaviors in it. One of these behaviors was userData, which allows web pages to store up to 64 KB of data per domain, in a hierarchical XML-based structure.

The second runner in this relay race was introduced by Adobe Inc. in 2002. Flash storage allows flash objects to store up to 100 KB of data per domain.

After that, in 2007 Google came up with “Gears”, an open source browser plugin, which provides an API to an embedded SQL database based on SQLite with some other features. Afterwards Google tried to push all of the Gears capabilities into web standards like HTML5, and eventually Google Gears was stopped.

To avoid all these chaos, Web Hypertext Application Technology Working Group (WHATWG) came up with a well-structured client-side storage solution, which is part of the HTML5 specifications approved by W3C. As a result sessionStorage and localStorage has been introduced to almost all the major browsers and sooner or later WebSql, IndexedDB will also be a part of all of them.

What is HTML5 storage?

Storages are one of the most interesting and futuristic features of HTML5. HTML5 storage is a standardize way of providing comparatively larger storage to save client side data. Previously cookies were considered as a solution of storing data client side; but only 4KB per cookie and 20 cookies per domain can never help to develop a proper web app. HTML5 storages not only provided larger space (5MB to 25MB depending on browsers) but also gave a good control.
Though it faced criticism due to lack of security, but the “something is better than nothing” concept helped it to be one of the mostly talked topics of HTML5.

Why you need client side storage

1. For better browsing experience with fast start-up.
2. To shift load from server sessions to client side variables.
3. To stop repetitive and similar ajax calls.
4. To make your app work when user is offline.
5. Easier programming model, with no server required.

Types of storage

1. sessionStorage
2. localStorage
3. Web Sql
4. IndexedDB
5. File system

sessionStorage and localStorage

sessionStorage and localStorage, basically known as web storages is used to store data in a key value format. Though both of them stores only string formats, but you can set and get your required things by serializing and deserializing.

Persistence:

sessionStorage: It persists for a session. It will persist in a single tab no matter how many times you navigate through different pages; but once you close the tab, things will be gone.
localStorage: It has more persistence. It persists the data even after you close the browser and reopen.

Availability to other tabs/windows

sessionStorage: Accessible only within the window or tab that created it
localStorage: Shared across every window and tab of one browser running same web app

Advantages

1. Supported in almost all the browsers, including iOS and Android. The best part is IE8 onward supports it.
2. Easy to use. APIs are very simple.
3. Semantic events available to keep other tabs/windows in sync.

Drawbacks

1. Supports only string format.
2. Serialization-deserialization is a costly process. Makes things slower.
3. Searching is never optimum; may have a visible performance drop in case of large data.
4. Manual effort is required to manage data as data is effectively unstructured.

Web SQL database

As the name speaks, the web SQL database is a spec that brings SQL to the client side, based on SQLite. But this specification is no longer in active development or maintenance now and may be completely dropped or replaced by some other specification, W3C announced that on 18th November, 2010.

Persistence

It’s just like Javascript variables. Once you refresh the page, everything is gone.

Availability to other tabs/windows

No, it’s not available to other tabs or windows.

Advantages

1. Being an asynchronous API, it is more performant.
2. Database interaction won’t lock up the user interface.
3. Good search performance, since data can be indexed according to search keys.
4. Easier to maintain integrity of data, due to rigid data structure.

Drawbacks

1. Not supported by all the browsers. IE and Firefox doesn’t support it at all; though the others do.
2. Need to learn SQL first to use it.
3. Database schema must be defined upfront, with all records in a table matching the same structure.

IndexedDB

When the W3C announced that developers shouldn’t work on web SQL actively anymore, IndexedDB came as a replacement.
Unlike the relational database, IndexedDB is a simple object store. You create an Object Store for a type of data and simply persist Javascript objects to that store. Each Object Store can have a collection of Indexes that make it efficient to query and iterate across.

Persistence

It doesn’t get deleted automatically. Once you create, it will persist for all the sessions of that particular domain.

Availability to other tabs/windows

Yes, it is shared across all the tabs or windows.

Advantages

1. As IndexedDB is using asynchronous APIs, database interaction won’t lock up the user interface. (Synchronous API is also available for WebWorkers.)
2. Data can be indexed according to search keys; hence searching operation become very fast.
3. Supports versioning.
4. Uses simple data model, so learning curve is not very steep.
5. Decent browser support: Chrome, Firefox, mobile FF, IE10.

Drawbacks

1. 1. Not supported in old versions of the browsers; this is the one and only drawback of IndexedDB I think.

File system storage

The other storages, mentioned above deal with text data, but file system storage, which is currently available only Google chrome and Opera can store binary content. It uses “FileSystem API Standard“, which gives each domain a full hierarchical file system; that means the binary files get stored in users hard disk.

Persistence

It is also like IndexedDB, which doesn’t get deleted after the session or closing the window.

Availability to other tabs/windows

Yes, it gets shared by all the tabs and windows.

Advantages

1. Can store large content and binary files, so it’s suitable for images, audio, video, PDFs, etc.
2. As you can store all your media files, stylesheets, fonts, scripts, so you can make a very rich as well as performant web app.
3. Good performance, being an asynchronous API.

Drawbacks

1. Not supported in much browsers. Only Chrome and Opera supports it.
2. No proper file management system or indexing is available; so searching become hard.

Conclusion

Day by day the client side development is becoming more efficient and performant. The storages mentioned above helps reducing the regular http communications between the client and the server. A good management and implementation of these can make your app immensely fast and will give the user a very good performance.