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.