It would be nice if the documentation mentioned that garlic.js requires an HTML5 browser with localStorage implemented. Remember, there are people who are still using Internet Explorer 6 and 7, and these browsers are incompatible . This is a minor details considering browser marketshare, but a fallback using cookies would be a nice-to-have feature.
Besides that, awesome work!
I'm admittedly only speaking for a dozen agencies or so, but things are definitely better off lately than they used to be.
But I suppose if your userbase is predominantly IE6/7, then it may not be worth the effort for you.
I tried to test it in IE 6, and the browser just immediately crashes. Not like an alert box, just an instant shut down!
In the past I would have started the unpleasant task of figuring that out and fixing it up, or perhaps detecting and redirecting to a more lightweight page.
This time I said screw it - I'm done with IE 6! Call me irresponsible or lazy or whatever you want but I'm just done with IE 6 and it feels great!
By the way YouTube shows a giant warning on their page if you view it with IE 6, saying that it won't be supported in 6 months.
However if you are building websites that regular people use they still use XP and IE7... so much so that it can account for 10-30% of your website traffic.. It really pains me when HTML frameworks like Foundation 3.x drop support for IE7 and below because there is still the userbase there.
IE7/8 is not dead for most of the world yet. People who run statcounter websites are getting data from people who run their tools. I would trust if someone like Google Analytics released an average browser usage as they are more widely used. Who the F uses statcounter nowadays?
 Though you can do tricks/hacks to make it work for IE7.
Those who still have a need to support those browsers should code up and release an additional library that adds support to garlic.js so it can be used only by those that need it.
In fact, it'd be great if every library added cross browser support for old browsers as add-ons to libraries instead of making them a core part of the library.
You don't need to backport everything, only the critical stuff.
The source is here:
The code is pretty much idiomatic jQuery js following most of their style rules, layout rules and standard constructs so it's obviously been written as a jQuery extension. He must know jQuery well, hence why not use it?
As for why, well I spotted a bit of sizzle, jQuery.data and the event framework in one pass of a small code base. Given the nature of the library I can even guess what they're all for without reading the code.
Quite a lot more than the inevitable each that is also in there.
This seems to be the new 'cool'. "Why jQuery whine", whine, whine.
> You've got jQuery on your own site. Why are you moaning about it?
It was a theme requirement, also, Tu Quoque.
> He must know jQuery well, hence why not use it?
Because dependency for 200 lines of code.
> Quite a lot more than the inevitable each that is also in there.
Then the rest of your reply was redundant, wasn't it...
May be he does not. May be He uses Dojo, Prototype or any other JS library.
At least jQuery doesn't extends Object and Array like other libraries so it's quite safe to have as an extra dependency.
And there's your answer: The "cost" of depending on jQuery is small since so many things depend on it that most potential users probably already pull it in.
Ii your website uses the Google CDN to download jQuery new visitors will often not even download jQuery when arriving at your website because their browser probably has it already cached from visiting one of the dozens of other websites they have visited.
Some uses are unnecessary, eg. using `closest` to get the container form element. `element.form` can be used on any form input or control to access the form itself.
I dunno though. I don't like adding jQuery as a dependency but there are still some cases where it's just pragmatic, especially with handling events.
I'll definitely re-work on both the code and the doc. I've read that there is a kind of localStorage portage for IE8- that I'll look into.
Currently, if the browser does not support localStorage, the plugin auto-disable.
Which leads me to an aside — Why did you choose localStorage over sessionStorage?
For those who don't know — local/session are the same, only session will be cleared when the browser is closed.
My browser already auto completes form data… so I'm not sure I'd need it between sessions.
Please remember there are large numbers of users who cannot upgrade the browser they use at work, and there are valid reasons why their IT departments do not let them upgrade.
If your webapp is for entertainment, social, or otherwise not useful for corporate, government, etc. users then you're probably right. But otherwise you may be punishing users who have no choice in the matter, hate IE6 as much as you do, and use Chrome at home.
I agree about code bloat, etc., and if there's a clean way to maintain a separate branch or plugin to support IE6/7 users that's great, but if a library doesn't support them, I simply can't use it given my userbase.
Another link worth knowing about -- perhaps even more so, since there are demos there:
This is a huge problem, and is the reason I've had Lazarus installed for a few years now.
Apparently it exists for Chrome now, too.
Some other issues:
- doesn't work in IE
- saved data doesn't expire
- Storage keys aren't unique to the URL, so if two pages have the same exact layout, but different content, identical forms on the page will be filled out with stored information.
So it's a good concept, but I think that there are definitely some questions about user privacy, and that it needs to be paired with some extra UI cues that make it clear to the user that they're looking at draft information, and not something that's saved.
Keep you API open and flexible for the UX designer to choose what's best when. Also, if it's showing local data do something simple, like give the field a class of "garlic-data". That way the UX designer can choose the best way to differentiate it for their use case.
1.1.1 http:// attacklab.net/showdown/
1.3 Unit tests
1.6.1 Redis inspired, at twilio https://github.com/twilio/BankersBox
1.6.2 Amplify.store http://amplifyjs.com/api/store/
1.6.3 Persistent form data http://guillaumepotier.github.com/Garlic.js/
You should gather that in a cool markdown file on a github repo that every one could fork and suggest / add their own good libs :)
(Noticed this because the demo failed for me the first time.)
Like many UX features similar to this, I would say it mainly comes down to who your audience is, and where it's being used on how "weirded out" users would feel by this feature.
Please, could you update the link of this post to http://garlicjs.org?