Some server-side JavaScript prospects

[Colin Clark]

Hi all,

As you know, we're still in the midst of evaluating technologies for  
the Fluid Engage services layer. The services layer is the part of  
Engage that is concerned with managing and sharing data throughout the  
system. It will import and share data from collections and content  
management systems, and will also provide connections to the social  
networking and collaborative features of Engage. In short, the  
services layer is the place where we share information about exhibits,  
offering features such as search, tagging, commentary, and so on.

Our goal is to build a system that is lightweight and approachable,  
using a familiar dynamic language that is well-suited to the  
functional and declarative approach we've used with Infusion. At this  
point, I've pretty much narrowed the choice of programming language  
down to two: Python and server-side JavaScript.

As many of you will remember from recent architecture meetings, we've  
had some concerns about the prospect of server-side JavaScript;  
namely, the lack of existing web container infrastructure and issues  
around performance and threading. On the other hand, using JavaScript  
on the server would allow us to reuse many of the features in  
Infusion--particularly the Renderer and ChangeApplier--to build rich  
applications quickly.

I recently stumbled across a few tools that appear to make JavaScript  
on the server more viable. It all starts with the ServerJS group at  
Mozilla, a team working to define a base set of specifications for  
server-side JavaScript environments:

https://wiki.mozilla.org/ServerJS

Among other things, this group has developed a standard for loading  
JavaScript code as self-contained, packaged modules:

http://askawizard.blogspot.com/2009/03/interoperable-javascript-modules.html

They've also defined a standard library for doing things like  
accessing files, making HTTP requests, and so on. A promising  
implementation of this standard library and module system is Narwhal:

http://narwhaljs.org/

Most importantly, they've also developed a standard web container  
contract called JSGI. It provides a simple, low-level API for how  
requests and responses are processed in JavaScript. It is analogous to  
standards in other languages--WSGI for Python and Rack for Ruby. JSGI  
ensures that we'll have a viable model for porting code between  
JavaScript runtimes:

http://jackjs.org/jsgi-spec.html

Jack is an implementation of the JSGI spec, providing adaptors for  
several prominent servlet containers using Rhino, as well as the v8cgi  
project, a FastCGI adaptor for Google's V8 engine. Jack promises to  
get us up and running fast with JavaScript on the server, starting  
with the JVM for simplicity:

http://jackjs.org/getting-started-with-jack.html

To be clear, this stuff is still incredibly new, but it represents our  
most viable option for running JavaScript on the server. I've been  
doing some early experiments with Jack, and Michelle has picked up  
this work and is starting to run performance benchmarks on the  
platform. From there, we'll sync up with David's work writing a data  
importer for McCord's XML in JavaScript, and get a better sense of how  
viable this is. At the same time, Yura is cooking up a Python  
implementation of the data importer service for comparison. Antranig  
and I have also joined the #jack-js and #serverjs channels on  
freenode, and have introduced ourselves to the community.

Exciting stuff, and I'd love to hear your thoughts about it.

Colin

---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org