I think this wording is misleading:<p>> Everything in JavaScript acts like an object, with the only two exceptions being null and undefined.<p>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.
Section on <i>null</i> seems off to me.<p>> in almost all cases, it can be replaced by undefined.<p>Null has a subtle relationship to Object in that<p><pre><code> typeof null == 'object'
</code></pre>
For that reason, null should be used for values that can be optional references to Objects (or null).
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é (<a href="http://leanpub.com/javascript-allonge" rel="nofollow">http://leanpub.com/javascript-allonge</a>), 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!
Sometimes I have the feeling they are a bit over the top.
F.e.:<p>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.<p>The conclusion doesn't offer any advise what should be done instead of eval.<p>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.<p>F.e.
- if you want to evaluate a lambda function given from the command line.<p>- if you want to execute javascript provided by a user in a browser window.
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:<p><pre><code> // Set Bar's prototype to a new instance of Foo
Bar.prototype = new Foo();
Bar.prototype.foo = 'Hello World';
</code></pre>
Is an antipattern. Use<p><pre><code> Object.create()
</code></pre>
to set up your prototype chain, i.e.:<p><pre><code> Bar.prototype = Object.create(Foo.prototype);
Bar.prototype.foo = 'Hello World';
</code></pre>
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, [...]).<p>Object.create is supported by all modern browsers, and the Object.create polyfill can be found in Mozilla's documentation:<p><a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...</a>
On this same subject, an excellent read is JavaScript: the Good Parts. <a href="http://shop.oreilly.com/product/9780596517748.do" rel="nofollow">http://shop.oreilly.com/product/9780596517748.do</a>