Scott's Workblog

scott.bradley.wilson@gmail.com


attention!
This blog has moved! Go to my new blog!


print this article (opens in new window) view printer-friendly version (opens in new window)

The Rise of Server-Side JavaScript (SSJS)

Having a single language makes some sense. For one thing, you can reuse code between browser and server implementations rather than try to map APIs between different languages. You can also happily use JSON as your default serialization. And you only need to learn one language.



Other benefits are perhaps less obvious - for example, in recent years there has been considerable investment made in making JavaScript interpreters as fast as possible to meet the rising complexity of web applications. This has resulted in the screamingly fast V8 JavaScript engine used by Chrome, for example. This provides an infrastructure to create lean, mean JavaScript-based server applications.



Platforms



Node.js is a native JavaScript server application running right up against the OS. Node.js builds directly on Chrome V8 and uses event-driven, asynchronous JavaScript to create a very distinctive development environment. Node.js has very few dependencies, runs very fast, and has a very active community. Most of all, its fun! I ported the Google Wave Gadget API implementation from Apache Wookie over to Node.js in a couple of days (you can download it here). Node also seems to use very little memory regardless of demand - this is due to it using a threadless, event driven server model rather than a more traditional thread pool approach. On the downside, there is some skepticism of the hype around the speed of Node.js. Also, while being very lightweight has its advantages, being so close to the OS makes it harder to manage and track server performance without a lot of Linux Jujitsu: there are, as yet, no simple graphical management tools or utilities for handling deployed applications, for example. However, if you need a platform to prototype demanding real-time applications such as multiplayer games then Node.js is well worth looking at.



Ringo takes a more traditional approach, and uses the Rhino JavaScript engine to run JavaScript applications using Jetty, a Java application server. While Rhino isn't as fast as V8, its usually good enough, and one author has noted some benefits of using the tried-and-tested JVM as the basis for server code as opposed to Node.js's more radical approach. Another plus is that by using Java you get access to tons of Java libraries in your code using Java-JavaScript integration, rather than having to access everything through spawning a console process as in Node. On the other hand, all this Java does weigh a fair amount, and so you won't see the small memory footprints you can acheive with Node.js. If you're a Java developer interested in server-side JavaScript, but think Node.js looks a bit scary - or you just have a ton of Java code you can't face porting - then I think Ringo is a great place to start.



Jack is inspired by Ruby's Rack: it provides an interface between JavaScript and the web server. Jack provides handlers for JavaScript applications to respond to webserver calls building on JSGI in a similar manner to Rack or other lightweight CGI-style frameworks. You can use Jack with Jerry and other Java application servers such as Simple. In many ways, Jack is similar in final deployment to Ringo, and the two are broadly compatible. Jack is probably a good starting point if you want to develop your own specialized server-side javascript framework or middleware.



Nitro is a set of libraries that build on JSGI and Rhino. Rather than a complete platform, Nitro provides components that are useful in building JavaScript frameworks, including templating and parsing engines. The most prominent use of Nitro is AppEngineJS, which lets you run JavaScript servers using Google's app engine infrastructure - so if you want to deploy your application using Google's App Engine, then clearly this is the platform you need to look at.



Opera Unite is a very different kind of system entirely - it uses JavaScript to deploy web services directly from your desktop rather than on a separate server, for example to share music or have your own personal chatroom. Opera Unite services are created using JavaScript with some special extensions, which are then packaged as W3C Widgets. It may not suit every purpose, but it makes sense that a personal web server uses JavaScript as the server programming language, and makes it very easy to create and share simple applications with your friends. Plus it uses Widgets, my other favourite web technology of the moment!



Apache Sling is an example of putting JavaScript on the same footing as other server-side scripting languages such as PHP and JSP. Sling lets you create JavaScript applications and deploy them using its common web application server engine; in fact, "ESP", its implementation of server-side JavaScript looks a lot like JSP. If you want to use server-side JavaScript with a Java content repository (JCR) then Sling is clearly where you need to be looking. (Sling, incidentally, is also at the core of the Sakai 3 LMS).



Standards



The most important emerging standard in this space is the CommonJS initiative. CommonJS defines standard APIs for basic functionality needed by non-browser JavaScript, including module loading, writing to the console, and filesystem access. Most of the platforms described above implement one or more of the existing CommonJS specifications. On the roadmap for CommonJS are areas such as JSGI, Web Sockets, HTTP clients. Eventually we should see a high level of compatibility between applications written in JavaScript for deployment on any of the platforms described above (and the many others I've not looked at) making developing services in JavaScript less dependent on the foibles of any one deployment platform.



In Summary



Server-side JavaScript is an obvious direction for the evolution of web applications and services that ties in well with the developments on the client side of things like HTML5. While many of the current platforms are quite young, there is a very active community, and an active engagement in standardisation, that makes is a promising area for developers to look into. I think also it confirms for me that JavaScript is finally emerging from the scripting ghetto to become recognised as the web's most important programming language - the only language usable in both browsers and servers.

Related items: