We Keep Coding

JavaScript Temporary Storage

I am writing a Quiz Application and require JavaScript mechanisms to temporarily store data without utilizing MySQL or an Internet Connection. The Game is a Standalone application. What techniques or libraries may be useful for such an application to store game data temporarily in the particular instance of running the JS functionality.
Please provide any references that may be useful.
Much appreciated

If you don't need your data to stay after you leave the page, consider using sessionStorage.
Otherwise, you're fine with localStorage, like I said in the comment, here is a very related answer: https://stackoverflow.com/a/26026430/965907

You can use cookies, but localStorage is a bit more modern and provides several advantages. See https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage for a list of storage options in modern browsers.
localStorage and sessionStorage are very similar, and I'd suggest you just use localStorage. See HTML5 Local storage vs. Session storage for a broader discussion.

Maybe you can use javascript cookies. With them you can keep information with a name for as long as you would like. sessionStorage and localStorage are harder to understand and add to your page, but if you are an expert then you could use those. But as I said, I would recommend using cookies.Good luck with your work!

Memory mapped equivalent for FirefoxOS

How would you emulate a memory mapped file in FirefoxOS, Tizen or any other mobile pure-JS solution?
The use case is for a mobile browser and you need lots of data which does not fit in the RAM or you don't want to waste RAM for it yet and prefer to lazy load it.
The only thing I found is IndexedDB or what can I do about it? Any better tricks or APIs?
Hmmh it looks like Web SQL Database could be also a solution on Android, Tizen or iOS. But Firefox does not support it (?)
Update: I'm asking because of some experiments

First thing first, Web SQL won't be ever standardised as explained in the specification, so it should be considered only for WebKit/Blink-based browsers.
There is an awesome overview of offline storage options in this queston, even though the map tiles are considered in that question, I think it is still relevant to your use case.
I believe you are on the right track with IndexedDB for the graph data. On a high level it is a key-value asynchronous object store (see the Basic Concepts document). For your use case, you could index graph nodes in an object store. There is, for example, LevelGraph library which stores graph data in IndexedDB, though it is built for Semantic Web triples. HeliosJS is also worth mentioning, though it is an in-memory graph database.
Edit: Current API for IndexedDB is asynchronous. There is synchronous API drafted in the spec, which could be used only in web workers. Unfortunately no engine currently implements this feature. There is a pending patch for Gecko, but I did not find any plans for Blink or WebKit, so it is not a meaningful option now.
It is possible to access raw files through Web APIs. You could use XHR2 to load a (local) file as a binary Blob. Unfortunately XHR2 is mostly designed for streaming files and not for a random access, though you could split-up the data into multiple files and request them on demand, but that may be slow.
The direct access to files is currently quite limited, FileList and createObjectURL are primarily used for direct file user input (through Drag and Drop or file input field), FileSystem API was recently killed, and the DeviceStorage is non-standard and privileged (Firefox OS-specific). You can also store files in IndexedDB, which is described for FileHandle API. However, once you manage to get access to the raw File object, you can use the Blob.slice method to load chunks of the file – there is a great example of reading file chunks via upload form.
You may also want to look at jDataView library & friends, which eases handling of binary data through the more efficient ArrayBuffer.
Edit: As for the synchronous API, localStorage (aka DOM Storage) could be considered too. It is also a key-value storage, but much much simpler and more limited than IndexedDB:
Size of the storage is limited, usually to 5 MB
Only one localStorage per domain/application (you can have multiple named object stores in IndexedDB).
Only strings can be stored.
In general, localStorage is useful cookies replacement, but it is not really useful for storing large offline data.
So to sum it up:
IndexedDB is the easiest and widely available option, though it may be slow, inefficient or hit memory limits with very large data; also, only asynchronous API is currenlty possible.
Raw file access is hard to obtain without user interaction and the APIs are unstable and non-standard.
In the end, you can combine both approaches, two options come in mind:
Use XHR2 to parse the large file in chunks and store the parsed nodes into IndexedDB
Store the large file into IndexedDB (via XHR), use FileHandle.getFile to load the File object and Blob.slice to read its content.
In all cases, you can (should) use Web Workers to handle data manipulation and calculations in the background.
Anyway, GraphHopper looks great, we really lack such non-trivial offline applications for Firefox OS, so good luck!

Is there anything bigger than HTML5 localStorage?

I'd like to store local data on the client side to speed up page loads of my web-app. I tried with HTML5's localStorage but unfortunately it's too small for my needs. Is there anything bigger?

