Battle 4 ECMAScript 4

Reading articles like the Mozilla, Microsoft drawing sabers over next JavaScript evoke all kinds of sadness and frustration in me. I don't think the creator of JavaScript, Brendan Eich, is happy with the language he birthed and doesn't appreciate its unique beauty as some of its adopters, myself included, have. Many people will disagree with me on this, but in general I am guessing most people's beef with JavaScript is not the core syntax, but rather developing within the constraints of the web browser and dealing the different DOM's all without a decent debugger, things which I can totally sympathize with.

JavaScript 1.x (ECMAScript 3) is more than a toy to annoy and it isn't just AJAX. It's a simple and flexible object-oriented programming language. It doesn't have class-based inheritance, but once I broke through that barrier into the fluid realms of prototype-inheritance, I have never once wanted to go back.

JavaScript's (ECMAScript 3) weak points to me are its underlying core library of functionality, the lack of some methods for high performance string/byte manipulation especially for extremely large blobs, and a standard function for creating low-level objects. For the latter I side more with Microsoft's approach with Server.CreateObject, WScript.CreateObject, or new ActiveXObject because you can override any of those with your own function and intercept the calls to do whatever you need to based on the platform. I love the amount of native objects I get with Mozilla/XUL development, but the process for scripting their XPCOM objects is horribly verbose and smacks of stricter languages (Java, C++, C#, etc.) that this one normally does so well to get away from. I mean, check out this snippet of code for writing out a plain text file:

var file = Components.classes["@mozilla.org/file/local;1"].createInstance(Components.interfaces.nsILocalFile);

file.initWithPath("test.txt");

if (!file.exists())
file.create( Components.interfaces.nsIFile.NORMAL_FILE_TYPE, 420 );

var outputStream = Components.classes["@mozilla.org/network/file-output-stream;1"].createInstance( Components.interfaces.nsIFileOutputStream );

outputStream.init( file, 0, 0 );
var result = outputStream.write( "Blah blah blah", 14 );
outputStream.close();

Now compare that to this code run by CScript (WSH) to do the same thing:

var fso = WScript.CreateObject("Scripting.FileSystemObject");
var file = fso.CreateTextFile("test.txt", true);
file.Write("Blah blah blah");
file.Close();

I could've also used ADO.Stream if I wanted to use UTF-8 instead of ISO-8859-1 for the character encoding, but FSO works for most small scripts.

Also, the simple flexibility that I mentioned briefly above allows for some emergence and creativity you just don't see in other languages. For example, you can create your own "class" instance in any number of ways, but the client code will use it the same regardless. Beyond the basic keywords, you really just need to know that everything is a first-class object and you can attach/access/modify properties through the dot/period operator.

Finally, there is a subtle concept of types behind the everything-is-an-object model whereby you can see what something is by looking at its constructor property. The duck typing is (if it walks like a duck, talks like a duck, then it's a duck), I believe, what affects most people into believing the language is rubbish. Ironically, I see strongly-typed languages trying to work their way towards such "typelessness" (Java Generics / C# Nullable Types) and script trying to pull out of it (ActionScript 3, ECMAScript 4, PHP 5).

I don't mind progress, but do we have to change the philosophies and purpose that these various languages are built on? Let's embrace the differences between languages and work on better interoperability instead.