[yuchi]

I'm ashamed that a lot of rants about languages get so many points here on HN. This article, in particular, is written by a JavaScript ignorant, which for the first time approaches the language. Even worse, "JavaScript the good parts" is a good read, but it shouldn't be promoted as the _de facto_ bible of JavaScript as it is: it's old, outdated, lacks a lot of the recent changes and promotes a lot of patterns which became anti-patterns.

An example of my last sentence: have look at how Titanium SDK (v2.1.x) folks designed their "parasitic inheritance" architecture following Crockford's book. A terrible, unusable, instable, un-hackable (wrong) use of JavaScript.

EDIT: I don't know if Steve Kwan is actually a _noob_ or not, but it looks like. Eg:

    identifier = function () {};

this is not one of the examples of "ways to create a function". This is actually an assignement using a function expression. These are the 3 REAL ways:

    // As expression, in an assignement or as argument.
    (function () { /*...*/ });
    // As expression, but with a name given to it.
    (function $identifier$ () { /*...*/ });
    // As a declaration, which gets HOISTED!!
    function $identifier$ () { /*...*/ }

[yuchi]

Addendum. Oh gosh:

    var someObject = new Object();

Is that real?

[stevekwan]

I did not put that there because it was the best syntax. :) I put it there because I felt it was most likely to be understood by someone new to the language. I assume you're implying I should have used {}?

[yuchi]

Yes, not for the syntax itself, but for a mere "smell" of code quality. The use of "new Object" is found only in two kind of JS code incredibly old or incredibly badly written.

[stevekwan]

I hear you completely. But understand that my intent here was not to write idiomatic code, it was to write code that an outsider to JavaScript would understand. I worry that the {} syntax, while simple/elegant/preferred, may be somewhat less obvious to a new person who is unfamiliar with JavaScript's object literals. In any event, I've updated the article to include both ways.

Regarding variable hoisting, I am trying to keep this article short, concise, and focused on the big offenders when it comes to gotchas. The only reason I didn't discuss hoisting is because I felt it would introduce too many concepts at once. To me, hoisting is kind of "level 2," whereas understanding why var is required is "level 1."

And on a side note, I appreciate all the feedback you're providing here - I really do. That's why it's on GitHub and not some blog somewhere. But I would suggest that we separate personal attacks from code criticisms. If you don't like my approach with this article or you find something that's flat-out incorrect, by all means tell me. As a human I am prone to make mistakes - maybe moreso than others. :)

But please avoid making value judgments about a person you don't even know, such as calling them an ignorant. It's bad enough when people behave this way on the internet, but if that kind of mentality starts to seep into your "real world" life too, it'll start having serious effects on team relations and employability.

[yuchi]

I'm sorry for my personal stakes at you. And honestly I have to say I'm biased against javascript articles, because I'm so used to find a strong lack of experience and knowledge in them. I appreciate your answer, and please pardon my rudeness.

At the same time you could make a "level 1" article a lot more adherent to reality. For example, you could completely jump over that "function creation" section entirely, and simply do a clear explanation of what an expression is in JavaScript, and how to spot them.

Again, thank you for your personal advices, and thank you for your politeness (as opposed to my manners).