
JavaScript Garden - mhr_online
http://bonsaiden.github.io/JavaScript-Garden/
======
olavk
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
Yeah. I believe that false.toString() is "actually" something like
(Boolean(false)).toString().

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

------
acjohnson55
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!

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

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

~~~
Raphmedia
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
thanks for pointing it out. I wasn't aware that f.e. is not accepted as
standard english abbreviation.

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

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

------
keithwhor
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...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Object/create)

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

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

