On Server-side Javascript

Javascript has been utilized in the browser for a few years now, but server-side Javascript seems to be something that’s talked about a lot but there still is no viable solution to date.  Right?

JavaScript Issues

There are three real issues with server-side Javascript in general. These are the things I would be looking at before pronouncing that server-side Javascript is real enough to take off.

First, to DOM or not to DOM?  That is, it is debatable whether the Javascript engine on the server actually model the DOM.  My position is a resounding “NO!” as too much of the Internet has been about modelling the DOM on the server for far too long; it’s so Web 1.0, a 1990s way of thinking.  Modelling the DOM on the server has one advantage: you can use existing toolkits like Dojo or jQuery on the server side to manipulate HTML documents before sending them to the client.  The disadvantage is the cost of doing so; the startup time for instantiating a DOM and then processing it is quite costly, not to mention the amount of memory it consumes.  Think about how fast/slow your browser works and you realize that minus any rendering, this is the burden put on your servers. Aptana’s Jaxer is a well-known server-side Javascript solution that models the DOM, and may be the only such solution.

Second, standardization part one.  Javascript was designed to run in the browser, and with a DOM present.  Figuring out the order your scripts will be loaded and executed is trivial – it’s the order of the script tags you put in your HTML.  Server-side has no DOM and thus no script tags, so it’s rather nebulous how any script would get loaded at all, let alone multiple ones or the order.  Each implementation of server-side Javascript I’ve looked at have different philosophies that are not compatible with one another.  JsExt, for example, uses a subdirectory structure where a top level directory defines an object and the Javascript files inside define methods for that object; functions are often anonymous and the filename is the actual name of the function.  There are other obvious schemes, but all this leads to my next point.

Third, standardization part two.  Javascript is a very lightweight language once you take out the events and methods that are DOM oriented.  You have a few objects with a few prototypes and that is it (Strings, Arrays, Date, and so on).  The established server-side languages all have much richer and standard APIs; PHP has hundreds of functions and dozens of objects, for example.  There is no standards document that I know of that describes a similar set of functions and objects (and prototypes) that would enable server-side Javascript programs to be portable between server environments.  I’m talking about the server-side equivalent of jQuery or Dojo, and from my second point above you can see that the incompatibilities I described make this near impossible at this point.

It’s one thing for PHP to have it’s mysqli class and functions and Java to have JDBC.  These are language specific ways to access a MySQL database and you have to use what the language provides.  With server-side Javascript, you are using ONE language but might have to call Jaxer.db methods to access a MySQL database from Jaxer and JSEXT1.MySQL methods from JsExt.  One language, two radically different ways to access a database.

For the past year, I’ve been googling and watching out for viable server-side Javascript solutions but  I kept glossing over the ones that involved the Mozilla Rhino engine, thinking that we really want to be using whatever Firefox is using since we all benefit when Firefox is improved.  I found JsExt (http://jsext.sourceforge.net) to be about the best implementation of the bunch, but I really only ended up using it for its ability to run javascripts from the command line (in lieu of batch files or shell scripts).

Then I read this brilliant blog post by Steve Yegge of Google:

http://steve-yegge.blogspot.com/2008/06/rhinos-and-tigers.html

While the post and lecture is amusing and highly entertaining throughout, the gist is that the JVM (or .NET’s CLI) has a huge role in the future of computing.  These things are language agnostic; the goal is to turn source code into the virtual machine’s (VM) byte codes and let the VM implementors do their thing.  More specifically, you can compile Javascript into JVM byte codes and the resulting program not only runs in the JVM, but it also gets the benefit of Just In Time (JIT) compiling and optimization done by the VM.

I stumbled upon one of these JVM based projects, the Helma project, late last week and spent a few days over the weekend with it and came away quite impressed.  Turns out server-side Javascript has been here since 1998 when Helma first started up.

What is Helma?  It’s a full blown application server, built on top of the Jetty WWW server with the Rhino javascript engine.  It comes with a robust MVC framework written in Javascript, including an object persistence engine/database backend, and theme/skin/templating engine for the front end.

Helma can be downloaded at http://helma.org.  The download is under 5 megabytes.  The install took me about 1 minute to unzip.  To get started, all I had to do was run start.sh (or start.bat under windows).

The Helma configuration file is just a few lines, yet is rather powerful for defining the various applications you might serve with it.  It comes with two applications: welcome and manage.  Welcome is a small WWW site, a starting point for understanding what Helma is and how to get started using it.  Manage is a server administration back end that shows you the status of your applications, allows you to restart them or disable them, and so forth.

I highly recommend taking a look at Helma if you’re looking for a Javascript solution for the server-side of things.  I’ll mention a few of the highlights I found over the weekend, aside from how small it is and easy it was to set up.

The server comes with at least Rhino 1.7 which features a windowed debugger for Firebug style debugging of server-side code.

Javascript can trivially call any Java classes/methods on your classpath.  Seems easier to me to write a little bit of Java to extend your environment in a “native” code sort of way than writing C or C++ to extend a language like PHP or Perl.  This really puts a lot of power at your fingertips, like the ability to do image manipulation at Java speeds in your Javascript application.  Calling Javascript from Java is doable, too, but not as seemlessly.

The Helma server-side javascript library is quite rich, including Javascript classes/source code to implement FTP, SSH, SMTP, and several other Internet communication standards.

You can write text (HTML) to the browser or to the console (where you ran start.sh or start.bat).

There’s little overhead for defining a URL that runs a specific Javascript function to handle that URL.  It’s as simple as defining “function foo_handler() {  …}” to handle the URL //foo.

You can use Jetty to serve static content, or you can serve static content through a trivial URL handler.  The extra overhead is almost zero!  So you can check to see if a user is logged in before serving a client-based .js file or you can check to see if the HTTP_REFERER for an image request is from your site before serving it (avoid bandwidth leaching).

I noticed two or three speeds when viewing the sample application I implemented to test things out.  There seemed to be a rather long page load time right after restarting the server (start.sh/start.bat) for the first page or so.  After editing a script and reloading the page, it seemed a lot faster, but still a tad slow.  But reloading that same page was just about as fast as I can expect a page to be served.  I assume this is due to the whole application being compiled into byte code upon restart, the incremental compiles as I change / edit source files, and the true production speed of JIT.

As far as performance goes, I would expect Helma Javascript code to be about the same as Java in this chart, due to it being compiled to JVM byte codes and JIT kicking in:

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=all&d=data&gpp=on&java=on&ghc=on&csharp=on&sbcl=on&hipe=on&mzscheme=on&vw=on&lua=on&python=on&tracemonkey=on&perl=on&ruby=on&php=on&calc=calculate&box=1

Thumbs up from me for Helma!