JavaScript Trends Friday, 30 May 2008

I came across a blog post yesterday that had a lot of misinformation. The post had received several comments and trackbacks thanking and commending the author for his "helpful" post. At first I was mad. "How can these people give this guy credit for misinformation," I thought. I wrote up a comment correcting on various points, intending to publish it on the author's blog.

Thankfully, my comment could not be posted due to some problem with the weblog. I am thankful of this because I ended up thinking about the problem on a greater depth.

I decided to respond here, providing a review below. I was more bothered by the phenomenon of people eager to learn misinformation. The more I thought about that phenomenon, the more I realized that it's not the author's fault, it's just the way things are. I discovered a part of the web that I want to change.

The expert, in this case, is Alex Russell, of Dojo fame, as Ajaxian likes to call it. It doesn't really matter who it is. In fact, it could have been me several years ago, when my JavaScript knowlegde was not as strong. I have written some really awful javascript that fortunately did not become famous.

My initial technical responses to the blog entry, which I have cut and snipped, are interspersed below. I have done my best to not take the author out of context and provide clear, relevant feedback. My real "response" starts below the proceeding technical response.

Technical Response

alex:

Everything in JavaScript is an Object. Even functions

Not true.

Fact: There are primitive values, too: undefined, null, true, 3, and "foo" are all primitive values. Not objects.

alex:

Every object is always mutable

Fact: An EcmaScript object itself is always mutable, but property-setting will not be always successful and error-free.

1. Host objects do not need to implement setters for each property. For purpose of providing a relevant example to back up my claim:

   function fixEvent(e) {
     e=e||event;
     e.pageX = 1; // getEventPageX(e);
   }

   - will cause an error in Firefox. The pageX property actually needs a patch, because creating events, the pageX property doesn't get set correctly (bug 411031). So the argument "every object is always mutable" leads to developers doing things like writing a "fixEvent" function. It is not safe to do so.

2. Some properties are tagged ReadOnly. A String or Function object's length property, for example.

alex:

The dot operator is equivalent to de-referencing by hash (e.g., foo.bar === foo["bar"])

Fact: The two property access operators .<Identifier> and [<identifier-string>] perform identical operations.

alex:

The new keyword creates an object that class constructors run inside of, thereby imprinting them

False.

Fact: There are no class constructors. No classes in the current release of EcmaScript 262 r3.

The new operator (an operator) creates a new object in context of the function on which its called. Nothing gets imprinted.

alex:

Functions are always closures (combine w/ previous rule to create OOP)

If used very carefully, closures can be used to mimic some of the constructs found in OO languages. However, to say that closures "create OOP" is false and misleading.

alex:

The this keyword is relative to the execution context, not the declaration context

There is no "declaration context". You seem to have made this up as a way to describe the way you think JavaScript works.

alex:

The prototype property is mutable

Not informative.

Fact: A property is a reference.

If the property's value is a native EcmaScript object, then it will be mutable. It goes without saying that this is true even if the name of the property is prototype.

Considering a prototype property of a function, where the prototype's value is an EcmaScript object: {}, then it is mutable (as discussed above).

alex:

Jeremy: great clarifications. Thanks.

Jeremey provided a false statement with code that was confusing. Jeremey wrote:

y = new Foo();
assert(y.gimme() == 2);

But:

button.onclick = "alert(y.gimme())" will error rather than alerting "2", because in an event handler, "this" refers to the elm which sourced the event.

Fact: This is a perfectly valid assignment of a string value to an onclick property of a button object.

Jeremy's example of a button object with an onclick property assigned to a string value:-

button.onclick = "alert(y.gimme())"

- the string "alert(y.gimme())" is not eval'd.

(Continuing Jeremy's post)

because in an event handler, "this" refers to the elm which sourced the event.

Has relevant meaning in a script:-

// assign function to onclick.
button.onclick = y.gimme;

Definitely not in:

<body>
<script>

function Foo() {
this.x = 1;

this.gimme = function() {
return this.x + 1;
}
}

y = new Foo();
</script>

<button onclick="alert(y.gimme())">click me</button>

</body>

Result

When the button is clicked, the method gimme is called with y as the thisArg. The number is returned and displayed as a string in the alert box.

Thanking Jeremy for Jeremy's mistake and calling the mistake a clarification does not make Jeremy correct. It is not helpful to Jeremy or anyone else.

alex: (To Dethe):

My statement about objects (variables whose .constructor property in some way descends from Object) was correct.

Fact: No, it was not correct. Now you've made another misstatement.

Fact: (new function(){}) - is an object, not a variable. Its - constructor - property doesn't "descend" from Object, either.

Fact: var i = 0, len; - is an example of two variables that do not have a .constructor property.

Fact: The term "descend" has no meaning in context of describing a constructor property; it is fictitious terminology to describe the way you imagine JavaScript works.

(alex: To Dethe, continued):

Also, the hash deference is exactly equivalent. That there's no way to have a JS lexer handle an variable name with spaces in it in no way detracts from the equivalence, it just means that the dot operator has to follow the rules of thing that aren't string literals.

Fact: There is no "dot operator."

Fact: The fullstop, "." also has meaning in numbers, for example, 4.2.toString().

Fact: There are two property access operators: "." and "[]". There are many "things that are not string literals." The "." property access operator can be used only for valid identifiers.

I think you were using the term "de-reference" to try to describe getting a value. Now your using "deference". I'm not sure what to make of that.

The Real "Response"

My real "response" in the larger sense, is that I'm taking a stance. I'm going to try and change the web.

Think 2.0

A who's-who in web 2.0 is destructive to the web, in a way. The idea should win, not the individual. The popular libraries have spread ideas for web development across the web but they have also played a big part in the "whos-who" trend that I see.

What I see demonstrated in the blog entry that I replied to is a misunderstaning of JavaScript that received positive acknowledgement and review. The question is: Why? Is it because the entry is simple and clear?

Ask Why

If a "famed" individual can be commended for teaching JavaScript facts that are false and inaccurate, what does that say about what web developers value in the web? Where are we headed? I am hoping that this trend will reverse itself. The reversal of this trend starts by questioning things. I question things and you should, too.

Angry, Bitter, and Vile?

As much as I've pointed out bad parts of Dojo and Google (And jQuery and PrototypeJS and YUI), I probably sound like a bitter, angry person. In fact, there are people who would love to have you believe that I am nothing more than that. I've made my observations and shared them, even at the expense of sounding mean and bitter. I want the web to change, and in my next entry, I'll clearly explain the direction I want the web to turn.

Technorati Tags: JavaScript