Originally Posted by xelawho
Let's just assume that I know nothing about the cache, local storage, etc. The JSON file can be ridiculously big - nearly 3MB in some cases (which seems quite big, and certainly seems to slow my phone down) but I don't need all of it in one hit. The way I've got it working so far is ajax call dumps all the json into the page then we filter from there, which works fine on the desktop but I guess smaller devices struggle with that load.
What I'm wondering is if:
a) it's possible, and
b) there would be any performance gain
to leaving the json where it is (I'm imagining localStorage here) and only pulling in the bits of data that match the filtering request.
or is it all just one big memory pot, and saving in one place ends up costing somewhere else, making it all balance out in the end?
localStorage is one big 2.5mb pot. there will be little/no boost from splitting hairs on the client. a performance boost could come from having 30 100kb chunks that are fetched as needed, or a server that feeds the client as needed...
i've loaded json in the 5-15mb range on many devices, and it seems to work. Localstorage will max out in chrome at 2.5mb, since it uses 2bytes per char. ff gives you the full 5, IE has some weird limit that makes no sense, i think it's slightly more than chrome until 10, when it's like firefox's.
depending on your data, you can use deflate to shrink it down 50-75%. some binaries don't like to be zipped, or unzipped rather, but i've had excellent results with ascii text.
manifest is nice because it has no pre-set limit, so it might be all you need.
if you need more than a compressed 2.5 mb, you'll have to use a DB.
i have been successfully keeping about 16mb client-side under one key as a big json string using my simple abstraction lib, http://danml.com/js/localstorage2.js
it's barely more complex than localStorage to use, certainly FAR simpler than the webSQL and indexedDB APIs it sits on top of.