random memes }

Revisiting server-side Javascript

Over the past couple years a large chunk of my time has gone into writing a web application to replace a desktop application. The application requires some clever interactivity, a bit beyond what you can do in HTML/Javascript, and so contains a small Java applet. On the back-end some fairly intense processing is required, and so makes use of a moderate-sized/heavily optimized C++ application. In between lies a custom Tomcat instance hosting server-side Java, and some moderately fancy client-side HTML/CSS/Javascript. Switching between all these different forms of programming is frankly exhausting.

Over the same period of time I have experimented with a good chunk of the new/popular/interesting toolkits, languages, and whatever - in search of the best tools to use in my craft. There are too many good but not overwhelming choices. Python or Ruby or Java or Perl or Smalltalk or Lisp or ... at the end of the day I do not find any of the many choices especially compelling compared to the others. What is needed is some criteria filtering down the alternatives. The list boils down to some clear choices:

What is missing is something a bit looser on the server. For many tasks getting lots of function written is more important than high levels of efficiency. This is where Lisp, Smalltalk, Perl, Python, Ruby, PHP, and shell-scripting came in. Which do you pick and why? They all have merits, but none seem like a clear winner.

For a cluster of reasons I am starting to believe that server-side Javascript is the logical choice. In the first place, as a web developer you pretty much have to get good at using Javascript for the client. With closures and prototype objects, Javascript is a very decent looser/higher-order language. While Javascript may not be quite as slick as Python or Ruby (pick your favorite language/feature), the difference is not enough to matter. Bits that add up in favor of Javascript:

Turning theory into practice, found Helma as an interesting example using Rhino. Looks like there are others, and that Java-based server-side Javascript is relatively easy. The picture with C/C++ based server-side Javascript is a bit fuzzier, mostly as there are too many partial solutions.

The other piece of the puzzle is integration into IIS (for the Windows folk) and Apache (for the Unix folk). Personally I like the notion that the application/interpreter runs in a seperate process, lashed to the web server with something like FastCGI (or similar). There is an existing FastCGI extension for IIS, but new IIS versions tend to break extensions in interesting (not) ways. The news of late is that Microsoft is offering a FastCGI extension. This is very good news for folks deploying applications on Windows, as we hopefully should see fewer problems with new IIS revisions.

The other compelling variation is server-side Javascript for applications at web-hosting services. This is pretty exclusively the domain of PHP at present. My webhost (DreamHost) allows the use of FastCGI (originally for PHP and Ruby). A C/C++ based server-side Javascript interpreter lashed up via FastCGI could offer excellent performance. The same code and skills could be largely re-used when developing in-house applications (where the underlying implementation may be Java).

Starts to look like Javascript interpreters lashed to web servers via FastCGI, and integrated into existing applications is the best common path.