The server-side Javascript meme

March 6th, 2010 at 5:29 pm

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 [1].

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 [2], 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 [3]. 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.


These are exciting times. The vibrancy reminds me of the Rails hype of a few years ago. As I’ve mentioned, from my point of view this situation has its pros and cons, but the pros outweigh the cons. Being locked in narrow directions hasn’t been historically fruitful. Mutual enrichment between communities and arms races are a much more viable way to progress.

It will be interesting to see where we’ll be a year from now – I wager that many things are yet to change. In any case, if you’re looking for a spot in an exciting niche of programming where you can make a difference, it seems that server-side Javascript, especially with event-based models like Node.js, fits the bill.
[1] As always happens, the solutions come from several sides. Technologies like Silverlight allow running C# and Python in the client, while cool projects like Pyjamas compile Python to Javascript allowing to write client-side code in Python and running it natively in the browser.
[2] If you restrain yourself to the subset described in the "Javascript, the Good Parts" book. A review is due, I know…
[3] Which, by the way, was specifically designed by Google to serve as an embeddable engine.

Related posts:

  1. A simple canvas-based Javascript game, with a Django back-end
  2. Should I learn Javascript ?
  3. New year’s Python meme 2011
  4. Finding out the mouse click position on a canvas with Javascript
  5. MySQL server installation woes

10 Responses to “The server-side Javascript meme”

  1. blackdogNo Gravatar Says:

    Javascript is far from ideal particularly if your fond of static typing, however, javascript as the “assembler of the web” is targeted by many compilers/translators, my favourite being haxe,

    There’s also Coffeescript, Clojurescript, Parenscript; the point being, a server platform like Node.js can be leveraged even if JS is not your favourite language – as I’m doing in my hxNode project for haxe.

  2. Paul BarryNo Gravatar Says:

    I think CoffeeScript ( takes care of most of your concerns. If you program strictly in CoffeeScript, you can avoid the quirky side of JavaScript and use a language that is more clear and concise, like Ruby/Python. CoffeeScript *is* JavaScript: The Good Parts, with sugar on top :)

  3. elibenNo Gravatar Says:

    @blackdog & Paul,

    I’ve seen CoffeeScript mentioned before, but it kind-of beats the point. Javascript is a strange “assembly layer” – a true VM would be much better (i.e. Parrot, JVM) – as long as CoffeeScript isn’t popular on the client it won’t be popular on the server, and using it for the server with JS itself for the client kind-of beats the one-language point.

  4. Paul BarryNo Gravatar Says:


    What’s stopping you from using CoffeeScript on the client and the server?

  5. MikeNo Gravatar Says:

    > First of all, further fragmentation of the server-side development community.

    What, really? What’s another option to write server side applications going to do to this “community”? You can already use virtually any language you want to write web applications, actually.

    > While it has a good core in it , there are also a lot of quirks and design faults.

    Yeah, like many languages.

    > Oh, and there’s a ton of horrible code out there that just gets copy-pasted from project to project.

    How is this any fault of JavaScript itself?

  6. elibenNo Gravatar Says:


    Nothing, I guess. But if I’d take this path I’d pick Pyjamas, since I know and love Python and see no reason for learning yet another language (CoffeeScript).

  7. M. Edward (Ed) BoraskyNo Gravatar Says:

    There are too many programming languages already. None of them is perfect, so people feel the need to create yet another language, yet another community, etc. Eventually, you just have to say, “Please, no more!” Server-side JavaScript has me shouting, “PLEASE! NO MORE! I’M BEGGING, DOWN ON MY KNEES!”

    There are half a dozen or so languages that people actually use! PHP (4 and 5), C/C++, Java, browser-side JavaScript, Ruby 1.8, Python 2.x, Perl 5.10. Why do we need PHP 6? Perl 6? Ruby 1.9 and 2.0? Python 3? Go? Haskell? Scala? Smalltalk? Erlang? C#? For crying out loud, most of the interpreters / run times are written in C, if only long enough to bootstrap up to a “higher-level” language.

  8. neimadoNo Gravatar Says:

    Any article about server-side javascript that does not mention Microsoft Jscript does a disservice to itself, and the community. I have been developing back-end systems in JScript for a long, long, LONG TIME. It is as robust as any other server-side javascript solution. JScript.NET is powerful, and easy to code. Code re-use between front-end and back-end has been no problem at all.

  9. ArnebergNo Gravatar Says:


    What's stoppibg you from using CoffeeScript on the client wnd the server?;

  10. Conrad BarajasNo Gravatar Says:

    Good article. I’ve bookmarked this website so I can follow your follow-ups. Thanks for taking the energy to share this.

Leave a Reply

To post code with preserved formatting, enclose it in `backticks` (even multiple lines)