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.

Yeah. I believe that false.toString() is "actually" something like (Boolean(false)).toString().

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

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.

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.

Out of interest what does F.e. mean? You seem to be using it in place of the usual e.g.

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.

thanks for pointing it out. I wasn't aware that f.e. is not accepted as standard english abbreviation.

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

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.

Interesting. Most references that I found say that f.e. is not correct. ;)

For example, probably.

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

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.

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.

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), 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!

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.

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

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

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