Develop Reference

localStorage vs localSettings

I'm trying to save settings in a Javascript Based Universal App in Windows 10.
I'm currently using localStorage and it seems to be working fine. But I've seen other posts that indicate I should use:
Windows.Storage.ApplicationData.current.localSettings
(see: Best way to store string array in local storage, Windows 8?)
And this works as well.
But I'm wondering what is the recommended way? localStorage seems to be persistent even when I quit and reload the app. But will it always be persistent? And will it work on mobile? or is localSettings generally the way to go, what's the difference here guys?

ApplicationData.current.localSettings is backed up in the cloud, which means that if the user buys a new phone (or resets their existing phone) and asks to restore settings from a backup of their old phone, the settings in ApplicationData.current.localSettings will be restored to the new phone. This article discusses app data backup in more detail.

Queries related to browser cache

I am using browser cache to store my response data, but wanted to know how feasible it is to store the data in browser cache. Can anyone explain the following:
1. Is their a guarantee that the data will be cached for specific time, if I am storing only JSON data(can be huge).
2. What is the maximum size limit of browser cache.
3. Is my data cross domain accessible?If yes is their a way I can protect it?
4.Does the result vary from browser to browser?

There are two main storage method in modern browsers, localStorage and sessionStorage, in your case I assume you are using localStorage.
For localStorage:
the data stored will be persistent as long as the user not clearing the data or you remove them using localStorage.removeItem()
the maximum size of localStorage varies from browsers, basically there is at least 2.5MB. details in this post
localStorage works just like cookies, so you don't want to store any sensitive stuff, SSL between clicent and server is recommended
IE 8 and above, Chrome 4, Firefox 3.5, Opera 10.5 and Safari 4 have already implemented this API
Details about localStorage in this link

LocalStorage limit on PhoneGap

There is usually a limit of 5MB on localStorage on browsers, including iPhone's Safari.
Since PhoneGap has the access higher security privileges including access to other storage mechanisms on the device, in theory they should be able to eliminate the limit of 5MB.
For example, it should be able to get around the usual restrictions by storing the data on a file, etc while keeping the API compatible with localStorage javascript object.
Is this done? Or is PhoneGap limited to the same 5MB?

PhoneGap doesn't do anything out of the ordinary to extend the default limits. On Android, I get 2.5M characters in localStorage (Strings in JavaScript are UTF-16).
You can find default limits for most browsers here: http://dev-test.nemikor.com/web-storage/support-test/
This was helpful in understanding the limitations, and I used the code to create a simplified test PhoneGap app.

PhoneGap has File API that should not be affected by browser local storage limits but don't know if there exist any abstraction to make it behave as HTML5 local storage "backend".

If you want to store a large amount of data you should not do that in localStorage, there are databases and files for that kind of need. localStorage is a key-value datastore, it's use is limited and it should not be "hacked" to fit all needs.

Localstorage is something which is provided by the browser.
Localstorage is not something which is available on a device, either a mobile phone or a desktop, that is leveraged by a browser.
Since it is something which the browser provides there is no way, we can change/increase it using Phonegap since your Phonegap app runs inside the browser.
If you want more storage space, you can use a technique which Phonegap can access like a file storage or SQlLite.

Client side local storage of data

I want to store some data client side. Cookies are my first inclination, but they get sent with every request, right? Is there a way to store data without it being transferred? I don't necessarily want to add 10-20k of overhead for every request. Is the only alternative HTML 5 webstorage and how many browsers have adopted that?

html5 storage is widely deployed
HTML5 STORAGE SUPPORT
IE FIREFOX SAFARI CHROME OPERA IPHONE ANDROID
8.0+ 3.5+ 4.0+ 4.0+ 10.5+ 2.0+ 2.0+
you can find out more # http://diveintohtml5.ep.io/storage.html

No, not all cookies get sent with every request. You can check to see if a cookie exists, if not create it, and if so, read it. Cookies are still a good cross-browser option for small amounts of data.

http://fsojs.com supports robust file storage client-side, but only works with Chrome at the moment

As you have mentioned, cookies are an options and so is web storage in the HTML5 spec. There's also the ability to use Flash to store data with the added benefit that this data persists across multiple browsers on the same machine, but the drawback that you'll need a fallback for users who don't have Flash.
Personally, keeping the data on the server (identified by the session id or cookie) would be my way to do it, you have control of the data and don't have to worry about losing it when the user clears their cache or switches machines/devices. It's also the most fault-tolerant because it doesn't rely on browser features and/or plugins (other than perhaps cookies).
One more thing, if you're looking for an abstraction of client-side data storage that uses all of the above (cookies, flash, web storage) check out Evercookie

Different browser behaviour between localStorage/sessionStorage and cookies

This is not so much a technical question as a question of practice: browser storage doesn't seem to have the same browser behaviour as cookies.
For example:
In Firefox 3.6, sessionStorage is not shared between tabs within the same browser session.
localStorage can never be set to expire, while sessionStorage can never persist.
If a site uses cookies for the session, they are shared between tabs.
If a cookie is set to expire, then it expires after a certain date.
It makes sense that it is not 'like for like', however this means that we may need to mix and match our variable storage solutions depending on need. Your thoughts and opinions on the benefits/pitfalls of either would be appreciated.
Background:
On the website we are currently developing, we decided to implement progressive enhancement using browser storage (sessionStorage and localStorage) with a cookie fall-back. Our reason for doing this is simply as a learning exercise, but moving forward this should help us on mobile platforms and situations where cookies are not usable (we are already storing our assets on a cookie-less domain, so this isn't a motivator).
To do this, we have created a class which has set, get, remove and clear methods which store the application variables within a JSON string (this allows us to group values in a hierarchy). For browsers which don't have a JSON parser we use Crockfords JSON plugin.
At run time the storage class works out if the user's browser supports browser storage, otherwise sets the functions to write to cookies instead. Due to the inconsistencies already highlighted (plus others I am unaware of), this 'like for like' progressive enhancement is actually false.
Edit: Another browser vaguary: if IE 8 is running in IE 7 standards mode it supports localStorage and sessionStorage, where standalone IE 7 does not(!).