
JavaScript caching framework for client side caching in the browser - d0ugal
https://github.com/d0ugal/locache
======
btipling
If you are caching private information you are going to have a bad time. The
expiration feature is misleading. It will only run when the site with the
library is loaded.

So if you're in a random internet café checking your email on a site that uses
this library to cache your emails and then close the browser and leave all
that private information, your email content, is cached on that browser. If a
savvy enough person saw you on this site and knew what it did that individual
could go to the browser and simply use Web Inspector, in the case of Chrome,
and check out what was cached and read all of your cached emails.

There is no way for the client to know it's not a secure environment unless
you ask the user. You also could delete the cache on log out, but what you
can't do is delete the cache when the browser or tab closes, because then you
don't have a cache at all. And more than likely most devs wont even think on
this and just imagine that their cache will expire at some point.

Gmail solves this problem by requiring a per browser opt-in via, on Chrome at
least, a browser extension for client side caching.

I haven't investigated to see if there's some way to use the HTML5
cache.appcache window.applicationCache to solve this problem. That actually
has an expire.

~~~
d0ugal
Yup, this also need to be documented or worked on. I've only been using it to
cache content from a public 3rd party API so not had to tackle this yet.

------
gioele
Cache management is hard to get right. Make sure the data you send is
cacheable and let the browser manage it.

Browsers have complex mechanisms in place to deal with broken firewalls, high-
latency links, non-conformant servers and proxy. Any client-side caching
implementation is going to be slower and less complete than its browser
counterpart.

~~~
geuis
I have to agree. As nice as these kinds of systems sound (I've designed
experimental ones myself), in _most_ applications its just not the right way
to handle it. The first gotcha is that localStorage isn't async itself. If you
have lots of data that has to be pulled out or stored, you might end up
locking up the thread and bring the rest of the app to a standstill.

Another important issue is that _all_ browsers already have caching mechanisms
built in. Spend your time verifying and correcting that your headers are being
set properly for your js and stylesheets.

Also, localStorage only gives you 5mb of storage. That space can be taken up
very quickly if you aren't careful.

There are some very limited cases where this kind of thing can be useful. One
that I'm reminded of is mobile web applications. Steve Souders talked about
this briefly at the jQuery conference around this time last year. However, all
the major mobile browsers already support cache manifests, which mostly
obviates the need for something like this.

~~~
d0ugal
I agree, its not a good approach in general. Correct cache headers on the
server is probably the way to go in many cases.

I originally created this handle working with an external API in a simple
static files only app. It works really well for that usecase and solved my
issues. It was then easy to make in a general way, so I decided to chuck it
out in the wild and see if I can help anybody else.

Perhaps I should add an area to the README to define when you should (and
maybe more importantly when you shouldn't) use this.

------
huskyr
What does this library offer over just using localStorage without a library?
The browser API is already really easy, and with no fallbacks for IE<9 i don't
really see any advantage in using this...

~~~
binarymax
Expiration is the first thing that comes to mind

~~~
d0ugal
Expiration was the main reason I created it. Also it will handle storing
objects.

~~~
huskyr
Maybe it would be an idea to state that clearly in the readme on Github? I
guess it's probably obvious for people who know memcache, but for a frontend
developer the library seems like a general localStorage wrapper. Your library
deserves more than that :)

~~~
d0ugal
Sure - I'll do that.

------
sbarre
Amplify.js has a caching store that supports localStorage and more,
abstracting away the actual storage mechanism..

<http://amplifyjs.com/api/store/>

~~~
d0ugal
neat - thanks. I'll check this out, I hadn't found many options when I
originally looked.

~~~
iambot
Lawn chair is also a good wrapper for localStorage with plenty different
adapters: <http://westcoastlogic.com/lawnchair/>

------
marcuswestin
Nice! Also relevant: localStorage wrapper for all browsers without using
cookies or flash. <https://github.com/marcuswestin/store.js>

Perhaps worth using under the hood for locache?

~~~
d0ugal
That's neat. locache has a simple wrapepr around localStorage - the
"locache.storage" object, so it would be easy to add an extra layer that
supports other browsers. I had considered this already, but not had the need
yet. There is an implementation in the Mozilla docs to mimic the localStorage
API but store the data in cookies.

------
x5315
Why doesn't this use the userData for IE 6/7? Given that those browsers are
the least performant, wouldn't it make sense to ensure caching works on them?

~~~
sbarre
As I pointed out below, Amplify.js, an established Javascript library, has the
Store module that supports all manner of browser storage (including userData)
with a unified interface that abstracts away the specific storage mechanism.

<http://amplifyjs.com/api/store/>

I have nothing to do with that project but I hate to see people re-invent the
wheel. ;-)

------
ImDelicious
I find the batch operations odd odd:

1\. why have a different method for multiple values rather then check
parameter type for the normal methods (e.g. if 'set' received an object or get
received an array).

2\. getMany returns an array instead of an object mapping key to value. Sure
may be more efficient but less convenient to use.

~~~
d0ugal
Hmm. Good points. 1) I made them different operations just for clarity -
however, it would make the API a little nicer if they were the same. 2) I
agree with this - an object mapping would probably be easier.

Pull requests, issues etc. all welcome. Otherwise, I'll have a look at it
myself.

------
ladon86
Looks good! How is mobile browser support?

~~~
d0ugal
Head to this page with a browser, if its all green then its fully supported on
that browser. Otherwise, open an issue on github :)
<http://d0ugal.github.com/locache/tests/index.html>

