- we use long polling, but will add WebSocket support once we get more browsers that support it. The code to make it work is shared here: http://amix.dk/blog/post/19489

- we had a smaller comet system in the past that was based on Java + JBoss Netty. It didn't scale that well (used ~10x time the memory node.js solution and had a lot of quirks, like lost connections). Generally thought Netty worked "ok", but I would recommend anyone doing anything serious to look at node.js

- node.js feels VERY natural, but it could be because I had coded so much in JavaScript :)

- I have done a presentation on comet with node.js+V8 to the Taipei Open Source Group which you can check out here: http://amix.dk/blog/post/19484

The technology is there to build next generation web-applications, what are you waiting for? :)

The second reason to pick JavaScript is that it's already geared towards event based programming, because of following things:

   events in browsers and
   closures are a natural part of the language, e.g.
   document.addEventListener("click", function()...

And really, JavaScript is a great language and it can emulate almost any paradigm that you may like. node.js also introduces a module system which makes it much easier to manage code. JavaScript isn't perfect and there's tons of bad code written for it, but it's possible to create beautiful code in JavaScript :-)

Edit: plus, I am confused about the presentation on comparison with Tornado slide. It seems Tornado has higher transfer rate. And after all, they just do a thin layer on top of epoll, what's the penalty here?

Redis http://github.com/fictorial/redis-node-client

memcache: http://github.com/elbart/node-memcache

MySQL support using DBSlayer

And it's fairly easy to implement other stuff using node.js's TCP module. This said, it could definitely use more modules, but it's a young project and I am sure they will come.

(E.g. I'm a node.js newbie, but my understanding is that it doesn't have the io thread/worker thread pool, pipeline/handler framework that Netty does. Still reading about it.)

There seems to be some JavaScript support for Thrift, this would be a great way to have node.js fit in with ones architecture.

https://issues.apache.org/jira/browse/THRIFT-550

Also what are you using for your base libraries?

For example one needs RFC3339 date support, can you just plug in something like Google Closure Library?

http://code.google.com/closure/library/

http://axod.blogspot.com/2009/12/websocket-some-numbers.html

Also a caveat followup - websocket don't play nice with some proxies/nat/firewall setups. Either need https, or fallback on comet.

I think it's always good to have a few things on the go though, so I doubt I'd ever be 'full-time' on any one thing ;)

Also I would like to note I saw your Tornado vs Node.JS hello world test and it made me curious because we use Tornado and we really believed that it was the fastest.

So I looked at your results and noticed Tornado had 100x more bytes transfered in your AB test. So I decided to run your same test on a raw Tornado HTTP server (not using the web.py framework) and these were the results of Hello World.

These tests were ran on an 3.66 i7

Tornado (single instance):

import tornado.httpserver import tornado.ioloop

def handle_request(request): message = 'Hello Word' request.write("HTTP/1.1 200 OK\r\nContent-Length: %d\r\n\r\n%s" % ( len(message), message)) request.finish()

http_server = tornado.httpserver.HTTPServer(handle_request) http_server.listen(8009) tornado.ioloop.IOLoop.instance().start()

ab -c 100 -n 4000 http://127.0.0.1:8009/ Requests per second: 10037.84 [#/sec] (mean)

Node.js (single instance):

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(8008);

ab -c 100 -n 4000 http://127.0.0.1:8008/ Requests per second: 9159.65 [#/sec] (mean)

However doing the test the way you did it did show the results you had with Tornado being 2x slower, however I don't believe that was a fair test at all.

Just my input.

Also regarding node.js we run around 8 I think and we plan to introduce more as node.js does not have threads or processes and currently our CPU and memory usage is very low. They are load balanced from our Python servers, but nginx would be a good load balancer as it's non-blocking.

It should be said that I have coded a lot in Python and I love Python - - so I don't have any bias and I would gladly use Python if it could scale.

His tested showed that Tornado was 2x slower the Node.jsbecause he did it wrong, I actually find Node.js rather impressive =)

Did you need some other functionality, and also have you any interest of new modules for node?