JavaScript 2.0: Why Give Programmers Crutches?
[Guest Comment from Shane Steinert-Threlkeld]
A new spec on which JavaScript 2.0 will be based , should be finalized by the end of the fall. Yet most of the proposed changes do close to nothing to actually improve the language.
A lot of developers of so-called Rich Internet Applications, from widgets to online versions of desktop programs such as word processors, are very excited about this new release because it should make make it easier to just pull different nuggets of pre-produced code into their new Web-based services.
But most of the proposed changes, summarized well by Jeremy Martin, seem to act mainly as crutches for programmers in other languages (read: C# and Java) to use JavaScript.
The biggest change is the implementation of true class-based inheritance, where new sets of programming objects with similar structure and behavior derive much of their functionality from previous classes of objects.
This is a change that people have been wanting for some time: You don’t have to build new combinations of data, procedures and uniqueness, for each object you might want to be used.
But it is not needed. With JavaScript, you just use another object as a prototype, clone it and then make it unique. Such prototypal inheritance can effectively mimic class-based inheritance, without creating classes, in more than one way. See Dean Edwards’ base2, qooxdoo, Prototype for a few implementations.
Most of the changes in the new specification have the same flavor as this one: they turn JavaScript into Java, an object-oriented programming language that relies heavily on classes. JavaScript, on the other hand, is more flexible in allowing the programmer to define and manipulate objects every which way. While standardizing this may sound great on paper, this is only because people have not taken the time to fully appreciate JavaScript’s prototypal inheritance.
Some of the functions that make the next rev of JavaScript more like Java are how it classifies types of values and formulas as well as how it maintains constants and namespaces. While many people prefer the programmatic rigor that these create, neither static typing (optional) or constants add serious functionality to an already well-written JavaScript program.
Douglas Crockford: "JavaScript - The Good Parts" @ Yahoo! Video
That last link comes from Douglas Crockford, long a proponent of JavaScript as a serious programming language to be used for more than cute image rollovers and the like.
Having spent more than 250 hours (so far; still developing) this summer programming a math and 3D rendering library in JavaScript, the dynamic and flexible nature of JavaScript’s prototypal inheritance and object model (everything is an object in JavaScript) is a practical, fundamental advantage. Why someone would want to take something so elegant and flexible and turn it into Java – which essentially forces a programmer to use classical, class-based inheritance-- is beyond me.
The biggest benefit that I see is that it will lower the entry barrier into JavaScript development for folks with a classical programming background. Who knows if that’s even a good thing?
It has been said that “JavaScript is a mirror that reflects who you are as a programmer.'' JavaScript is so dynamic that you can program in a step-by-step procedural manner, in a prototypal manner, or using class-based methods if implemented properly.
The upcoming JavaScript 2.0 seems to be turning JavaScript from a mirror of a programmer’s skills to a cookie-cutter method of creating unoriginal code. It replaces multiple ways of programming with just one.
Let’s hope that the release will be backwards-compatible, allowing prototypal inheritance, at least, to survive.
And programmers to stay off crutches.
Shane Steinert-Threlkeld is a student of math, computer science, and philosophy at Johns Hopkins University. He is also a semi-professional web developer and consultant with his own opinions.