Hacker News Reader

Comment by fruchtose | Hacker News Reader

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

View on HN

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

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.

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.

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.

right!

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

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.

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.

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.

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.

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.

Reply on news.ycombinator.com