Node is a combination of Google’s V8 JavaScript implementation, and various plumbing and libraries. The result is an unusual and clever server programming platform. Node is in a fairly early development phase, and already has a remarkably active community: ~9000 mailing list messages (as of June 2010) and many dozens of projects and libraries. I’ve spent some time digging through Node code and writing small bits of it, and was pleased with what I found.
Why is Node worthy of attention?
- JavaScript is a Next Big Language, it is everywhere. It is probably the most widely used programming language ever.
- I know a few things about asyncronous server programming, having done a lot of it in 1990s IVR software; it is very well suited to serving a large user population.
- Node is accumulating libraries at an impressive rate, indicating momentum.
- There are significant advantages in developing a whole application stack (server and client code) in a single language. For example, this makes code and business logic sharing works across tiers. Using Node, a JavaScript-HTML tool, a JavaScript-CSS tool, JSON, etc., it is possible to develop a complex web application using only JavaScript.
Node is not all unicorns and roses though.; my most serious misgiving about it is that it does not (yet) have a great strategy to make straightforward use of many-core servers. We’ll have to see how that develops over time.
Node Knockout
The team at Fortnight Labs is putting together Node Knockout, a 48-hour Node programming contest. I am a fan of such contests. I’ve offered to help out by being a judge, and I’ve also signed up Oasis Digital as a sponsor.
As a judge, I can’t be on a team; I’ve like to see a team or two form here in St. Louis, though.
To take full advantage of multiple cores, I believe you can just start an instance for each core. Friendfeed does this with Tornado (another evented webserver) http://www.tornadoweb.org/documentation#performance
Bruno – Running an instance of the whole thing per core is not always a good answer, as the number of cores goes up. (Reasons: the C worker thread pool, having to use something out of process to share data even if the whole project fits very easily on a single N-core server, etc.)
Node is early in development, it is likely that if it gets broader traction, a mechanism to automatically work well on N-core machines will appear.
Automagic multicore optimization would definitely be a killer feature for Node. But in my testing (of a pretty simple Node.js comet server), we were bottlenecked by network I/O way before we started taxing the CPU. Obviously other apps might have different results, but the bottom line is that V8 is pretty damn fast.
I thought firing up child processes for computation would take advantage of multiple cores. I do this in my bingo game.
For those who prefer a strongly typed whole stack node.js have a look at my haXe type signatures for Node.js on github http://github.com/blackdog66/bdog-node. For a write up similar to Kyle’s and the merits of haXe (a javascript x compiler) have a look at http://www.ipowerhouse.com.