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) {
res.sendHeader(200,
{'Content-Type': 'text/plain'});
res.sendBody('Hello World');
res.finish();
}).listen(8000);
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?
Tags: javascript, node.js
Most the programs I have created together have one thing in common. Each performs its main function, then sits there waiting for a mouse click using this piece of code.
> Is performance more important than program comprehensibility?
I agree that event-based programming sometimes inverts the flow of control and gets ugly.
That said:
If your application is synchronous, it needs a process or thread for each concurrent request. If you can processes requests quickly, that can be OK — there won't be many concurrent requests (extreme case: if you process requests in 1 millisecond, not many will pile up). But if you need to call a slow web service or push/pull significant amounts of data to remote network locations, then under load you're going to need a lot of threads/processes, which means lots of machines and memory. It might get expensive.
Also, if a backend service hiccups and doesn't respond to the application tier for 10 seconds, then suddenly your average response time jumps way up, and you run out of concurrent processes (which is usually not pretty). Asynchronity lets you handle that sort of problem more smoothly.
Other applications that can't serve requests quickly are ones that purposefully hold a connection open (chat, alerts, games, etc). For applications such as those, asynchronicity can be imperative. We might see more and more of it with advances like Web Sockets (http://dev.w3.org/html5/websockets/).
Also, does programming server-side with data callbacks necessarily obfusticate the flow of the program? It's different from GUI programming where any event can fire at any time. If you don't make parallel calls during a request, your code could be linear:
main:
- do some stuff
- make async call, pass control to callback1
callback1:
- stuff
- more stuff
- make async call, pass control to callback2
callback2:
- more stuff
.
.
I think the eventual winner will be something that lets you think synchronously while behaving asynchonously behind the scenes. The closest thing I've seen so far is gevent – http://gevent.org/