Home Blog CV Projects Patterns Notes Book Colophon Search

Initial Thoughts on Server-Side JavaScript

21 Aug, 2009

As many of you will know I've been very keen on JavaScript ever since reading Dogulas Crokford's book "JavaScript The Good Parts". Aside from teaching me that JavScript is actually a very useful language it has also taught me the huge benefits to be gained from knowing the correct subsets of features to actually use. In fact I've been applying that principle to much of my Python code, avoiding decorators, the use of the ** operator, anything that uses any of Python's more clever features etc. I've also been applying the principle to library design and have created what I hope is a new web micro-framework architecture and supporting libraries which I think are much more promising than the others available in the Python world today. More on that once it is finished.

This post was supposed to be about server-side JavaScript though. As a framework developer I'm always looking for how to make it easier for other users to write code. At the moment JavaScript is ubiquitous on the client side so one way to make the life of a web developer easier is to make it available on the server side too and share libraries between the two. Hence my interest.

Here are some notes on what I've learned about the Java ecosystem so far:

GWT statically analyses Java code to produce the JavaScript but is effectively just a Java GUI toolkit, which in hosted mode runs a Java GUI application for debugging and in web mode compiles to very efficient JavaScript to run online. Not all Google services use it though. It is also no use to people using Scala, Jython etc because it doesn't analyse Java classes, it analyses Java itself. Also, there's a bug which means it doesn't work properly on 64-bit dev platforms without some hacking. Dissapointed. Dismissed.
Rhino is totally brilliant, stable, well documented and effective, I'd encourage you to use it to see just how easy it is. To use Java classes you just use them, no importing, no mapping to JavaScript, they just work, brilliant. I spent the first hour trying to use Java classes without realising you can just write var a = new java.whatever.you.Want(). This gives you full access to the entire Java infrastructure from JavaScript.
Rhino can create .class files directly from JavaScript.
Helma 1 and 2 are effectively Java frameworks which use Rhino to expose JavaScript objects. Helma NG is written mainly in JavaScript so is much more hackable. It is slightly slower but a much nicer concept. One to keep an eye on.
ServerJS is a group set up by Kevin Dangoor (someone I've only met once but have a lot of respect for) to define a standard for importing JavaScript modules, the latest draft is implemented in Helma NG.
AppJet is a small framework written in Scala which uses Rhino to allow you to write JavaScript code. It looked promising but is now not supported.
The Java standard library is far more complex than it needs to be I needed 9 lines of Java-like code just to run an exec() command to run an external C program from JavaScript running Rhino.
Jaxer uses ScriptMonkey to embed the whole of Mozilla into a server-side framework so that you can run pages server side before they are sent client side it is open source but I get the impression its a "we're a company, oh and we provide some source code" way, it doesn't seem like they want to build a large open source community.
Env-JS is a project to create a browser environment entirely in JavaScript so that you can do a similar thing to Jaxer but without needing to embed Mozilla. It is slow and at the time of writing contains a bug that meant I couldn't get it to work with Rhino.
Alternatively, Cobra from the Lobo project looksinteresting as an HTML parser which could be used to do just the DOM part (we don't need the other parts server side anyway). There is also a MozillaParser Java project to use Mozilla as of Firefox 2 to parse an HTML page, executing scripts as it goes, and this could be used too.
Parsing an XML file in Java to pass to a Document object for DOM manipulation is really hard because it always tries to get the schema, but the W3C server returns a 503. You therefore need to set up XML catalogs. I haven't done this yet. Surely something like this should work:
```
factory =  javax.xml.parsers.DocumentBuilderFactory.newInstance();
factory.setValidating(false);
factory.setExpandEntityReferences(false);

filename = new java.io.File("index.html")
doc = factory.newDocumentBuilder().parse(filename);
```
I still can't get V8 to compile on 64bit Ubuntu. Still some more work needed before that looks viable.
JSext looked very promising but doesn't seem to have developed much since August last year. Is it still active?

After spending some time looking at all this I turned back to Python and was pleased to see the python-spidermonkey bridge being actively developed. I gave it a quick test and seems to work absolutely brilliantly. A quick benchmark of a Python web app where the actual response is generated in JavaScript rather than Python shows that using Python and JavaScript is about half as fast as just using Python on its own. I suppose that is to be expected.

So far it is looking like my future interactions with server-side JavaScript are likely to involve complex framework code being written in Python and exposing simple objects for use from JavaScript. That way client side developers get all of the benefits of being able to write 90% of server-side code whilst server-side developers can still program in an accessible language like Python.