7 ms·

JavaScript caching framework for client side caching in the browser

65 points by d0ugal 15y ago

marcuswestin 15y ago
Nice! Also relevant: localStorage wrapper for all browsers without using cookies or flash. https://github.com/marcuswestin/store.js https://github.com/marcuswestin/store.js Perhaps worth using under the hood for locache?
- tbsdy 15y ago
  This looks interesting... It appears that there is an abstraction and you could easily swap out the localStorage parts with your js goodness!
- d0ugal 15y ago
  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.
sbarre 15y ago
Amplify.js has a caching store that supports localStorage and more, abstracting away the actual storage mechanism.. http://amplifyjs.com/api/store/ http://amplifyjs.com/api/store/
- d0ugal 15y ago
  neat - thanks. I'll check this out, I hadn't found many options when I originally looked.
  - iambot 15y ago
    Lawn chair is also a good wrapper for localStorage with plenty different adapters: http://westcoastlogic.com/lawnchair/ http://westcoastlogic.com/lawnchair/
- subliminalbrad 15y ago
  I've been using Amplify.store for some time now, and I would highly recommend it. It uses localstorage where possible, but it also includes a lot of sensible fallbacks including browser-specific strategies. It also allows you to add your own strategies if you wish.
- polynomial 15y ago
  That's actually what I thought this post was going to be about.
ladon86 15y ago
Looks good! How is mobile browser support?
- d0ugal 15y ago
  Good - I need to do further testing. However, it works well in mobile Safari from my testing - any help here on android etc. would be appreciated.
- d0ugal 15y ago
  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 http://d0ugal.github.com/locache/tests/index.html
huskyr 15y ago
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 15y ago
  Expiration is the first thing that comes to mind
  - d0ugal 15y ago
    Expiration was the main reason I created it. Also it will handle storing objects.
    - huskyr 15y ago
      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 15y ago
        Sure - I'll do that.
    - rauar 15y ago
      Storing objects in localStorage requires only 2 one-liners with JSON2.js (stringify() and parse() ).
    - cheeaun 15y ago
      Note that Amplify.js mentioned by sbarre, has expiration too.
ImDelicious 15y ago
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.
- huskyr 15y ago
  Agree with 1). Might be a matter of taste, but jQuery does this as well with many methods (e.g. $.on).
- d0ugal 15y ago
  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.
x5315 15y ago
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?
- d0ugal 15y ago
  Simply because I didn't know about it. Happy look at pull requests or I'll have a go at it myself if I get time.
- sbarre 15y ago
  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/ http://amplifyjs.com/api/store/ I have nothing to do with that project but I hate to see people re-invent the wheel. ;-)
gioele 15y ago
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 15y ago
  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 15y ago
    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.
- gambler 15y ago
  Browsers don't have built-in partial caching, which I consider the biggest missed opportunity for improving the state of modern web development. Cache HTML blocks, then send a list of tokens identifying those blocks to the server, so it doesn't re-generate those pieces of content. It's conceptually simple, declarative, possible to implement as 100% backwards-compatible and could be used pretty much everywhere. Another big thing that's missing is partial forced expiration. This is when the entire page is cached, but certain blocks are excluded from caching. Upon the next request to the same page, the browser sends a normal request with one addition: an extra header listing the transient blocks. Thus, the server has an opportunity to respond with updates only, rather than the entire page.
btipling 15y ago
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 15y ago
  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.

65 points by d0ugal 15y ago

Nice! Also relevant: localStorage wrapper for all browsers without using cookies or flash. https://github.com/marcuswestin/store.js https://github.com/marcuswestin/store.js Perhaps worth using under the hood for locache?

tbsdy 15y ago
This looks interesting... It appears that there is an abstraction and you could easily swap out the localStorage parts with your js goodness!
d0ugal 15y ago
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.

sbarre 15y ago

Amplify.js has a caching store that supports localStorage and more, abstracting away the actual storage mechanism.. http://amplifyjs.com/api/store/ http://amplifyjs.com/api/store/

d0ugal 15y ago
neat - thanks. I'll check this out, I hadn't found many options when I originally looked.
- iambot 15y ago
  Lawn chair is also a good wrapper for localStorage with plenty different adapters: http://westcoastlogic.com/lawnchair/ http://westcoastlogic.com/lawnchair/
subliminalbrad 15y ago
I've been using Amplify.store for some time now, and I would highly recommend it. It uses localstorage where possible, but it also includes a lot of sensible fallbacks including browser-specific strategies. It also allows you to add your own strategies if you wish.
polynomial 15y ago
That's actually what I thought this post was going to be about.

ladon86 15y ago

Looks good! How is mobile browser support?

d0ugal 15y ago
Good - I need to do further testing. However, it works well in mobile Safari from my testing - any help here on android etc. would be appreciated.
d0ugal 15y ago
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 http://d0ugal.github.com/locache/tests/index.html

huskyr 15y ago

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 15y ago
Expiration is the first thing that comes to mind
- d0ugal 15y ago
  Expiration was the main reason I created it. Also it will handle storing objects.
  - huskyr 15y ago
    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 15y ago
      Sure - I'll do that.
  - rauar 15y ago
    Storing objects in localStorage requires only 2 one-liners with JSON2.js (stringify() and parse() ).
  - cheeaun 15y ago
    Note that Amplify.js mentioned by sbarre, has expiration too.

ImDelicious 15y ago

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.

huskyr 15y ago
Agree with 1). Might be a matter of taste, but jQuery does this as well with many methods (e.g. $.on).
d0ugal 15y ago
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.

x5315 15y ago

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?

d0ugal 15y ago
Simply because I didn't know about it. Happy look at pull requests or I'll have a go at it myself if I get time.
sbarre 15y ago
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/ http://amplifyjs.com/api/store/ I have nothing to do with that project but I hate to see people re-invent the wheel. ;-)

gioele 15y ago

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 15y ago
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 15y ago
  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.
gambler 15y ago
Browsers don't have built-in partial caching, which I consider the biggest missed opportunity for improving the state of modern web development. Cache HTML blocks, then send a list of tokens identifying those blocks to the server, so it doesn't re-generate those pieces of content. It's conceptually simple, declarative, possible to implement as 100% backwards-compatible and could be used pretty much everywhere. Another big thing that's missing is partial forced expiration. This is when the entire page is cached, but certain blocks are excluded from caching. Upon the next request to the same page, the browser sends a normal request with one addition: an extra header listing the transient blocks. Thus, the server has an opportunity to respond with updates only, rather than the entire page.

btipling 15y ago

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 15y ago
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.