Preston L. Bannister { random memes }

Seems the prior post gathered some response.

To set expectations – this is my personal weblog. What I put here is the bits that (to my mind) might be otherwise missing. I am not interested in repeating material covered elsewhere. If you are already well-read, then I hope these bits will nudge your thinking forward a bit (even if you do not entirely agree with my conclusions).

On the other had, if you are seriously short of clues, I am not going to help you. Spent enough time on USENET News (long ago) to note the point of diminishing returns. Since I write these bits as an entertainment (of sorts), I am not going to invest a lot of time with folk who are too many laps behind.

Javascript is at heart a dynamic, prototype-based sort of object-oriented language. Most folk coming to Javascript are acquainted with static, class-based languages – and have little or no experience with anything different. The natural inclination is to transfer learned habits from the old to the new language – and that is a mistake.

Back in the late-1980′s or early-1990′s one writer came up with a classification scheme for object-oriented languages. There were many variations proposed and explored in that time, so a scheme that enumerated the important aspects was very useful. (Wish I knew how to find the article – it was in an ACM or IEEE publication of that period, I believe.) As a guess, I suspect that most of the current generation of programmers is not aware of the possible variations, and assume all object-oriented languages must be like Java / C++ / C#, and expect the same learned habits to still make sense with Javascript.

Disregarding the usual noise, there is one bit which it is worth responding, as it (quite unintentionally) illustrates my point.

New gives you prototype inheritance, performance benefits, and it’s about language semantics.

That is exactly my point! … only the reality differs from the assumptions of the guy making the comment (and I suspect he has a lot of company). Back in the late 1980′s / early 1990′s the pragmatic consensus was to move forward with object-oriented languages that could be made to run efficiently on the then-current hardware. How to generate optimal code for static class hierarchies was fairly well understood, at that time. More dynamic object-oriented languages were simply too hard to optimize.

The v8 Javascript engine offers a good example. The combined memory and CPU footprint of an efficient Javascript engine was simply impossible on circa-1990 computers. What is practical and reasonable on current-generation computers was – twenty years back – completely not practical.

My reading of the articles on the current-generation Javascript engines was that the toughest problem – and main aim of implementors – was to optimize in the absence of static-class hierarchies, and that quasi-static classes are not particularly optimized.

This makes sense. Writing script for web pages is programming in the small. The number of entities on a web page is small, as are the number of repeated instances. Static classes with efficient support for huge numbers of behavior-identical instances are essentially useless in a web page. If you are creating large numbers of instances for a web page, you are almost certainly doing it wrong. (Note the “flyweight” class pattern is useful here.)

My assumption (from what I have read) is that “static” class hierarchies yield no particular benefit in client-side Javascript.

Assumptions should be checked … so I wrote a micro-benchmark.

Method dispatch – Microbenchmark – Javascript
The aim was to measure method-dispatch for three cases:

1. The method is bound to the instance.
2. The method is bound to the “class” (via the __proto__ member).
3. The method is bound to the “class” (via the function invoked via new).

What I see (in terms of exact results) will likely vary as each browser vendor tweaks their Javascript engine. The point – in the case of the current discussion – is that static class hierarchies yield no significant advantage. It does make perfect sense that static-class languages can deliver bare-hardware performance numbers (which I do expect to use). For web page script, I expect static-like class usage to yield no significant benefit.

For programmers coming from C++/Java/C#, the notions that made sense no longer apply. Thus the emphasis on denying any semblance to static-class languages. This was exactly my point.

A small item…

Javascript is a hash (pun not entirely intended). There are good parts to Javascript, and bad parts. For folk attempting to learn Javascript for the first time, they could use some help avoiding the icky bits.

My first cut at rules for a “strict” mode for Javascript:

• No use of “function name(){}” declarations
• No use of “document.write()”
• No use of “new”

No doubt I could come up with more rules, with a bit more reflection, but this is a start.

No use of “function name(){}” declarations
There are two means of declaring functions, and I strongly prefer the second form. Programmers coming from other languages tend most often to use this form:

function foo() {
}

For an entire collection of reasons I prefer this form:

var foo = function() {
};

The second form is better suited for later refactoring, and offers subtle emphasis to the learning programmer of the difference offered by Javascript. The first form can also lead to subtle bugs (which I do not want to explain) – certainly not what you need when first learning a rather different language.

As a partial hint, I tend to make rather a lot of use of namespaces, so my function declarations most often look like this:

var ZOT = {};
ZOT.foo = function() {
};

Or in the more elaborate use:

var ZOT = (function() {
    var foo = function() {
    };
    return {
        foo: foo
    };
})();

This last form makes full use of closures, and allows for private data and functions.

No use of “document.write()”
Programmers tend to want to generate HTML from program code. This is a huge mistake.

To me this is a classic application of separation of concerns. HTML describes page structure. CSS describes page presentation. Script describes dynamic behaviors. Best to keep each concern separate.

No use of “new”
On this point I am certain others will differ. They might even be right. Certainly the “new” operator is of huge advantage in static languages. But that is not the domain of Javascript – certainly in the web browser, and possibly even for server-side usage.

The “new” operator misleads programmers when first learning Javascript. The pattern of usage most appropriate to a static-class language is not the same as the most appropriate usage in an entirely dynamic language.

Conflicted over Crockford
There is a measure of irony in the last point. Douglas Crockford has consistently served to promote better usage of Javascript. Crockford was hired by Yahoo. The quite elaborate user interface library in Javascript developed by Yahoo, is first invoked with “new YUI()”. YUI obviously represents a substantial body of work, at least partially in what seems the right direction. Yet I cannot yet quite get past the beginning.