Event-Programming: The Highway to Concurrency?

Yesterday I watched this talk by Ryan Dahl about node.js. node.js is a environment, based on Google’s v8 javascript engine, to build high-performance servers using the Javascript language. Here’s a simple hello world HTTP server:

var sys = require(‘sys’), 

 http = require(‘http’);

http.createServer(function (req, res) {


 {‘Content-Type’: ‘text/plain’});

 res.sendBody(‘Hello World’);



You may ask yourself “why the hell would you use Javascript for server-side programming?” And that’s a valid question. However, in the case of node.js it seems like a good fit. Why? Because Javascript in the browser is very event-based: mouse over, click, drag and timeout events, for instance. Events are Javascript’s programming model in the browser. Node.js brings this idea to the server. Everything requiring I/O in node.js happens asynchronously, with everything you can provide a callback function, or set an event handler to handle events such as “data”, when a block of data has been read from a stream. This results in improved performance.

Some people are really excited about node.js, but I’m not so sure. My feeling is that events are today’s goto statements: they lead to code for which it is is very difficult to determine what happens in which order. It’s bad enough that we have to do it this way in user interfaces and browser, do we really want this at the server as well?

Is performance more important than program comprehensibility?