Code Conventions for the JavaScript Programming Language

    document.getElementsByClassName("externalLinkBig")[0].setAttribute(
        "class", "externalLinkSmall"
    );

I can't speak for Crockford, but I would note that "function foo() = {}" is equivalent to "var foo = function () {}", so it may be for the same reason for declaring global variables up top.

You simply don't document the "private" properties. Pretending JavaScript is more robust than it is helps no one and wastes memory.

I don't think we're talking about the same thing. I'm talking about private variables, the same way they are used in other programming languages: variables that cannot be accessed from outside the object. When you try to access private variables in other languages it throws an error, and you want it to throw an error, that's why you make it private. You don't want it accessed. Crockford shows how you can do that in js. Consider this version of the code you gave:

function Point(x, y){ this._x = parseInt(x,10); this._y = parseInt(y,10); var _private = 'foo' } Point.prototype = { get x() this._x, set x(v) this._x = parseInt(v,10), get y() this._y, set y(v) this._y = parseInt(v,10) }

var myPoint = new Point(100,50); alert(myPoint._x); alert(myPoint._private);

The last alert will show 'undefined', that's intentional.

Const is not supported in IE (https://developer.mozilla.org/En/Core_JavaScript_1.5_Referen...), and wasn't originally supported in js.

I've already pointed out that there is already a common, testable convention in place: if((a = b))

Avoiding assignments in conditionals is general advice in more than just one language. Besides here's what Mozilla says about it:

assignment in a conditional (Note: you can suppress this warning by including an extra set of parentheses around the assignment) (https://developer.mozilla.org/en/New_in_Rhino_1.6R6)*

Also:

It is advisable to not use simple assignments in a conditional expression, because the assignment can be confused with equality when glancing over the code. For example, do not use the following code:*

If you need to use an assignment in a conditional expression, a common practice is to put additional parentheses around the assignment.

In other words you can put () around the assignment, but that doesn't mean you should or that it's a best practice.

Crockford literally wrote the book on JavaScript, and I've seen his defense of some of his coding conventions in various talks, so I'm inclined to give him the benefit of the doubt. If you disagree with some of them, hell, email the guy. He might explain it in better detail.

Which is an irrelevant point anyway since it still doesn't justify hijacking an already commonly accepted convention for some other purpose.

"In other words you can put () around the assignment, but that doesn't mean you should or that it's a best practice."

The point is that the meaning is clarified by using the convention.

"It is advisable to not use simple assignments in a conditional expression,..."

I would not presume to know what level of brevity is desirable for a developer in a given situation. Conventions like the one mentioned are available for clarification of such constructs.

"Crockford literally wrote the book on JavaScript, and I've seen his defense of some of his coding conventions in various talks, so I'm inclined to give him the benefit of the doubt."

Accepting an argument based on perceived authority is a logical fallacy. "the book on JavaScript" has some questionable things as well I hear:

    Function.prototype.method = function(name, func) {
        this.prototype[name] = func;
        return this;
    };