Node.js is N in a series of O attempts at a Javascript server-side programming model. I’m not qualified to describe it in great detail, having just started to get to know it properly, but I wanted to share some notes on what I’ve learnt so far.

Node.js is interesting because it uses Javascript. The evangelism argument of why this is A Good Thing is that this language is ubiquitous and pretty much cockroach-like survivability odds skills-wise come what may – when your current language-du-jour is desperately out of fashion 3 weeks from now then Javascript will still always just be there looking at you a little smugly. It’s the lingua franca of all browsers and the new BASIC of the web view-source generation.

Now Javascript is a good person struggling to get over a bad personality, in that although usually all it does is the workman dull job of crawling over a DOM or trying to figure out how to open an annoying popup window, there is nothing fundamentally wrong with it as a language. In fact, it’s actually quite a pleasant thing once you get to know it. The use of continuations and how it handles closures as part of it’s event programming interaction makes it an interesting choice for asynchronous style event programming.

There is a theory that Node.js will become popular because it uses this Dr Jekyll version of its personality (he’s the good one, Farmville Fans), and that the Mr Hyde alert();alert() part is suppressed. The happy day scenario here is that once you’ve learnt Javascript then you’re all set for both client and server side programming models. One Event Model to Rule Them All. We also have the current situation of vendors falling over themselves to impress with their browser VM performance chops, in that ‘making the web work faster’ is a nice side goal of us all getting better and better Javascript run-times. The Google V8 project and its decoupled extensibility hooks have allowed Node.js to exist on the server and scream along in speeds only dreamt of in the futuristic nightmares of the IE6 team.

What worries me personally is more that I’m increasingly thinking of Javascript as more of a build target – something to be used as a intermediary language like the CIL or byte-code. Whether it’s things like CoffeeScript cleaning up the var/bracket noise syntax or Google Web Toolkit it shows that Node.js’s appeal can’t really be Javascript per se. If preprocessing is seen as some vital rouge on the cheeks of the pig, then that’s not a good argument for loving Node.js language ubiquity so far.

So if a single client / server universal language isn’t the appeal then there is the elegance of the programming model. If you haven’t already it’s worth browsing the Hello World style http example here http://nodejs.org/. The style is wonderfully fluent and the advantage is in the non-blocking nature of those function calls. An event-queue model on a single thread (yes, exactly like a browser Javascript engine) can be argued to more efficient in terms of throughput than cranking up new threads or processes. What you lose in fault protection you gain in context-switch, and there is lots to like of the underlying style that Node.js uses through its Javascript genes to make event-driven throughput applications.

So far it seems that Node.js is breaking the community ice by being used as a message in / message out scenarios, with websockets being the obvious target on the client browser. There is lots to be impressed by in how little CPU/Working Set is claimed by this event queue style and it shows a lot of applicability for other non-networking shuffling apps. It’s lean but not quite as mean as some other ‘harder’ functional programming models.

Node.js has a nice package manager already called NPM http://npmjs.org/, and with that in place is all set up to grow in lots of different directions. I can certainly imagine (and have seen a few already) MVC Rails like scenarios, Template-like Sinatra scenarios and JQuery functional client/server hook ups. The modules have a nice dependency hierarchy mapped out, and the package bundler seems to be straight-forward JSON files. The building blocks are certainly in place for growth of the framework and the libraries.

Finally, the nice thing about Node.js is that it’s not yet massive, in that it’s still emerging and growing and that the underlying framework is of a size where you can browse the API and get your head around it. Whether it’s around for the long-haul is debatable but it’s a really interesting evolution of Javascript on the server and brings a lot of practical functional style programming in a really elegant way.

Definitely a project to watch.