You have several options, but browser support differs and as such you will need to abstract the differences away from the browser by an extra layer on top of the various browser mechanisms
Local Storage is supported by pretty much everything, and normally stores 5-10MB.
IndexedDB is supported by most, but not all desktop browsers and can store lots more data. How much depends on the browser, but expect something like 50MB or unlimited.
WebSQL is the only way to go if you aim for iOS and Android browsers, as they don't support indexeddb. You can store up to 50MB there.
Elegant abstraction layers that does all of this for you are many: check out the answers in this thread.

If the data is static in nature you might be able to cache some in a .js file or use jsonp instead of local storage.
Otherwise your only option right now is local storage with a storage limit of 5 - 10 megabytes depending on the browser. You might be able to get more out of this by compressing your data with something like this: https://github.com/olle/lz77-kit/blob/master/src/main/js/lz77.js

Offline Mobile Web Application Storage

I am looking at writing a mobile web application with offline support, and would prefer to use the HTML5 offline capabilities instead of something like phonegap.
A requirement of the app will be that it store 2 collections of different types of objects (lets call them Books and Authors) which, when online, it will download from the server. If it didn't need to be offline then I'd be using some flavour of SQL tables or (preferably) a document-based DB to store these items, but having done some basic investigation I haven't found anything that feels "right" that works offline.
My question is: what is the best strategy to store those items? What I have considered so far:
HTML5 localStorage - Seems to have relatively wide support but is limited to key value pairs, which would mean a slightly unpleasant data structure - maybe having a total-authors key and then a series of author-1....author-n key-document pairs. This feels wrong to me - like I am trying to work around the intent of the storage.
CouchDb - I've worked with CouchDb quite a bit in the past so would love to use it or an equivalent, but "proper" CouchDb would require a native app (with which I have no experience), and the 2 in-browser equivalents I have seen don't quite seem to do the trick: Lawnchair doesn't seem to add much to the localStorage option and BrowserCouch doesn't appear to have had much activity recently (which always makes me wary).
WebDb - Looks like it would be perfect...except it seems to be officially discontinued and doesn't look to be widely supported
Gears - Discontinued
IndexedDB - Limited browser support for now (at least according to caniuse)
I'm convinced there must be something out there that does what I want, and I've just managed to somehow overlook it. Can anyone suggest the way this ought to be done (as opposed to a way it could be done)?

There's no browser-native simple solution as far I know; you'll have to either go with localStorage or develop for both WebDB and IndexedDB.
But non-native you could use a abstraction layer like lawnchair (uses localStorage by default, plugins available for indexeddb, webdb, ...) or the one SO-user Gatapia wrote for picnet (uses indexeddb & webdb & gears) that you can find on github.

Is there a wrapper for HTML5 sessionStorage that provides a good compatability implementation?

We would like to use the HTML5 sessionStorage (or something like it) in a new project but you can't rely on it on some browsers. There's this project (http://code.google.com/p/sessionstorage/) which provides an implementation that works a lot of places, yet oddly it doesn't use the HTML5 version if it is available. It always does its own thing.
There's this project (https://github.com/jas-/jQuery.handleStorage) over on GitHub
but its emulation layer is cookies (bleh!).
Note: The above is incorrect, see the answer from jas- below where he explains that I was mistaken about that project.
Is there anything better out there that offers a good implementation like the first project but falls back automatically to HTML5 if it is available? We might retrofit the first project to automatically fall back to HTML5 if available but would rather not build that if there's already a good solution out there.

I know you said that you wanted a solution that did it all but what's wrong with something like this?
if(!window.sessionStorage){
$.getScript("/google_code_sessionStorage.js");
}

There's a couple of YUI utilities for this, depending on whether you're using 2 or 3:
YUI 2: Storage Utility
YUI 3: Storage Lite
Both will use HTML5 session storage if available.

Munsch,
I realize this post is several years old but I wanted to clarify the project you mentioned, I am the author of jQuery.handleStorage and it does not use cookies as its default method of client storage.
If you read the documentation for the project you will see that one of its three client storage options is to use cookies in the event a clients browser does not support the HTML5 localStorage and/or sessionStorage API's.
With that said, if you need a more robust and flexible client storage tool I would recommend secStore.js as it does not implicitly require binding to a form, supports the HTML5 client storage options, gracefully degrades to cookie in the event of a legacy browser and optionally uses the SJCL API to provide transparent encryption of possible sensitive data.

I ended up doing more research on this because I liked both of the answers I got, but I wanted something more like the YUI 3: Storage Lite but that didn't require YUI. Something that was framework agnostic or jQuery friendly would work a lot better for us.
In the end I found a couple of possibilities and one stood out as what we'll try and put to use: Lawnchair
Also considered: store.js, AmplifyJS