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:

  • On the server-side C++ is going to be around forever for whenever brute force processing is needed (not for many/most web applications).
  • On the server-side Java is going to be around forever, has a huge collection of libraries covering almost everything needed by a web application, and can be quite efficient with all the work on the JVM.
  • On the client-side we can count on HTML 4.01/CSS 2/Javascript 1.5, and can expect this set to stay pretty much fixed for years.
  • Between the browser and server shipping HTML and JSON seems generally to make the most sense. Yes, I am mostly ignoring XML for in the client and on the wire.

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:

  • Using Javascript on the server means one less language for the web developer to learn. Should help productivity.
  • As a scripting/higher order language, Javascript is good enough.
  • When using Rhino (Javascript implemented in Java) you get immediate access and superb integration with all your server-side Java code.
  • When using SpiderMonkey (Javascript implemented in C) (and/or Tamarin) you get immediate access to all your C/C++ code.
  • Generating and consuming JSON data gets just a bit easier.

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.