I think the desire for this kind of project is very reasonably based, and it looks like you have done great work on most of the implementation. I have one gripe with it, though.
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 [1]. This is a minor details considering browser marketshare, but a fallback using cookies would be a nice-to-have feature.
That depends on your user base. If it's just the wider internet that's accurate, but if you're aiming at government or big corporate clients, you'd better check your analytics first.
At least in the federal government in the DC area, IE6 and 7 are all but dead, basically. While there are still plenty of legacy servers running older versions, desktops are far less behind than they were even 2 years ago.
I'm admittedly only speaking for a dozen agencies or so, but things are definitely better off lately than they used to be.
We're talking about something that prevents form data loss. If it doesn't error on IE6/7 and simply doesn't work, then that's fairly graceful degradation that provides a benefit to users on more modern browsers.
But I suppose if your userbase is predominantly IE6/7, then it may not be worth the effort for you.
One of the sites I built recently has a ton of backbone.js dynamic loading.
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.
Sure you can quote stats all day, but it depends on your target audience. If you are running a tech website (such as HN/TC/Reddit/etc) you will see a HUGE portion of visitors using browsers like Chrome/Firefox and hardly any IE.
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[1] 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?
[1] Though you can do tricks/hacks to make it work for IE7.
Adding many lines of code to a library to support two browsers that have 1.5% of worldwide share and should die because we would all be better off if they did is not the right solution.
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.
Oh of course IE8 isn't going anywhere, but there is no reason at all for people to be on 7. Can you explain why someone on XP would move off 6 but not go all the way?
It depends on your market. In China, IE6 is still at 20-25% and it's even more if you count all of the smaller browsers that simply wrapped IE6 Trident into their own browser interface.
I get the sentiment here but considering this is an enhancement to the user experience that IE6/7 users will never know they missed out on either way...
You don't need to backport everything, only the critical stuff.
"Ew"? Flash is practically ubiquitous, works reliably and predictably in both modern and legacy browsers, and is used as a fallback for HTML5 by tech giants like Google. No need to let your prejudice get in the way.
No more ew than people being on IE.
In my opinion, flash is a viable alternative where modern technologies aren't able to be used, especially if it's a trivial enhancement.
Hmm, what does jQuery provide that is so essential that someone decides to add a dependency this big for something so simple? It seems that everything requires jQuery these days, even when a 5-line for loop would do.
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.
> It seems that everything requires jQuery these days
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.
JavaScript is an extremely bare language that largely lacks a standard library. Libraries like jQuery make code easier to write and easier to maintain and sometimes even result in smaller downloads for the user.
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.
It seems to use it for events, selectors, and data attributes.
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.
Ideally this would be solved in a similar way as when you statically link to libraries in C - the parts of your dependency are pulled in and users don't have to worry about it. (There are other issues with this of course, but they are well understood by now that someone could develop a system to mitigate that by now)
The problem is more about the download size than the actual deployment (unless you mean using only the parts of jQuery you need, in which case I guess it would be hard to share between apps).
Why not? This is a plug-in aimed to help in the event something happened with the browser window. Besides accidently closing it there aren't many other scenarios where this plug-in would be useful.
I disagree to a certain extent. I don't believe in catering to the possible 5% [1] market share that will not upgrade their browsers. Anything that strongly suggests people to upgrade is better, imo. I don't care for the entire notion of including everybody when it calls for more code bloat and makes the code more difficult to maintain or upgrade.
> I don't believe in catering to the possible 5% [1] market share that will not upgrade their browsers
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.
This library solves a problem and solves it well. The local storage issue should be left up to other libraries who are designed to solve that gripe. :-)
I figure those folks using IE 6 or 7 are used to a lackluster internet experience. Little perks like this are not critical features and can be foregone for this small userbase.
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 [1]. This is a minor details considering browser marketshare, but a fallback using cookies would be a nice-to-have feature.
Besides that, awesome work!
[1] http://www.quirksmode.org/dom/html5.html#t00