Server-Side JavaScript

Here's a radical idea: Use one language to write entire Web apps -- the same language which billions of web pages already use, every day.

Sounds obvious, but for at least the first twelve years of the Web's evolution, developers have pretty much had to use different languages on the server from those available in the browser, leading to segregated teams, disparate and inconsistent know-how, and plenty of server-side string manipulation gymnastics to generate HTML or Ajax pages.

The simplicity of using JavaScript on the server was part of Netscape's original vision back in the day with Netscape LiveWire. But back then, 350 MHz servers were the best you could buy, and Mozilla was yet to emerge from the Netscape organization to continue to advance the state of Web technologies. Today with computing cycles having increased more than 10-fold and Mozilla's work on Rhino (JavaScript interpreter in Java) and SpiderMonkey (JavaScript interpreter in C) and JavaScript itself, we have very solid foundations for JavaScript to be extraordinarily useful and applicable on the server-side again -- with performance in the same range as popular server-side environments like PHP and Ruby on Rails.

Now, with TraceMonkey available, JavaScript (both client side and server-side) can see 20x to 40x speed improvements according to Brendan Eich, Mozilla CTO and creator of JavaScript. Server-Side JavaScript is another way in which, as this article quotes Eich, "Mozilla wants to 'get people thinking about JavaScript as a more general-purpose language' and show them that 'it really is a platform for writing full applications.'"

Many vendors today are embedding Mozilla Rhino or Mozilla SpiderMonkey into Web server environments. Some, like Aptana with the open source Jaxer server actually embed the entire Mozilla Firefox browser engine (including SpiderMonkey) within a Web server to enable server-side Ajax and server-side DOM access in addition to server-side execution of JavaScript.