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.