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.
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?
"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.
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.
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.
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.
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.
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!
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'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.
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.
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'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.
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.
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.
I.e. maximum storage size, scope (global, 2nd level domain, any domain), life cycle (when is it cleared), etc.