7 ms·

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

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 http://www.quirksmode.org/dom/html5.html#t00

gildas 14y ago
It would also be nice if the documentation mentioned that it requires jQuery.
- guillaumepotier 14y ago
  right!
- StavrosK 14y ago
  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.
  - vidarh 14y ago
    > 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.
    - StavrosK 14y ago
      That's true, I guess. I just don't think you should include large dependencies if you can easily avoid them.
      - jarin 14y ago
        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).
  - mattmanser 14y ago
    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/garlic.js 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.
    - StavrosK 14y ago
      > 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...
    - joesb 14y ago
      > 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.
  - seabee 14y ago
    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)
    - StavrosK 14y ago
      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).
      - jarin 14y ago
        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.
  - FuzzyDunlop 14y ago
    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.
  - th 14y ago
    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.
paulirish 14y ago
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_combined-ww-daily-20121107-20121109-bar http://gs.statcounter.com/#browser_version_partially_combine...
- jakejake 14y ago
  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.
  - mikegioia 14y ago
    I think you're within your right to ditch IE6. I don't even support IE7, users just get a chromeframe prompt.
- showerst 14y ago
  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.
  - bmelton 14y ago
    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.
  - 14y ago
twmb 14y ago
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/ http://theie7countdown.com/
- jtheory 14y ago
  > 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.
guillaumepotier 14y ago
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
- benschwarz 14y ago
  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.
  - mh- 14y ago
    what about when the browser crashes?
    - benschwarz 14y ago
      Sure, if you think thats a valid use case to build for. I don't.
      - jonknee 14y ago
        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.
      - mh- 14y ago
        well, if you use a modern browser it's an unfortunate reality, regardless of how you or I think it wrong
Hawkee 14y ago
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.
ErikD 14y ago
I would suggest using userData [1] for IE 6 and 7. [1] http://msdn.microsoft.com/en-us/library/ms533007%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/ms533007%28v=vs.85%2...
recuter 14y ago
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.
- jarin 14y ago
  It also probably wouldn't be super crazy difficult to use a Flash local storage fallback for them.
  - Navarr 14y ago
    Ew
    - neotek 14y ago
      "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.
    - juanojeda 14y ago
      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.
ErrantX 14y ago
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. :-)
dmethvin 14y ago
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 https://github.com/mattpowell/localstorageshim

gildas 14y ago

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

guillaumepotier 14y ago
right!
StavrosK 14y ago
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.
- vidarh 14y ago
  > 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.
  - StavrosK 14y ago
    That's true, I guess. I just don't think you should include large dependencies if you can easily avoid them.
    - jarin 14y ago
      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).
- mattmanser 14y ago
  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/garlic.js 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.
  - StavrosK 14y ago
    > 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...
  - joesb 14y ago
    > 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.
- seabee 14y ago
  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)
  - StavrosK 14y ago
    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).
    - jarin 14y ago
      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.
- FuzzyDunlop 14y ago
  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.
- th 14y ago
  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.

paulirish 14y ago

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_combined-ww-daily-20121107-20121109-bar http://gs.statcounter.com/#browser_version_partially_combine...

jakejake 14y ago
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.
- mikegioia 14y ago
  I think you're within your right to ditch IE6. I don't even support IE7, users just get a chromeframe prompt.
showerst 14y ago
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.
- bmelton 14y ago
  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.
- 14y ago

twmb 14y ago

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/ http://theie7countdown.com/

jtheory 14y ago
> 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.

guillaumepotier 14y ago

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

benschwarz 14y ago
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.
- mh- 14y ago
  what about when the browser crashes?
  - benschwarz 14y ago
    Sure, if you think thats a valid use case to build for. I don't.
    - jonknee 14y ago
      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.
    - mh- 14y ago
      well, if you use a modern browser it's an unfortunate reality, regardless of how you or I think it wrong

Hawkee 14y ago

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.

ErikD 14y ago

I would suggest using userData [1] for IE 6 and 7. [1] http://msdn.microsoft.com/en-us/library/ms533007%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/ms533007%28v=vs.85%2...

recuter 14y ago

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.

jarin 14y ago
It also probably wouldn't be super crazy difficult to use a Flash local storage fallback for them.
- Navarr 14y ago
  Ew
  - neotek 14y ago
    "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.
  - juanojeda 14y ago
    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.

ErrantX 14y ago

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

dmethvin 14y ago

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 https://github.com/mattpowell/localstorageshim