Not the B Team
Every once in a while I hear whispers of server-side javascript and I get just as excited as the next person. But, I’ll admit that until recently a phrase like “Javascript on Rails” was on the same level as a phrase like “McGyver vs. The A Team – The Movie.” Fictonal. But awesome in theory.
(Don’t worry, they eventually join forces in the sequel)
But what about Jaxer?
My limited experience with server-side javascript (SSJ) has been through Jaxer, from Aptana. It touts some cool functionality, like loading the DOM server-side and built-in database drivers for MySQL, with the former allowing for DOM manipulation and integration with libraries like jQuery.
Ubiquitous "Gear" Logo
But, in its attempts to blur the lines between client and server execution, Jaxer has made sacrifices in its extensibility. It is meant to be plugged into another system. For instance, I don’t know of an easy way to expose data through a RESTful JSON/XML API (like so many sites are doing nowadays) using Jaxer alone.
What I’m really looking for in SSJ is something akin to the ecosystem surrounding languages like Ruby and Python. That’s why I was pleasantly surprised to stumble accross a few projects that aim to do just that.
Narwhal – Javascript Standard Library and Interactive Console
The foundation of any good ecosystem is a standard library. Enter Narwhal, “a flexible javascript standard library.”
There are a lot of things to like about this project, but the primary benefit is its attempts to play nice with multiple javascript runtimes like Rhino and V8cgi. Also, this project is embracing Mozilla’s ServerJS standard which I think is important for its longevity and interoperability.
Setup is a breeze, you can simply clone the project from github:
git clone git://github.com/tlrobinson/narwhal.git
Once you add narwhal/bin to your $PATH, you can use the convenient symlink js to enter an interactive javascript console similar to irb or python.
Jack – Javascript’s “Rack”
Interestingly enough, Narwhal came into existence as it’s author, Tom Robinson, was working on Jack.
JSGI is a webserver interface for JavaScript inspired by Ruby’s Rack (http://rack.rubyforge.org/) and Python’s WSGI (http://www.wsgi.org/).
Jack is an implementation of JSGI compatible handlers (to connect to web servers), middleware (to intercept and manipulate requests to add functionality), and utilities (to make using JSGI easier).
Setup is also breezy. Simply clone Jack into the same directory you cloned Narwhal into:
git clone git://github.com/tlrobinson/jack.git
Since you’ve already added narwhal’s bin directory to your path, lets just make a symlink to jackup from there.
From your narwhal/bin directory:
ln -s [path/to/jack]/bin/jackup jackup
Run jackup -h for usage.
So, what’s next? Where’s Javascript on Rails?
With Narwhal and Jack, you can start writing basic web apps. Looking at the example.js script in jack/examples we can see the basic request/response structure. Looks familiar huh?
var Jack = require("jack");
var map = {};
// an extremely simple Jack application
map["/hello"] = function(env) {
return [200, {"Content-Type":"text/plain"}, ["Hello from " + env["SCRIPT_NAME"]]];
}
// apply the URLMap
var app = Jack.ContentLength(Jack.URLMap(map));
//...
While these two pieces are a good start to a vibrant server-side javascript ecosystem, there’s still a long ways to go to before it’ll be on par with Ruby and Python.
What SSJ needs is its Django/Pylons/Rails/Merb. There are a couple of projects I’ve found in the wild that are using Jack and Narwhal, but they appear to still be in very rapid flux.
Nitro
Nitro provides a library of carefully designed middleware and utilities for creating scalable, standards-compliant Web Applications with JavaScript.
Helma NG
Helma NG consists of several components that can be used together or alone:
1) A compact JavaScript runtime environment based on Mozilla Rhino. It adds
to Rhino a reloading module system that is compatible to the ServerJS
Securable Module proposal.
2) An interactive shell with support for autocompletion and history.
3) A module library implemented in JavaScript, covering basic functionality
such as extensions to the built-in objects, file I/O, logging, persistence,
client and server side HTTP support and more.
FirePHP is a great plugin for php+ajax devs — in essence, it captures error and logging output and sends it over HTML headers instead of the content body. These logs show up in your firebug console alongside your javascript logs, making it great for ajax development. You want your output clean but your error and logging info accessible, and lets face it, 
nlsmith are discussing. 
nlsmith 4:38 am on June 20, 2009 Permalink
Your last article talked about server-side js, you can use firephp on that, too: http://nlsmith.com/projects/console/ (and rails: http://github.com/smith/firephp_rails/tree/master)
I ran into the same type of bug on Jaxer and to a lesser degree, ASP.
I'm planning on making it Jack middleware, too.
britg 1:25 pm on June 20, 2009 Permalink
Very cool project you put together! I will definitely give it a try — I'm finding that I can't live without FirePHP now. I'm sure that will carry over to my server-side JS projects and this sounds like the perfect solution. Cheers!
britg 1:30 pm on June 20, 2009 Permalink
And yes, I think Jack support is a great move for the project — I think it'll find more adoption on Jack than Jaxer. Nothing wrong with Jaxer, but I have a feeling that Jack will be widely adopted going forward just because of it's WSGI/Rack approach.
Matt Saunders 4:16 am on February 21, 2010 Permalink
Hi, FYI this can also happen if you're not using nginx as a proxy but as a regular httpd, using fastcgi for PHP. The fix is very similar – just add these lines to your nginx config file and adjust the sizes as necessary:
fastcgi_buffer_size 16k;
fastcgi_buffers 4 16k;