Show HN: garlic.js - don't let your users lose their form data | Hacker News Reader

Show HN: garlic.js - don't let your users lose their form data

guillaumepotier.github.com

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.

Besides that, awesome work!

[1] http://www.quirksmode.org/dom/html5.html#t00

For all intents and purposes, IE6 and IE7 are dead. They account for less than 1.5% of worldwide browsers [1]. At this point, seems okay to leave out.

[1] http://gs.statcounter.com/#browser_version_partially_combine...

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.

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.

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.

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.

I think you're within your right to ditch IE6. I don't even support IE7, users just get a chromeframe prompt.

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?

Grandkid/nephew/neighbour's kid was around to do one upgrade but not the other?

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.

say that to some my sites that still see >50% IE6/7 share. It all depends on your demographic.

If you want to support this on IE 6/7, just add a shim that uses userData behaviors for localStorage. Here's one: https://github.com/mattpowell/localstorageshim

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.

It also probably wouldn't be super crazy difficult to use a Flash local storage fallback for them.

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

It would also be nice if the documentation mentioned that it requires jQuery.

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.

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

That's true, I guess. I just don't think you should include large dependencies if you can easily avoid them.

It really doesn't matter, if you use a version of jQuery that is likely to already be cached (like the ones hosted at Google Code).

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

You're better off using the full jQuery hosted at a common CDN, since it is likely to already be cached on the user's computer.

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?

The source is here:

https://github.com/guillaumepotier/Garlic.js/blob/master/gar...

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.

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

> You've got jQuery on your own site. Why are you moaning about 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.

right!

Yes,

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.

Best

IE8 supports both local and sessionStorage.

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.

what about when the browser crashes?

Sure, if you think thats a valid use case to build for. I don't.

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.

well, if you use a modern browser it's an unfortunate reality, regardless of how you or I think it wrong

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.

[1] http://theie7countdown.com/

> 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 would suggest using userData [1] for IE 6 and 7.

[1] http://msdn.microsoft.com/en-us/library/ms533007%28v=vs.85%2...

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.

I'm getting a 404. https://github.com/guillaumepotier/Garlic.js

http://garlicjs.org/ works as well

The provided github link 404's. But this one works:

https://github.com/guillaumepotier/Garlic.js

Another link worth knowing about -- perhaps even more so, since there are demos there:

http://garlicjs.org

> don't let your users lose their form data

This is a huge problem, and is the reason I've had Lazarus installed for a few years now.

https://addons.mozilla.org/en-us/firefox/addon/lazarus-form-...

Apparently it exists for Chrome now, too.

Thinking about it, I'm mildly amazed that the browsers themselves didn't solve this problem back in 1996 or so.

Maybe it's a security issue? With some sites you might not want that information saved, perhaps.

Good call. Not thought about that. At least, it is shown to the user, and not hidden and recorded secretly.

Opera saves forms when possible. It also has instant backward navigation from cache. I guess it saves forms on cached pages.

Firefox seems to do this sometimes too. (e.g. I went backwards then forwards while typing this, and my text was retained.)

Form content recall is a native Chrome feature now.

Do you have a link? I've followed Chrome development pretty closely and have never seen that. I too use Lazarus.

Not a link, but without any plugins of that type installed, this is the behavior I've had for a long time now. (I use Chrome for everything until I need to test apps in FF).

Could you explain that? I lost forms yesterday that I couldn't see any way to recall.

Don't want to be that guy, but what's different from http://simsalabim.github.com/sisyphus/?

Oh, I was totally unaware of this one. Never mind, it clearly shows that there's a lack here on this browser behavior. My project is juste a few hours pet project. I'll try to maintain it and make it as advanced & usefull as sisyphus, for fun :)

Name, code, documentation, dependencies, browser support, test coverage, etc.

Is there a way to differentiate between data that's only saved using Garlic (local) vs data that's also been saved to the server? This could be a huge confusion for users if there isn't.

I agree with this. Outside of explicitly signaling to users that they have a saved 'draft' of the form, and having them click a button on the page to restore their filled out fields from the draft, there aren't really very many sane implementations.

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.

Yes, I'll need to work on that, if there is already server data. Maybe in a tooltip like, let the user choose which version he should use

I wonder if you should have some sort of icon or text indicator (per field) that shows there is saved form data available, but don't populate until the user triggers it, or an option to restore all available form data in one click? There are situations where I want to clear a form so I'll refresh the page if a clear option isn't available. I guess the solution would be for everyone that uses garlic.js to make sure they have a clear option.

There are all sorts of use cases that might want one thing over the next (display server data vs local data for example).

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.

Could you add a version number to your script for this reason? It'll also make diff'ing much easier.

