With the rise of AJAX on the web, javascript rose from being an obscure, client side language mainly used for gimmicky animations and popup ads, to a proper web programming language used for sophisticated network comms between browser and server.

The server side of AJAX is still in most cases handled by PHP, causing most web developers to, apart from markup languages HTML and CSS, having to code in both Javascript and PHP. (PHP could be replaced here by Python, Perl, or any other server-side language).

Well, those days might be over, thanks to a nifty little (and I mean litte, as in extremely lightweight) engine called node.js, which not only runs javascript on the server, but actually uses javascript as the server.

A Javascript webserver? What are they smoking?

My initial rection to this is a bit similar to seeing someone building a palace out of ice, or a steam locomotive out of sand. Amazement at the amount of effort and creativity that’s being put into the idea, but very little for its actual usefulness.

Let’s have a look at the Javascript engine under node’s hood: an engine written by Google, called V8.

Why did Google write their own Javascript engine?

When Javascript was first integrated into the Netscape Navigator browser in the mid 1990′s, it’s main goal was to provide access to an HTML document’s elements (called the DOM tree), after the document has been rendered by the browser. Its use was mainly to make small alterations in content based on user interaction, like changing the colour of a button when the mouse hovered over it, or popping up small browser windows (annoyingly so).

Performance was not a big issue.

Later, people started using Javascript to, after the document has been rendered in the browser, pull more content from the server to update into the browser, thus making web pages active. A good example of this is GMail, which, without having to reload the page in your browser, adds new mail messages in your inbox. This technique is called AJAX.

Javascript is an integral part of the AJAX revolution, which was largely driven by Google. They quickly realized the severe shortcomings of most Javascript engines, and wrote their own: the V8 engine, highly optimized for speed and memory consumption.

Given the way the V8 engine was written, and the asynchronous nature of Javascript (which basically means Javascript multitasks by default), It suddenly becomes clear that Javascript, given the right implementation, could be better suited to the server side of AJAX than PHP, Python or Perl. That means, in the GMail example, that both the part that reads the new mail on the server, and the part that shows you your new mail in your inbox, could written in Javascript.

Seeing the light

Node.js extends the V8 engine with a set of libraries that makes building a simple web server as simple as this:

You don’t have to understand Javascript to see that that is really simple. Given that Node is installed on your server, you simply have to run a .js file with the above content with Node, to have a working (though basic) webserver.

On top of that, as highlighted in this article on Mashable, node’s footprint on the web server is extremely small, up to 1000 times smaller per connection, compared to Apache (the most commonly used web server on the Internet). This means, as your site accumulates concurrent users, your server could take 1000 times longer to run out of memory.

Apart from this, users are more likely to experience a smooth, fast user journey, because of the fact that so much less server oomph is needed to process and deliver the same data.

Node is not the be-all and end-all of server solutions – it has a very specific use, which happens to fit a common trend today: providing a lightweight server infrastructure to serve up large amounts of small chunks of data to large numbers of users.

This makes node a perfect match for the realtime web, for gaming apps, for collaboration: basically all applications where speed and concurrency of data transfer matters.

Where does this leave PHP, Python, and their counterparts?

PHP will remain to be the best Hypertext Preprocessor there is, until further notice (which is what it was built for – generating and manipulating HTML). Python will remain the language of choice for building very complex server applications quickly. Perl will remain … well, Perl.

I do think, however, that PHP, Python or Perl’s role as server-side language in AJAX communications could diminish into obscurity. Let’s wait and see.