1. Bitwise Operators
3. Dom Mutations
Client side storage is almost as old as Internet itself. Back in the days we used cookies for this, but since Firefox 2 & Safari 4 browsers support DOM Storage techniques. We are probably all familiar with IndexedDB or deprecated WebSQL. Both of them are widely supported in almost all of the newest browsers:
localStorageThats not all - we also have well known localStorage & sessionStorage key/value client storage system. We can simply save the value in one window:
And load it in another:
The advantage of local/session storage over IndexedDB is that we can listen to an event that fires when something has changed - we can for instance propagate those changes to all the browser cards or iframes in our application. Choose the 'result' tab in the next fiddle, go back to the first one and save something using the form.
It's helpful also in IndexedDB based apps - for example PouchDB made by Dale Harvey use localStorage events with IndexedDB data to keep everything up to date everywhere.
window.name storageWe can also use window.name property to store data on the client side. This ancient method allows us to read and write data across pages and domains, even from outside the current origin. According to Wikipedia [HTTP COOKIE] we can store up to 32MB there (according to some sources its even around 60MB). It's also accessible even before domready event. And even if it's not really cleaver idea in times of tabbed browsing (every new tab starts with empty window.name), it's still used as a fallback in for older browsers. More on window.name storage:
Ajaxian: What’s in a window.name?
Session variables without cookies
HTML5 sessionStorage for "every" browsers