Server-side JavaScript Will Be as Common as PHP

Reading through the comments on Craig Buckler’s blog post, Will Server-side JavaScript ever catch on? confirms what Douglas Crockford wrote about JavaScript: it’s been typecast. A lot of people can only see it in context of the browser. A big part of this is due to the confusion between the language and the browser DOM. The DOM interface is actually where most JavaScript programmers spend their time.

It also confirms another fact: a lot of people hate JavaScript. I’m confident though — for programmers who appreciate JavaScript’s finer features and can accept its rougher parts — that the news JavaScript is moving server-side is unsurprising and probably welcome. And I’m certain that this is only the beginning.

So where can JavaScript be found server-side right now?

Jaxer is a JavaScript web application framework and server. The server-side API is as capable as any, including access to databases, files, and network sockets. There’s a blurring of the boundary between server-side and client-side scripting; for example, server-side scripts can manipulate the web page DOM.

Scripts are embedded ASP style into your HTML:

<p id="msg"></p>
<script runat="server">
  var nme = document.createTextNode(
      "Hello my name is Jaxer.");
  var para = document.getElementById("name");
  para.appendChild(nme);
</script>

The runat attribute can be server, both, or server-proxy. If set to server, the script is evaluated before the page is sent to the browser. If not set the scripts are executed client-side. If set to server-proxy, then the functions can be called from a client-side script by name, but are proxied, via Ajax, to the server-side equivalent.

Helma is another web application framework that uses JavaScript for server-side scripting. Helma has a templating system, which means it avoids mixing server-side and client-side JavaScript code. You instead write actions in JavaScript, which then render templates, injecting data into the rendering process. Each HTTP request triggers a configured action.

Here’s an example of a template or skin in Helma jargon, named ‘hello’:

<p>Hello, my name is <% response.name %>.</p>

And the action that renders it:

res.data.name = 'Helma';
this.renderSkin('hello');

There are many more examples of server-side JavaScript as the Server-Side JavaScript topic on Wikipedia shows. Almost all of them use Rhino or SpiderMonkey to execute the JavaScript.

Is server-side JavaScript a serious proposition?

While implementations of JavaScript on the server are appearing, it’s far from the ubiquity of PHP hosting. A fair comment is that server-side JavaScript is currently bound to the framework in which it resides. As such, JavaScript written in one environment is unlikely to be portable because of the lack of a standard API. It’s a need that’s already been identified and so the work of the ServerJS group has begun. Projects like jslibs also aim to solve this problem.

Lack of hosting services is also an issue, though Jaxer and AppJet provide their own hosting platforms. Helma applications can be hosted with services that support Java. Once the standard library problem is solved I’m sure we’ll see hosting support improve — you’ll be asking your host for “mod_javascript” support.

Finally, JavaScript has more than enough rough parts to make many people nervous about using it server-side. I seriously think ECMAScript 3.1 and ECMAScript Harmony will eventually have that covered.

We’re seeing JavaScript support appear in many platforms, both web and desktop, local and server. Will server-side JavaScript support offered in hosting packages be as common as PHP? I think it’s inevitable.