A Bright Future for Standardized Server-Side JavaScript

The new ServerJS discussion group has exploded. In only one week, 209 members have joined and 644 messages have been posted. At times the #serverjs channel on irc.freenode.net has been too busy to read every message. It seems many web programmers are interested in standardized server-side JavaScript.

Kevin Dangoor of Mozilla's new developer tools group instigated things. Many of the active members are implementors from projects like Helma, Persevere, Cappuccino, Rhino, and more. At least a couple ECMAScript committee members have already been encouraging compatibility with possible future ECMAScript standards. There are a lot of heavy hitters on board.

The group's main goal is a specification for a standardized API: file access, database interaction, http request object, etc. Various projects can build implementations based on different JavaScript engines (e.g. Spidermonkey, WebCore, V8, Rhino, etc). Code that works on one implementation should work on another. For example, code could be moved from a Java web server running Rhino to Apache with mod_js based on Spidermonkey. The ability to share code means server-side JavaScript programmers even on different projects can finally work together to produce a large body of community code.

So far module systems have been the focus of group discussion. This is foundational to all work to follow and affects how the code is written and can be shared with the browser. How does one module of code load a dependency module? In which scope are the imported variables available? The current proposals fall into two camps: global eval and Pythonic. JavaScript in the browser uses a global scope where all files are evaluated in the single global scope. It is simple to understand but namespace collisions and large scale projects are potentially difficult to manage. Alternatively, Python has a concept of a module (a.k.a. file) scope and a dependency module can be imported into that scope. Importing makes the imported module visible only in the importing module's scope. Although unfamiliar to many JavaScript programmers, module scope is ECMAScript compliant. The Pythonic system confines modules in their own namespace which makes large projects easier to manage perhaps at the cost of a slightly more complex mental model and perhaps makes sharing code with the browser more difficult. Proponents of both types of systems have made proposals on the group wiki.

A secondary goal for the ServerJS group seems to be actualizing that specification in code that you can download and use to build applications. Think CPAN for JavaScript. Mozilla has already agreed to host a package repository. Mozilla! That is a brand name that your project manager or CTO might be willing to trust.

That's a lot for a first week!

If you think running JavaScript both in the browser and on the server could be good for your applications then I encourage you to join the group and help shape the future of server-side JavaScript.