March 06, 2010 at 17:29 Tags Javascript

In the past few months a new meme seems to be very vibrant in the world of web-development: server-side Javascript. The idea certainly isn't new - Netscape had offered JS on the server-side sometime in the 1990s. Since then, powerful dynamic languages like PHP, Python and Ruby along with Java and ASP have taken over the server-side development scene. So what has happened recently to stir the balance?

It's hard to tell, I can only guess:

Javascript is growing in popularity as more and more powerful applications get written in it to run in the browser. This increases the amount of programmers interested in it, as well as the total amount of Javascript code out there in the wild.

A zoo of new and powerful implementations has appeared recently. A real arms race between Google's V8, Mozilla's TraceMonkey and WebKit's Squirrelfish boosted the performance of Javascript engines considerably in the past couple of years.

The first reason, in particular, is very important. These days a web-developer has to constantly switch between two programming languages - Javascript for the client, and his server-side language of choice for the server. Many people started feeling that this is a useless split of attention, and using a single language both for the client and the server is a good idea .

Why it's bad First of all, further fragmentation of the server-side development community. Aren't there enough ways to write web-applications as it stands? Multiple languages to choose from, multiple frameworks to use once you've chosen a language. Do we need another language & platform for server-side development? What's so bad with having two tools, each suitable for its domain? The other reason I see is more controversial. Javascript is far from being an ideal language. While it has a good core in it , there are also a lot of quirks and design faults. Oh, and there's a ton of horrible code out there that just gets copy-pasted from project to project. I'll stop here since I don't want to turn this post into a language flame-war, but I'll do say that I'd prefer coding in Python or Ruby over Javascript, and thus it's disturbing that Javascript starting to take a share of the server-side cake.

Why it's good Just as the rise in popularity of JS in the browser brought us faster engines that make the internet experience more pleasant, I think that examining new approaches is generally healthy. There's a lot of excitement around this issue lately - excitement that brings talented developers in, places them in the zone for productive hacking, and overall provides a fresh perspective on things. For example, one of the most exciting tools in this scene is Node.js. It's a Javascript interpreter built on top of V8 . What's really cool about Node.js is that it's completely event-based, designed and tuned for asynchronous non-blocking I/O. Asynchronous non-blocking I/O seems to be all the rage recently, as it was found to be greatly enhancing the performance of servers, allowing to handle huge loads of concurrent connections within a single process, without using threads. This approach isn't new. Twisted is a venerable and powerful event I/O library for Python, for example. However, when you code with Twisted you have to be careful to use only very specific Python modules - use one that is blocking and you've ruined the whole model. Node.js, on the other hand, comes with its own standard library that was designed from the ground-up to be 100% non-blocking. It's only fair to note that in this area of event-based programming, Javascript actually has an advantage. The language's simple built-in way of creating anonymous functions is very helpful in this aspect. As a matter of fact, everyone who's written AJAX code and has used a library like jQuery (which these days covers a high percentage of serious JS developers), is already used to the event model of programming. AJAX is all about asynchronous events for which you register an anonymous callback function to handle the result when it arrives. Node.js isn't the only general-purpose implementation of Javascript suitable for server-side development. Mozilla's Java-based Rhino is an alternative, and there are many others. As expected, we can see a lot of fragmentation between the communities since Javascript doesn't even have a commonly accepted standard library. Recent projects like CommonJS come to fix this situation, however. On yet another hand, making one process run as fast as possible is a lofty goal, but what about true parallel programming? Event loops such as the ones offered by Node.js don't scale to multi-CPU machines, so I wonder how this situation will be handled. My bet would be on relatively independent processes communicating via message-passing and talking to mutual data stores via TCP.