Store.js - cross browser local storage without using cookies or flash

by narcvs • 16 years ago

155 62 16 years ago

barredo2• 16 years ago

From the readme:

"So far tested in

Tested in Firefox 2.0 Tested in Firefox 3.0 Tested in Firefox 3.6 Tested in Chrome 5 Tested in Safari 4 Tested in Safari 5 Tested in IE6 Tested in IE7 Tested in IE8 Tested in Opera 10"

Does it mean it works on IE6+? Does IE6 have local storage?

kingsley_20• 16 years ago

Probably uses Adobe Flash storage in browsers that don't support a db.

pmjordan4• 16 years ago

The source code is very short, readable and only one JavaScript file (plus an HTML page with embedded JS for the tests). There's no Flash, although that was admittedly my first thought as well.

cheald6• 16 years ago

Take a look at the source. It uses an IE-proprietary something or other to mock the behavior.

http://msdn.microsoft.com/en-us/library/ms531424%28v=VS.85%2...

Been available since IE 5.5, apparently. Who knew?

barredo2• 16 years ago

Really awesome. I did check the source, but did not quite understand that. Thanks!

pmjordan4• 16 years ago

Looks like it. If you look a the store.js source code, it links to http://msdn.microsoft.com/en-us/library/ms531424(v=VS.85).as... which appears to be another one of those hidden gems in IE, like the original AJAX implementation, or XDomainRequest.

wrs2• 16 years ago

"Hidden?" Give IE some respect...its rendering may have been crap, but it had plenty of features like this for building robust web applications years before the cool kids realized that might be a good idea.

alc277• 16 years ago

I've seen some frameworks that use flash storage as a last resort for IE6. I've found success just building in a ajax fail-over and then let IE6 or any other browser make use of the fail-over.

narcvs2• 16 years ago

IE6 has userData behavior, which can be used to store data on the client just like with local storage

wolfhumble• 16 years ago

Tested it on IE 6 and got: "Tests passed" So I guess it works . . . :-)

narcvs2• 16 years ago

Yup, it works in IE6.

I don't have access to IE5.5, would love to have someone test it.

cheald6• 16 years ago

Give IETester a whirl. IE 5.5, 6, 7, 8, and 9 preview render engines in a single executable.

http://www.my-debugbar.com/wiki/IETester/HomePage

ido• 16 years ago

Is there a significant amount of people out there who still use IE5.5?

Myrth• 16 years ago

It would be nice to know limitations (by browser/version?)

I.e. maximum storage size, scope (global, 2nd level domain, any domain), life cycle (when is it cleared), etc.

paraschopra2• 16 years ago

I just tested. Like cookies, it also obeys domain-only visibility. So, all hopes for cross-domain user tracking are still doomed. sigh

orangecat• 16 years ago

So, all hopes for cross-domain user tracking are still doomed. sigh

I would certainly hope so...

dandelany2• 16 years ago

I'm completely unconvinced that cross-domain local storage is even remotely a good idea. I can't think of any data I'd want to store in a clientside database that I would want other sites to be able to see/modify.

  So, all hopes for cross-domain user tracking are still doomed. sigh

Um, this is a good thing. I don't want the sites I visit to be communicating my use patterns to each other.

paraschopra2• 16 years ago

Actually, it wasn't a sarcasm. I do need cross-domain user tracking for perfectly legitmate reasons. Many of my users do A/B test where control is www.example.com and variation is www.example.org (for example) and the goal page lies on www.shoppingcart.com -- currently there is NO way I can track a user across these three domains (no, third party cookies don't work properly on Safari and Opera).

I am left to experiment with user fingerprinting md5(user-agent, http accept and screen resolution) but that is less than ideal situation.

cheald6• 16 years ago

Why on earth would you imply that cross-domain user tracking is a good thing?

calcnerd2563• 16 years ago

because it's a choice

Edit: I misread "is" as "could be". It's a good thing to have because it could be a good thing to use. It may be a bad thing to have enabled by default, but it's a bad thing to omit outright.

Groxx4• 16 years ago

(to repliers)

</sarcasm>

lanstein• 16 years ago

This was one of the less obvious uses of sarcasm in recent memory.

dandelany2• 16 years ago

I don't think so... If it was sarcastic, it wouldn't really be worth mentioning, like saying <sarcasm>Oh great. Another car with airbags!</sarcasm>

kenpratt• 16 years ago

Lawnchair (http://brianleroux.github.com/lawnchair/) is similar to this, but you have to pick an adapter (see http://github.com/brianleroux/lawnchair for browser list).

mblakele• 16 years ago

In the past I have used PersistJS (http://pablotron.org/?cid=1557) for this. Are there reasons to prefer one or the other of these libraries?

marcuswestin4• 16 years ago

PersistJS is 12kb minified. store.js is 4kb unminified

PersistJS falls back on flash and cookies, which is bad (flash slows down browser during page loading, cookies fatten your network requests). Store.js uses localStorage, globalStorage and IE behaviors which do not have those negative side effects.

erlanger• 16 years ago

  Fix issue 1, rename store.del() to store.remove()
  marcuswestin (author)
  18 minutes ago

Will the API be stabilized? Or can you alias method names in cases like this, rather than clobbering them?

alunny• 16 years ago

It's a sixty line JS file that's been online for less than a day. I don't think API stability is a major concern at this point.

marcuswestin4• 16 years ago

erlanger: you can consider the API stable now.

n8agrin• 16 years ago

It seems as though the author does not believe in semicolon use in Javascript. Looks interesting though.

marcuswestin4• 16 years ago

I use semicolons when they're needed (for loops, multiple statements per line), and don't use them when they're not. The code becomes cleaner to my eyes.

gnaritas2• 16 years ago

They're always needed so the JavaScript can be run through a compressor for production deployment without breaking the code.

Beyond that you're using curly braces when they're not strictly required, which seems inconsistent. I would expect either both all the time or both only when strictly necessary.

empire29• 16 years ago

Anyone know of size limitations on this storage? I am in the middle of writing a jQuery plugin and storing data in cookies which have the 4KB size limitation (which resulted in me having to "chunk" the data across several cookies). This looks like the perfect alternative!

richbradshaw• 16 years ago

Usually 5MB

Groxx4• 16 years ago

I think Safari defaults to 10MB, though I may have changed it and forgotten doing so.

eli3• 16 years ago

Be careful, there's a limit on how many total cookies you can have per domain too.

philfreo• 16 years ago

also be aware that data is getting submitted to your domain on every request -- not great for performance

eli3• 16 years ago

In theory localStorage should work on iPhone and Android 2.0+ too

chip• 16 years ago

Do you plan to add length? ie localstorage.length, etc. I'll like to implement this on http://readmelater.com

Looks great by the way!

tobyhede• 16 years ago

For a different take on local storage, have a look at MilkCrate http://github.com/garrow/milkcratejs

MilkCrate is a wrapper around html localStorage/globalStorage that provides support for saving and querying collections of objects. MilkCrate attempts to implement a similar querying interface to mongoDB.

Dylan16807• 16 years ago

It works now that I stuck it on a server, but apparently FF3.6.4 drops the data between passes on a file:// url. IE6 and Opera10 hang on to it, nothing else available here.

Store.js - cross browser local storage without using cookies or flash

Related Stories