Javascript: A Language in Search of a Standard Library and Module System

  1. Array
  2. Boolean
  3. Date
  4. Error
  5. EvalError
  6. Function
  7. Math
  8. Number
  9. Object
  10. RangeError
  11. ReferenceError
  12. RegExp
  13. String
  14. SyntaxError
  15. TypeError
  16. URIError

Recognize that? Yes indeed, it’s the complete list of standard Javascript objects of Javascript 1.5. 16 objects, of which 7 are error objects. Of course, this is just the Javascript language by itself. In practice Javascript executes inside a browser, which gives it access to additional objects like the DOM, and all kinds of fancy HTML5 and non-standard browser-specific features.

When Javascript was just a little language that people would use to do simple mouse-over events, this was not a problem. However, now, more and more applications are written in Javascript in the browser and Javascript is used in more and more places other than the browser. Better yet I dare to bet you that in a few years time Javascript is going to be one of the most used programming languages in a growing number of domains. The growing body of Javascript code also means Javascript needs more than just those 16 objects. It needs a larger standard API and it needs a standardized way to modularize code.

At the very least it needs a de-facto standard way of doing object-oriented programming, having the choice between classical, prototypal, or, sure, why not lazy inheritance is not doing it for me. Different libraries use different styles. Worse yet, different libraries develop their own utility objects to produce classes, and if they’d at least agree on a common way of doing that, but no, there are a few dozen different way of implementing exactly the kind of inheritance you like. I’m not the biggest fan of Java, but at least they made a decision on this at the language level.

But I’m getting side tracked. The main two things Javascript needs to be a proper language that we can apply "grown-up" software engineering principles to:

  1. A standard library
  2. A module system

First, the standard library. Those 16 objects are no longer sufficient. So, what happens is that programmers step in to build a larger, more extensive library of objects. It would be great if they all teamed up to come with the one framework that everybody uses, but of course they didn’t, so we now have Prototype, MooTools, jQuery, MochiKit, ExtJS, YUI, Google Closure, and I’m probably forgetting about a dozen. This divides the Javascript world into different camps. Either you’re a jQuery guy or a Prototype guy, a ExtJS guy or a MochKit guy. There’s a YUI-y way of doing things and a Prototype way of doing things. There’s a jQuery calendar, an ExtJS calendar, and a Prototype calendar. Of course, once you picked a framework you stick to it, because if I want to use a prototype calendar from my jQuery application, I have to pull in x kilobytes of additional code that essentially duplicates jQuery functionality. A lot of effort is wasted because of this.

What Javascript’s standard library should contain is pretty tough thing to determine. First thing that comes to mind is a set of standard data structures. Of course Javascript has arrays and objects. Objects are typically also used as maps (although the keys can only be strings, and not even all strings) and sometimes even as set (where the property names represent values).

A better library of data structures is required, including a proper map and set implementation. Additionally, APIs for other common tasks such as:

Some stuff like DOM traversals, querying and widgets will be hard to agree on probably, but would be nice to have.

Because Javascript is increasingly being used as a non-browser language, for instance on servers, it will also need non-browser stuff like IO, inter-process communication, sockets etc. The CommonJS initiative is working on these. CommonJS is an initiative, mostly among Javascript server vendors, to agree upon certain standard interfaces to, e.g. IO, threads, sockets etc. Its main contribution to date, however, is its module system.

Javascript does not have namespaces, but you can use objects for this purpose. That’s fine. In the past, some frameworks have built their own module system around this. Dojo and Google Closure offer a remarkably similar API to export and load modules:

dojo.require('dijit.widget.Editor');
dojo.require('myproj.Something');
dojo.provide('myproj.MyObj');

myproj.MyObj = function() { };
myproj.MyObj.prototype.initialize = function() { ... };

Replace ‘dojo’ by ‘goog’ and you basically have the Google Closure version. Quite nice and reasonably clean. However, there’s also JSAN’s module system. CommonJS’s module system is really nice, however according to some reports cannot be implemented in the browser properly. There’s an asynchronous version of the CommonJS module system called RequireJS, but, well, it’s not the CommonJS standard. There’s a proposal to standardize the RequireJS system as part of CommonJS, but it’s not entirely clear what the status is of that proposal.

I feel these issues have to be resolved and the good thing is that it does not require any changes in the Javascript language itself, nor its browser support. If the different framework vendors would just agree on a single base library that they all use, because, let’s face it, everybody needs a function to trim strings and a proper set implementation, a clean way of doing inheritance, plus a module system to go with that, be it dojo/Google’s system or a CommonJS variant, I don’t care.

It would be oh-so-nice to have a de-facto standard library for this stuff.