Nice work! I've added garlic to cdnjs: http://cdnjs.cloudflare.com/ajax/libs/garlic.js/0.0.1/garlic...

'Loose' is the opposite of 'tight'; to 'lose' is to misplace, which is the word you were going for.

Just a heads up, the <title> of your page is still "Bootstrap".

That was a test.

You passed.

ahah ^^

I just hope everyone gets to use it. I added it to my "great to have" Javascript libraries list. Good work!

Ruben, can you please share your "great to have" Javascript libraries list? It sounds promising.

It's still a work in progress, but of course! I have many (many!) bookmarked pages with more libraries in my instapaper feed, some emails to myself and a few emacs .org files I use as buckets. I just decided to start collecting them last week and made a quick sweep-clean with the most recent tabs I had open and the few I had linked to recently:

1.1 Markdown 1.1.1 http:// attacklab.net/showdown/

1.2 DBs 1.2.1 http://jazzrecord.org

1.3 Unit tests 1.3.1 http://jsunittest.com/

1.4 Documentation 1.4.1 http://www.naturaldocs.org/ 1.4.2 http://fitzgen.github.com/pycco/

1.5 Visual 1.5.1 http://lab.hakim.se/kort/

1.6 localStorage 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/

I'll probably end up posting the list (or the mind map that forms it) on my blog sooner or later (probably as soon as I hit 30 or when I finish my current Javascript RTE project)

Anyone else ending up on a "UPVC Doors and Windows" site when going to http://jsunittest.com/ ?

Jsunit's site is dead, too. http://qunitjs.com/ looks like a good one having similar abilities (test in browser was my main feature for this one)

Hmmm indeed. I'll find another one ;)

Nice!

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

Good idea Guillaume ;) (and great work here!) I think it will make for an interesting git for my almost empty repositories!

Should add an option for users to disable this (like remember me on login forms)... not good for public computers if you don't know the form you just filled in but didn't submit will retain the data. Other than that, cool!

Persisting localStorage seems to be controlled by the setting to delete cookies after exiting the browser. If i have it set to delete cookies, it deletes localStorage. if i allow it to keep cookies after quitting the browser, then it persists localStorage.

(Noticed this because the demo failed for me the first time.)

Are you sure of that? I've tested the behavior of cookies / localStorage on iPads recently, and on private sessions without cookies, Safari on iPad had localStorage persisted.

Getting a 404 on the OPS link. This seems to work https://github.com/guillaumepotier/Garlic.js

While convenient and technically fine, this can get creepy for users. “Wait, I didn't submit the form on purpose but the data has been saved?”

I had this same thought, but I think it would just be best to use these sort of plugins wisely, and not on every form element possible. Or to maybe have some sort of form "note/tip" that mentions it's being auto saved. Sites like Quora do this via drafts of your comments/responses that you write. That way people know to erase the content if they truly don't want it saved.

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.

Pretty cool - another very similar option that comes in the form of a jQuery plugin that I just noticed in the [new] section of HN.... https://github.com/simsalabim/sisyphus - It looks pretty slick.

Hi there, github has some difficulties with the page url and tend to show some weird 404 :(

Please, could you update the link of this post to http://garlicjs.org?

Thx!

As a side note do not use the Bootstrap class .well together with .row cause it overflow because of padding. Create this structure: div.row > div.well > the content.

Thanks for your first comments ;) This is a very very early alpha release. 1h of work in fact.. Please, feel free to contribute!

They have been doing this for years!!

http://www.bonsoni.com/post_ad.php

Why is this a website feature instead of a browser extension, where it would work for every site?

I would imagine it's easier for a site owner to provide this than get everyone to install a browser extension.

I think anothermachine meant it should be default behavior in browsers. I agree, with the attribute to disable or enable this from the html it would be a nice feature for browsers to implement.

I just made a simple Chrome Extension out of it: https://chrome.google.com/webstore/detail/simple-form-recove...

It should be a browser feature, option or extension, for users to have control over it from one place.

I was thinking about this the other day and I thought "How is this not standard!?"

Good job!

It's not standard because people frequently do things like type a credit card number into a form on a public computer. Lots of potential for privacy breaches.

With and option to disable this behavior from the HTML websites could chose to disable it on forms which might contain sensitive data. Browsers could even disable it by default and let the websites enable using an attribute.

Even on a private computer, having it stored in a file can be bad, because if another process gets on there and reads the storage, it'll get the data.

Huh, this is very nice. Congratulations!

Thanks :)

Link doesn't work (404)

i like it. workaround for older browser possible?

Yes possible. Someone mentioned usage of store.js, i'll dive into it next week

it's gooooone!

Reply on news.ycombinator.com