5 ms·

JavaScript Garden

120 points by mhr_online 12y ago

geronimogarcia 12y ago
Man, this bring memories back! This was one of the recurring sources I had five or six years ago along with Eloquent JavaScript. Everyone doing JavaScript should read it at least twice.
je42 12y ago
Sometimes I have the feeling they are a bit over the top. F.e.: eval should never be used. Any code that makes use of it should be questioned in its workings, performance and security. If something requires eval in order to work, it should not be used in the first place. A better design should be used, that does not require the use of eval. The conclusion doesn't offer any advise what should be done instead of eval. Somehow they assume everybody uses eval because its convenient, and that there is a quick work around available. The functionality of eval however non-trivial. F.e. - if you want to evaluate a lambda function given from the command line. - if you want to execute javascript provided by a user in a browser window.
- alandarev 12y ago
  Command line and user in browser window can both be united into: executing the code provided by the user. Eval can be closely compared to the execution of a binary file. Do you trust that user to upload executable and run it on the host? Then eval is fine, otherwise - you are asking for the trouble.
- grayrest 12y ago
  > The conclusion doesn't offer any advise what should be done instead of eval. In case anybody is actually wondering, you almost always want a Function constructor: var add = new Function('arg1', 'arg2', 'return arg1 + arg2;'); The only exception I've ever run into was in miniature string templating where eval or with was used as a hacky way to generate the context. The best way to do that is replace with a function argument: tmpl_str.replace(/{{(\w+)}}/g, function(_, key) { return ctx[key]; })
  - babablacksheep 12y ago
    new Function() parses the JavaScript code stored in a string into a function object, which can then be called. It cannot access local variables because the code runs in a separate scope.
    - LunaSea 12y ago
      Function constructor as well as setInterval() and setTimeout() with stringyfied functions are almost as insecure as eval(). Until now I don't think that I have ever encountered a case where any of these were the absolute only solution.
  - arnarbi 12y ago
    > In case anybody is actually wondering, you almost always want a Function constructor I don't see how that's any different from eval. What you almost always want is a better abstraction of your data and operations, that allows you to stop treating data as code.
- mattmanser 12y ago
  Out of interest what does F.e. mean? You seem to be using it in place of the usual e.g.
  - rory096 12y ago
    For example, probably.
  - Raphmedia 12y ago
    Same thing, english instead of latin. It's simply an abbreviation that doesn't really respect the conventions as you are used to see them.
    - je42 12y ago
      thanks for pointing it out. I wasn't aware that f.e. is not accepted as standard english abbreviation.
      - Raphmedia 12y ago
        To be honest, I couldn't tell if it is accepted or not. I think it is, but we simply don't see it that often. As far as I can tell, it is perfectly correct to abbreviate in the english language. http://www.encyclopedia.com/doc/1O25-fe.html http://www.encyclopedia.com/doc/1O25-fe.html
        mattmanser 12y ago
        No, f.e. is not an accepted or known abbreviation, it's not perfectly correct. You can try and start one, after all yolo, lol, rotfl. Or perhaps not ;) When I asked, I was wondering if it was a known abbreviation from an academic field I didn't know. I wouldn't use it, e.g. is the correct abbreviation to use in this instance.
        je42 12y ago
        Interesting. Most references that I found say that f.e. is not correct. ;)
olavk 12y ago
I think this wording is misleading: > Everything in JavaScript acts like an object, with the only two exceptions being null and undefined. The 'scalars' - string, number and boolean - only behaves like objects in the limited sense that you can apply the dot operator. But they are immutable primitive values, while all other objects are basically mutable dictionaries. So there is a big difference. For example the syntax seem to allows you to set a property on a scalar, but no property will not actually be set because there is no dictionary to hold the properties.
- nawitus 12y ago
  Yeah. I believe that false.toString() is "actually" something like (Boolean(false)).toString().
