Part 2: What can JavaScript really do in (Client-Side Storage)?

8 min readMar 29, 2018

Last week we started a series aimed at digging deeper into JavaScript and What can JavaScript really do, we thought that by knowing overview about Javascript DOM & frameworks and Design patterns + we take fast roundabout popular functions created by javascript.

The first post of the series focused on providing an overview of the Javascript role, This second post will be diving into the offline storage and how we can use it. We’ll also provide a few quick tips on how to write Javascript lines & see examples how to use Javascript with offline storage.

Your browser is more than tool to reach different websites, now you can see your website performance and how much you need to download a file and many new features but in this article we will talk about specific feature in HTML APIs that allow to us to use storage built-in browser to save data for some time.

Different storage mechanisms:

Web Storage (e.g LocalStorage) is synchronous, has no Web Worker support and is size-limited (only strings). Although ideas for async LS have been kicked around in the past, current focus is on getting IndexedDB 2.0in a good state. I would personally use IDB + a library.
Cookies have their uses but are synchronous, lack Web Worker support and are size-limited. In previous projects I’ve used js-cookie for handling cookies via JS (~800bytes gzipped). Support for an Async Cookies API is being sketched out right now with a polyfill in the works.
WebSQL is asynchronous (callback-based), however it also has no Web Worker support and was rejected by Firefox and Edge but is in Chrome and Safari.
File System API is asynchronous too (callback-based) and does work in Web Workers and Windows (albeit with a synchronous API). Unfortunately it doesn’t have much interest outside of Chrome and is sandboxed (meaning you don’t get native file access).
File API is being improved over in the File and Directory Entries API and File API specs. A File API library exists and for file-saving, I’ve been using FileSaver.js as a stop-gap. The writable-files proposal may eventually give us a better standards-track solution for seamless local file interaction.

Now we will define Web Storage, IndexedDB, Web SQL DB with weakness points and examples.

Web Storage concepts and usage

The two mechanisms within Web Storage are as follows:

sessionStorage maintains a separate storage area for each given origin that’s available for the duration of the page session (as long as the browser is open, including page reloads and restores)
localStorage does the same thing, but persists even when the browser is closed and reopened.

These mechanisms are available via the Window.sessionStorage and Window.localStorage properties (to be more precise, in supporting browsers the Window object implements the WindowLocalStorage and WindowSessionStorageobjects, which the localStorage and sessionStorage properties hang off) — invoking one of these will create an instance of the Storage object, through which data items can be set, retrieved and removed. A different Storage object is used for the sessionStorage and localStorage for each origin — they function and are controlled separately

You will find your Store data into localStorage in Application

Storage limits:
The maximum browser storage space is dynamic — it is based on your hard drive size. The global limit is calculated as 50% of free disk space. In Firefox, an internal browser tool called the Quota Manager keeps track of how much disk space each origin is using up, and deletes data if necessary.

So if your hard drive is 500GB, then the total storage for a browser is 250GB. If this is exceeded, a process called origin eviction comes into play, deleting entire origin’s worth of data until the storage amount goes under the limit again. There is no trimming effect put in place, to delete parts of origins — deleting one database of an origin could cause problems with inconsistency.

Weakness of Web Storage:

Poor performance for large/complex data, when using the synchronous API (which is the most widely supported mode).
Poor performance when searching large/complex data, due to lack of indexing. (Search operations have to manually iterate through all items.)
Poor performance when storing and retrieving large/complex data structures, because it’s necessary to manually serialize and de-serialize to/from string values. The major browser implementations only support string values (even though the spec says otherwise).
Need to ensure data consistency and integrity, since data is effectively unstructured.

Overview of IndexedDB:
IndexedDB lets you store and retrieve objects that are indexed with a “key.” All changes that you make to the database happen within transactions. Like most web storage solutions, IndexedDB follows a same-origin policy. So while you can access stored data within a domain, you cannot access data across different domains.

IndexedDB is an asynchronous API that can be used in most contexts, including WebWorkers. It used to include a synchronous version also, for use in web workers, but this was removed from the spec due to lack of interest by the web community.

IndexedDB used to have a competing spec, WebSQL Database, but the W3C deprecated it on November 18, 2010. While both IndexedDB and WebSQL are solutions for storage, they do not offer the same functionalities. WebSQL Database is a relational database access system, whereas IndexedDB is an indexed table system.

Basic pattern
The basic pattern that IndexedDB encourages is the following:

Open a database.
Create an object store in the database.
Start a transaction and make a request to do some database operation, like adding or retrieving data.
Wait for the operation to complete by listening to the right kind of DOM event.
Do something with the results (which can be found on the request object).

Simple indexedDB example that will work both in Chrome and FF — Source Code

Overview of Web SQL Database:

The Web SQL Database API isn’t actually part of the HTML5 specification but it is a separate specification which introduces a set of APIs to manipulate client-side databases using SQL.

I’m assuming you are a great web developer and if that is the case then no doubt, you would be well aware of SQL and RDBMS concepts. If you still want to have a session with SQL then, you can go through our SQL Tutorial.

Web SQL Database will work in latest version of Safari, Chrome and Opera.

Weakness of Web SQL Database:

Deprecated. Will not be supported on IE or Firefox, and will probably be phased out from the other browsers at some stage.
Steep learning curve, requiring knowledge of relational databases and SQL.
Suffers from object-relational impedance mismatch.
Diminishes agility, as database schema must be defined upfront, with all records in a table matching the same structure.

Now we finish almost of Storage different mechanisms, Do you Thinking what if I run this storage in offline mode? Or what If I use it with push notification system build with Service Worker? Let’s see how it work and define what is Web Workers and how it work with Storage

Overview of Web Workers:

A web worker, as defined by the World Wide Web Consortium (W3C) and the Web Hypertext Application Technology Working Group (WHATWG), Web Worker is a simple means for web content to run scripts in background threads. The worker thread can perform tasks without interfering with the user interface. In addition, they can perform I/O using XMLHttpRequest (although the responseXML and channelattributes are always null).

There is popular mistake when you realize that JavaScript is a language, which doesn’t define a threading model. Web Workers are not part of JavaScript, they’re a browser feature which can be accessed through JavaScript.

What about browsers support? Check this link

Types Of Web Workers:

-Dedicated Workers
-Shared Workers
-Service workers

Dedicated Workers

Dedicated Web Workers are instantiated by the main process and can only communicate with it.

Shared Workers

Shared workers can be reached by all processes running on the same origin (different browser tabs, iframes or other shared workers).

Service Workers

A Service Worker is an event-driven worker registered against an origin and a path. It can control the web page/site it is associated with, intercepting and modifying the navigation and resource requests, and caching resources in a very granular fashion to give you great control over how your app behaves in certain situations (e.g. when the network is not available.)

IndexedDB with Worker:

IndexedDB with Web Workers — Source Code

Use Cases

web workers are still relatively new and the majority of samples/tutorials out there involve computing prime numbers. Although that isn’t very interesting, it’s useful for understanding the concepts of web workers. Here are a few more ideas to get your brain churning:

Prefetching and/or caching data for later use
Code syntax highlighting or other real-time text formatting
Spell checker
Progressive Web Apps (PWA)
Analyzing video or audio data
Background I/O or polling of webservices
Processing large arrays or humungous JSON responses
Image filtering in <canvas>
Updating many rows of a local web database

Demos

Finally Web Storage & Web Workers amazing stuff to create strong and stable applications, You can use Web Storage with different javascript frameworks & Web worker too is now available on React.JS as a default file in setup + Google map now is Progressive web application (PWA), Offline applications + Client-side storage strong stuff enough to build big application.