Store.js - cross browser local storage without using cookies or flash | Hacker News Reader

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

github.com

155 pointsnarcvs62 comments

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.

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).

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?

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.

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?

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?

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

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.

"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.

Yes, that's exactly what I was trying to get at, evidently unsuccessfully. For all of IE's failings, it does seem to have been first to support an awful lot of scripting features. They've always been documented, but hardly anyone seems to know about them until the other browsers popularise them, and even then IE's implementation seems to be forgotten, presumably because APIs are nonstandard and the docs use different terminology.

I was doing web dev for an agency back when IE6 was the coolest browser around, and all around me JavaScript was still very much being used only for menus and rollovers. I guess all these features were basically ahead of their time. I'd love to know what Microsoft used them for, or intended them for. I mean, they've been exercising their vested interest in not pushing rich browser-based apps for years. I know their MSDN site has been very AJAX-y since before it was cool.

XmlHTTPRequest was created by Microsoft for OWA around 2000. I remember using JSRS (http://www.ashleyit.com/rs/) at the time until Mozilla started supporting XHR. Fine times :)

Very cool. From a quick test it looks like JSRS uses a hidden IFrame; in the case of POST it's the target for a scripted hidden form submission. The response is embedded in HTML though (as a textarea no less!), which doesn't make much sense to me.

Microsoft failed the dHTML buzzword campaign or didn't even care. Apple and Google did a much better job with HTML5.

dHTML+TIME could even use dynamic generated music

http://en.wikipedia.org/wiki/DirectX_Media

But I guess Microsoft is too obsessed with .Net and Silverlight now.

I wanted to point out the significant difference between "hidden" and "ignored". There was nothing hidden about these IE features. People just chose to ignore them. And of course they were nonstandard, just like most other new technology.

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

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.

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

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.

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

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.

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.

Surely if the language specification calls semicolons optional then any compressor worth its salt should honor that? The YUI Compressor, at least, copes with semicolon-devoid Javascript just fine.

That's the sufficiently smart compiler argument. The fact remains you have more options available to you for minifying if you don't consider semi-colons optional, naming one compressor that can deal doesn't change the fact that most can't.

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!

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!

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

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

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

Usually 5MB

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.

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.

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

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.

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.

If you don't need 100% reach, have a look at xauth source: http://github.com/xauth/xauth

They use a central domain and window.postMessage to make a secure but shared storage.

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

I would certainly hope so...

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

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.

The potential for abuse is staggering. Yes, it would be good to have to benign purposes, but unless you trust everyone on the internet to act honorably, it's a terrible idea.

Then disable it by default, but don't leave it out altogether.

Can you give me an example of when it would ever be appropriate to turn something like that on?

whenever the user wants it

(to repliers)

</sarcasm>

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

It's entirely possible I'm wrong, but I'm hinging my decision largely on the location (hn, where invasive user tracking is synonymous with evil with nearly everyone) and the "sigh".

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>

Good point, people never post useless comments.

</sarcasm>

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

Yup, it works in IE6.

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

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

I'm not convinced that IETester changes the underlying APIs correctly. Because of bad experience with "Multiple IE" simulators in the past I don't test on anything but the real install.

I hear you there. I just wish it were easier to have multiple versions of IE laying around without having to boot a VM for each. Heh.

ThinApp [http://en.wikipedia.org/wiki/VMware_ThinApp] is pretty useful when needing to do "classic" browser testing.

I don't think many people would be willing to invest $6,000 USD (minimum!) to test old versions of IE.

Yeah, I had trouble with those "portable IE6" implementations too. But IETester seems to be a lot closer to the real thing, at least as far as I can tell.

Hi,

IETester hooking is not perfect yet, but the engine is the correct versioned engine used on each tab. You can find more information here :

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

Regards.

IEs4Linux might work for you then. It can install the original IE6, IE5.5, and IE5 under Wine. IIRC it uses a separate wine tree for each version, so there's no chance of the IE6 js interpreter being run in IE5.

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

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

  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?

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.

erlanger: you can consider the API stable now.

Reply on news.ycombinator.com