acjohnson55 12y ago
This should be posted once a year for review. It's incredible how many boneheaded decisions in Javascript's design are still with us. I used to hate JS for that reason. But you eventually internalize all of the pitfalls, and find out, possibly after reading the brilliant Javascript Allongé (http://leanpub.com/javascript-allonge http://leanpub.com/javascript-allonge), that the language has some brilliant aspects as well. It's abundantly clear at this point that we're stuck with it, so read your JavaScript Garden and make the best of it!
mckoss 12y ago
How do they manage to keep the different language translations in sync? Seems duanting to send a pull request for anything but typos.
mckoss 12y ago
Section on null seems off to me. > in almost all cases, it can be replaced by undefined. Null has a subtle relationship to Object in that typeof null == 'object' For that reason, null should be used for values that can be optional references to Objects (or null).
osconfused 12y ago
On this same subject, an excellent read is JavaScript: the Good Parts. http://shop.oreilly.com/product/9780596517748.do http://shop.oreilly.com/product/9780596517748.do
keithwhor 12y ago
I should point out that: // Set Bar's prototype to a new instance of Foo Bar.prototype = new Foo(); Bar.prototype.foo = 'Hello World'; Is an antipattern. Use Object.create() to set up your prototype chain, i.e.: Bar.prototype = Object.create(Foo.prototype); Bar.prototype.foo = 'Hello World'; I understand this information is dated, but it should be updated as the language evolves and standards change. Surprises me to still see this floating around. You do not want to invoke your constructor when you set a prototype. If you want to use the parent constructor's behaviour in the child, it should be done in your child constructor using Foo.call(this, ...) or Foo.apply(this, [...]). Object.create is supported by all modern browsers, and the Object.create polyfill can be found in Mozilla's documentation: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

120 points by mhr_online 12y ago

Man, this bring memories back! This was one of the recurring sources I had five or six years ago along with Eloquent JavaScript. Everyone doing JavaScript should read it at least twice.

je42 12y ago

Sometimes I have the feeling they are a bit over the top. F.e.: eval should never be used. Any code that makes use of it should be questioned in its workings, performance and security. If something requires eval in order to work, it should not be used in the first place. A better design should be used, that does not require the use of eval. The conclusion doesn't offer any advise what should be done instead of eval. Somehow they assume everybody uses eval because its convenient, and that there is a quick work around available. The functionality of eval however non-trivial. F.e. - if you want to evaluate a lambda function given from the command line. - if you want to execute javascript provided by a user in a browser window.

alandarev 12y ago
Command line and user in browser window can both be united into: executing the code provided by the user. Eval can be closely compared to the execution of a binary file. Do you trust that user to upload executable and run it on the host? Then eval is fine, otherwise - you are asking for the trouble.
grayrest 12y ago
> The conclusion doesn't offer any advise what should be done instead of eval. In case anybody is actually wondering, you almost always want a Function constructor: var add = new Function('arg1', 'arg2', 'return arg1 + arg2;'); The only exception I've ever run into was in miniature string templating where eval or with was used as a hacky way to generate the context. The best way to do that is replace with a function argument: tmpl_str.replace(/{{(\w+)}}/g, function(_, key) { return ctx[key]; })
- babablacksheep 12y ago
  new Function() parses the JavaScript code stored in a string into a function object, which can then be called. It cannot access local variables because the code runs in a separate scope.
  - LunaSea 12y ago
    Function constructor as well as setInterval() and setTimeout() with stringyfied functions are almost as insecure as eval(). Until now I don't think that I have ever encountered a case where any of these were the absolute only solution.
- arnarbi 12y ago
  > In case anybody is actually wondering, you almost always want a Function constructor I don't see how that's any different from eval. What you almost always want is a better abstraction of your data and operations, that allows you to stop treating data as code.
mattmanser 12y ago
Out of interest what does F.e. mean? You seem to be using it in place of the usual e.g.
- rory096 12y ago
  For example, probably.
- Raphmedia 12y ago
  Same thing, english instead of latin. It's simply an abbreviation that doesn't really respect the conventions as you are used to see them.
  - je42 12y ago
    thanks for pointing it out. I wasn't aware that f.e. is not accepted as standard english abbreviation.
    - Raphmedia 12y ago
      To be honest, I couldn't tell if it is accepted or not. I think it is, but we simply don't see it that often. As far as I can tell, it is perfectly correct to abbreviate in the english language. http://www.encyclopedia.com/doc/1O25-fe.html http://www.encyclopedia.com/doc/1O25-fe.html
      - mattmanser 12y ago
        No, f.e. is not an accepted or known abbreviation, it's not perfectly correct. You can try and start one, after all yolo, lol, rotfl. Or perhaps not ;) When I asked, I was wondering if it was a known abbreviation from an academic field I didn't know. I wouldn't use it, e.g. is the correct abbreviation to use in this instance.
      - je42 12y ago
        Interesting. Most references that I found say that f.e. is not correct. ;)

olavk 12y ago

I think this wording is misleading: > Everything in JavaScript acts like an object, with the only two exceptions being null and undefined. The 'scalars' - string, number and boolean - only behaves like objects in the limited sense that you can apply the dot operator. But they are immutable primitive values, while all other objects are basically mutable dictionaries. So there is a big difference. For example the syntax seem to allows you to set a property on a scalar, but no property will not actually be set because there is no dictionary to hold the properties.

nawitus 12y ago
Yeah. I believe that false.toString() is "actually" something like (Boolean(false)).toString().

acjohnson55 12y ago

This should be posted once a year for review. It's incredible how many boneheaded decisions in Javascript's design are still with us. I used to hate JS for that reason. But you eventually internalize all of the pitfalls, and find out, possibly after reading the brilliant Javascript Allongé (http://leanpub.com/javascript-allonge http://leanpub.com/javascript-allonge), that the language has some brilliant aspects as well. It's abundantly clear at this point that we're stuck with it, so read your JavaScript Garden and make the best of it!

mckoss 12y ago

How do they manage to keep the different language translations in sync? Seems duanting to send a pull request for anything but typos.

mckoss 12y ago

Section on null seems off to me. > in almost all cases, it can be replaced by undefined. Null has a subtle relationship to Object in that typeof null == 'object' For that reason, null should be used for values that can be optional references to Objects (or null).

osconfused 12y ago

On this same subject, an excellent read is JavaScript: the Good Parts. http://shop.oreilly.com/product/9780596517748.do http://shop.oreilly.com/product/9780596517748.do

keithwhor 12y ago

I should point out that: // Set Bar's prototype to a new instance of Foo Bar.prototype = new Foo(); Bar.prototype.foo = 'Hello World'; Is an antipattern. Use Object.create() to set up your prototype chain, i.e.: Bar.prototype = Object.create(Foo.prototype); Bar.prototype.foo = 'Hello World'; I understand this information is dated, but it should be updated as the language evolves and standards change. Surprises me to still see this floating around. You do not want to invoke your constructor when you set a prototype. If you want to use the parent constructor's behaviour in the child, it should be done in your child constructor using Foo.call(this, ...) or Foo.apply(this, [...]). Object.create is supported by all modern browsers, and the Object.create polyfill can be found in Mozilla's documentation: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...