FAQ

Why use JavaScript on the server?

As the scripting language of the web browser, JavaScript is and will be familiar to many developers. The group of developers acquainted and fluent with JavaScript likely will only increase over time. There is much developer productivity to be gained by re-using that fluency.

In addition, using the same language on both the client and server sides may allow for some degree of code sharing.

Why not Perl/PHP/Python/Ruby?

While entirely worthy (to varying degrees) languages not in the browser will always be familiar to a subset of web application developers, where JavaScript fluency is more universal. When a higher order language is useful, JavaScript is roughly comparable to the other higher order alternatives. (Naturally, opinions will differ as to which is "best".) When developer fluency is factored in, JavaScript becomes a pragmatic choice.

Note that JavaScript inherits notions from some of the more interesting object-oriented languages, including Self, Scheme, and Prototype - all with a C/C++/Java-like syntax.

If sharing code is the objective, then why not compile language X to JavaScript to send to the browser?

Debugging compiled code is not an enjoyable experience. Often, the abstraction layer between language X and JavaScript also has some holes then you end up needing to plug with hand-crafted JS (and not just stock JS, but JS that is designed to interface with that library). By using JavaScript all the way across, there are no such leaks.

Also, there can be some impedance mismatch between the prototype-based object model in JavaScript and the class-based object models of other languages.

Is there a bonus reason to use JavaScript on the server?

Why yes, I'm glad you asked. JavaScript is powering increasingly complex applications in the browser. This has caused browser vendors to work hard on their JavaScript performance. Server side JavaScript has the potential to significantly outperform other common dynamic languages because of this work.