I have closely followed the development of the ECMAScript Edition 4 almost since it was announced. At first, the premise sounded pretty good: keep the good bits, sort out the bad bits, and add some syntactic sugar here and there. That’s still basically what ECMAScript 4 or JavaScript 2.0 is, but I’ve now come to the conclusion that the changes they have made to the language will actually make things worse.

JavaScript 2.0 is largely downwards-compatible with previous versions of the language, but if you look at JavaScript 2.0 source code and compare it to let’s say JavaScript 1.5 source code, you will notice that the two bear little resemblance. This is mostly due to two things: classes and type-annotations. Previous versions of JavaScript centered their view of the world on objects rather than classes, very much like Self and very much unlike Java or C#. Objects can inherit from other objects using a concept called prototypes, a language feature JavaScript also shares with Self. The problem with prototypes is that most people who come from a Java or C# background will find the concept hard to grasp. Also, the implementation of prototypes in JavaScript is not very straightforward and using prototypes the way it was probably intended is cumbersome. For example, using prototypes doesn’t mix very well with encapsulation. There are means of overcoming this limitation, but they’re not very pretty from a syntactic point of view. On the other hand, its prototypical inheritance is the main reason why JavaScript still works so well, despite the fact that it’s now being used for things it was never intended to do.

When I heard JavaScript 2.0 supported classes, my initial thought was “that’s probably a good idea” and I’m sure Brendan Eich and the other people working on ECMAScript 4 added that feature, thinking it would make people’s lives much easier. My feelings about classes in ECMAScript are a little different now, but let me talk about something else first.

JavaScript has always been the poster child of dynamically-typed programming languages, for all the good and bad it brings with it. ECMAScript 4 adds type-annotations to the language turning it more or less into a hybrid language that supports both dynamic typing and a form of static typing. Why would they add that to the language? Probably because there is this myth that static typing avoids a whole class of runtime errors. I’m certainly not denying that static typing has its advantages, but I would argue that the problem of runtime type errors is often largely overstated (especially because unit testing tends to catch the majority of type errors). Another motivation for adding type-annotations to the language could be that it allows for a different kind of polymorphism that is method-overloading. Of course in a dynamically typed language, all methods are polymorphic by default, so all method-overloading really does is help you get rid of certain if-statements.

Everything I’ve talked about so far is mostly a matter of my personal preference and I wouldn’t have written the blog post if that was all I had to say about ECMAScript 4. The new additions the language are mostly optional meaning you can use them if you want to, but you can also keep programming JavaScript 1.5-style. Here’s the thing though: a non-JavaScript programmer’s first reaction to the language has always been “this looks exactly like Java”. After some time tinkering with the language however, people would usually realize that the language is really not at all like Java. And so they would learn about the language’s unique traits and realize that in many ways, JavaScript is actually more expressive than Java. With ECMAScript 4, not only does the language look like Java, you can actually get away, only ever understanding the Java part of it. Never mind that JavaScript has closures, prototypes, on-the-fly-objects and other interesting stuff. Now it’s become just another somewhat statically-typed object-oriented programming language. Am I being over-dramatic? I think not. Just take a look at ActionScript 3, the ECMAScript 4-inspired scripting language that powers Adobe’s Flash and Flex. Every ActionScript 3 program I have ever seen, on the source-code level looked exactly like every Java program I have ever seen. They’re full of design patterns, most of which were invented to overcome the limitations of statically-typed languages. If you think that’s absurd, listen to this: just as we’ve learned to appreciate the convenience of duck-typing, ECMAScript 4 adds interfaces to the language. Want more? Parameterized types! That’s right, because ECMAScript is semi-statically typed now, it needs to loosen the type system again by introducing generics.

JavaScript as it is right now is far from being perfect and I do agree that it’s time to address some of the language’s problems. And yes, I acknowledge that ECMAScript 4 does improve the language in many ways, but the language wasn’t all bad and turning it into another Java simply doesn’t do it justice. The specification of ECMAScript Edition 4 is expected to be finished in October and it will probably be another three years until a big enough share of browsers will support it, but it looks like classes and type-annotations are here to stay. I can only hope that developers will stick to what they know and exploit some of JavaScript more distinctive features, but if it goes down the same road as ActionScript, we’ll soon all be writing Java in JavaScript.