Last month was Javascript season in Europe, with twoconferences dedicated to the language that powers interactive web applications, and a third, which featured it heavily. If a common theme emerged, it was the buzz about Javascript leaping out of the browser to serve other domains, and the noise has only become louder in the aftermath.
Of all the applications outside the browser, server-side Javascript is the most alluring for reasons described in this post. An idea that would have had you laughed out of the room a few years ago is edging towards reality.
Javascript outside the browser? Some of the applications are graphical user-interface platforms similar to the browser, e.g. Adobe Air, television sets. With other applications, there’s not even a graphical user interface. For example, some have suggested using it as a general-purpose Unix scripting language.
This guest post was written by Michael Mahemoff, who works at Osmosoft as lead web developer and blogs regularly for Ajaxian and on his his personal blog, Software As She’s Developed. You can follow him on Twitter.
The Perfect Storm
Server-side Javascript isn’t a new phenomenon; Netscape stuck Javascript in the server way back in 1996, right after they introduced it to the world as a browser technology. Interest soon waned, and the language was confined to the browser for the most part. Even there, it didn’t get a whole lot of respect and was frequently dismissed as a hack language capable of no more than annoying alert boxes and gratuitous ticker tape animations.
But suddenly, serious web-based applications started sprouting up. GMail, Google Maps, and JotSpot (kind of a Google Docs predecessor) were all running inside the browser. They weren’t supported by Flash, nor ActiveX, but Javascript manipulating the browser’s Document Object Model (DOM). The term “Ajax” was coined to describe these applications, and a community flourished. A few years on, Javascript has become the world’s most popular programming language by some accounts. Not so surprising when you consider its special status as the standard language shipped with all major browsers. It’s the web’s lingua franca. While most web developers have a favourite, primary, language for server-side work, they converge on Javascript when it comes to the browser. Javascript today can be compared to the English language: it’s arguably the most popular language as long as you count basic competency, not just outright fluency.
Given that you’re already using it in the browser, why not stick it in the server too? One language all the way down makes it easier for a single programmer to work on either side of the wire; there’s less of a mental shift. For project managers, the trend would make it easier to move developer resources between the front end and the back end if a common language is used on both. Many in the developer community now recognize Javascript as a respectable language, with understood patterns for effective use. In fact, many of Javascript’s negatives were a case of misdiagnosis: the problem was really the browsers’ DOM (Document Object Model) APIs, not the language itself. Take those out of the equation and you’re left with a solid language capable of tackling diverse problems.
There’s also a promising reuse story for this “dual-side Javascript” scenario. Take form validation for example. Right now, it’s common to write the same logic in two different languages. In Javascript, you write a validator to give the user immediate feedback inside the browser, and in a language like PHP, you write a validator to ensure data integrity once the form data has been uploaded to the server. But once you switch to Javascript on the server, you just need to write a single validation routine at both ends. Under some styles of development, you can also arrange for a function in the browser to directly call another function inside the server; the code is smaller and simpler to write, not being bogged down in the technical details of transferring data across the network.
Javascript performance has also moved forward in leaps and bounds, thanks to browser competition. Firefox’s Javascript engine, Spidermonkey, increased in speed by a factor of 20-40x. Safari’s underlying engine – Squirrelfish, aka Nitro – posted similarly impressive gains (see chart below), and Google Chrome came on the scene last year along with its highly optimized V8 Javascript engine, a very real contender in the “fastest Javasript engine” stakes.
Server-side Javascript also dovetails nicely the new breed of NOSQL databases. Being web-native, these databases tend to communicate in HTTP, and in some cases JSON (JavaScript Object Notation) is the message format. Javascript libraries already include support for exactly that kind of interaction and programmers are familiar with them. Some of these NOSQL systems go beyond data persistence and into the zone of full-fledged Javascript application environments.
Towards A Mature Server-Side Ecology
In the simplest case, all you need to run server-side Javascript is a Javascript engine to plug a web server into. There are plenty of open source options here; the choice will come down to the language its implemented in, which affects the kind of environments it can run in, in addition to the usual factors like performance and level of support. Many Javascript platforms run on the Rhino engine for example, and Rhino is built in Java; this means that they can easily integrate with Java components. Thus, you can build the entire user-interface in Javascript – including a thin UI layer on the server – and still have it backed by a conventional enterprise Java stack. Helma is one prominent example of this architecture.
Once equipped with a Javascript engine, you can write simple CGI scripts as you would with any other language – read the request, write the response. In practice, you’ll also want good library support to get anything useful done. Some environments do come with libraries, and you can also make use of existing libraries developed for browser-based Javascript. What will really make the biggest impact, though, is industry-wide standardisation. To that end, there’s a strong grassroots movement underway to converge on a complete API: CommonJS is defining an API for file access, networking, unit testing, and so on, as well as declaring how these components should be packaged for easy import. Multiple efforts are implementing the nascent spec in several major Javascript engines (Rhino, Spidermonkey, V8, EjScript). One open-source platform complying with CommonJS is Narwhal. It has considerable momentum and runs on several of the Javascript engines.
CommonJS is raising the level of abstraction for server-side Javascript and allowing developers to use patterns familiar from high-level servers in other environments. Writing a web server no longer means hand-coding the lower-level cruft. Thus, you get a framework like Jack, which is similar to Python’s WSGI and Ruby’s Rack. Jack’s based on the idea of fine-grained “middleware” libraries, able to be composed and reused, and there’s a separate project, Nitro, to build such components for Jack. So Nitro builds on Jack, and Jack builds on CommonJS. This is an example of the ecosystem beginning to emerge in server-side Javascript.
Use the Force! Building on Javascript’s Strengths
In the previous section, I treated Javascript as just another language with all the usual server-side abstractions and the well-trodden path towards modularity and reuse. That’s not a bad thing at all, since we also benefit from the synergies of running the same language in the browser and the server mentioned earlier. Where things get really interesting, though, is with frameworks that exploit Javascript’s unique characteristics.
It’s easy to get carried away with Javascript’s efficacy as a regular scripting language, so let’s remind ourselves that its roots are inside the browser. What the browser has, that a generic web framework doesn’t, is the Document Object Model (DOM). This is the browser’s model of the web page’s contents. What if we gave Javascript access to a DOM?
DOM access is a key feature of the Jaxer environment. It gives scripts access to an entire server-side Firefox instance. Developers can therefore manipulate content as they would in a client-side application, and output the resulting page. This overcomes one of the objections with Ajax apps, which is “what if the user has turned off Javascript?”. The page still comes out as plain old HTML. That’s a lot of power, and the patterns for using this kind of thing are not yet fully understood, but it has plenty of potential for exploration. There are also potentially great benefits for testing client-side applications if you can simulate an entire browser instance. jQuery founder has been working on a product called env.js. Where Jaxer is essentially an entire Firefox instance, env.js is an attempt to build a simulation of the browser environment from scratch, under active development. It’s too early to say if its scope will stretch beyond testing and into the realm of server-side Javascript.
DOM manipulation may be one characteristic thing about Javascript we can exploit, but there is also another (related) thing: event-handling. The language was more or less designed to respond to user events, so it has a great model for handling them that is familiar to any Javascript programmer worth their salt.
For most server-side programmers, event-handling capability will yield a big fat “who gives a damn?”. Server-side scripts don’t sit around waiting for events to come in. They usually just look at an incoming request, deal with it, and send out a response. Then they exit as soon as they can. All good stuff, but there’s a completely different paradigm possible. It’s part of the trend towards the real-time web and the design pattern known as Comet.
With Comet, the server holds on to the connection for a while, and continues to stream out information intermittently to the browser. The typical example is a two-way chat – as soon as one guy says something, the Comet server sends the message to the other guy. This is event-driven programming all over again, and compared to the usual suspects on the server, Javascript is well-placed to support this paradigm.
A framework that’s taking advantage of all this is node.js, or just “Node” to its friends. Node is interesting because it requires scripts to explicitly close the connection; if they don’t close it, the connection just stays open and the script can handle events as they come in, usually by sending more information down to the browser. Less than a year old, the project already has a strong community and numerous derivative frameworks and applications. A similar model has been used in other frameworks, like Python’s twisted, but Javascript may turn out to offer a neater syntax for this kind of thing. By daring to be different and using javascript for what it’s best at, Node is shaping up as a framework to watch. The speed of Node apps is likely to give Javascript serious cred among server-side developers.
The Cloud. Of Course, the Cloud!
No article on server trends could ignore the famous cloud. How does javascript work in virtualised computing environments? With a suitable engine, you can certainly set up an environment manually using amazon EC2, google app engine, or similar cloud hosts. However, you can do it easier than that with some of the other solutions around. Joyent took a big bet on Javascript when it acquired Reasonably Smart earlier this year; the host now offers a dead-simple runway to host Javascript scaleably. Aptana, the company behind the Jaxer platform described above, does likewise.
Something’s Going on Here
Before we get too excited about this trend, I should make one thing clear. Conspicuous by their absence are the real-world server-side Javascript apps. There don’t appear to be many sites running Javascript in the server at this time. Probably the most popular site powered by Javascript is EtherPad, the real-time collaborative notepad from AppJet, the company acquired by Google last week. This is a cautionary example, because AppJet launched as a cloud-based server-side Javascript framework before dropping it to concentrate on Etherpad. Aptana has also announced they are pulling back on Jaxer due to difficulties monetising it. Maybe this is more of a statement about cloud hosting revenue models than server-side Javascript, but it’s worth asking how other attempts to propagate server-side Javascript will fare.
One of the critical success factors will be a comprehensive standard API; it’s a prerequisite to a vibrant ecosystem of interoperable components, and with a range of engines to run on. We now have the seeds of that with commonJS. Another factor is best practices for using the language; again, we’ve already discovered much of that as a side benefit of the Ajax revolution. Frameworks like Node, which build on Javascript’s unique characteristics, are building on those to establish best practices for server-side Javascript. Reuse of both knowledge and practices will give Javascript its best chance yet to stand up as a viable alternative to the usual server-side suspects.
Although Javascript is a far better language than was previously assumed, its syntax still has plenty of quirks. If we restrict ourselves to the subset of Javascript found in all the major browsers today – and arguably it makes sense to do so – it’s arguably lacking certain features of other server-side languages. Those other languages are free to evolve autonomously; in contrast, Javascript’s fate is heavily determined by standards bodies, browser manufacturers, and the patterns around how users upgrade their browser.
In this sense, the language’s strength – shipping with every browser – is also an Achilles’ Heel. That said, the language may well prove “good enough”. The benefits of “one language all the way down” may outweigh the cost in many cases. The will is stronger than ever to make server-side Javascript a reality, and it’s translating into a visible surge of activity in the web community. There’s the promise of code reuse and the possibility of cutting in half the number of programming languages involved in building a typical web application.
Many smart developers have gravitated towards Javascript in recent years, as a means of producing world-class front-end apps. The attention has progressed our understanding of the language. Should server-side Javascript go mainstream, a third wave of Javascript developers will be joining the community and enriching the ecosystem.
Photo by Dmitry Baranovskiy
