twisted solves networking problems of all types really well, but (as Paul mentions in his post), most libraries for python are written assuming they have the entire interpreter to themselves for as long as they want (which in the naïve case, turns it into tornado, but it at least has facilities for running async tasks in other threads or processes).
node.js does as well, but it's developing a very rich library very fast. Certain things are harder to deal with (personally, I think twisted got async error handling right and most everyone else hasn't got there yet), but people think they understand javascript better than they think they can understand twisted.
Twisted has support for many network protocols while Tornado only has support for HTTP (client and server). If you are doing something other than HTTP, than Twisted might be the better choice.
Tornado mastered only the "have lots of suspended connections" thing. Many of the examples involve blocking for processing one of those connections. What's the point of having 20k connections terminated on an http comet connection if you completely block the entire event loop to service a single one while you make another network connection (e.g. memcached, mysql, etc...).
In this regard, most real life comet apps are doing more than http. To be fair, tornado did ship with a yet another python http client, so you can at least use it with a database that speaks http without blocking, though without chainable deferreds, it's hard to do the exact right continuations required to chain these events together without locking the event loop.
Twisted is theoretically better than Tornado because everything is async in Twisted, but Tornado is more practical because it's easier to write straight-line code than chains of callbacks. The cost of Tornado is that you need more memory on the frontend because you run more instances of the application.
In my previous comment, I listed some real life comet applications that use Tornado. What real life comet applications use Twisted?
@defer.inlineCallbacks
def gclient(gearman):
w = client.GearmanClient(gearman)
x = yield w.submit('test', 'some data')
print "result:", repr(x)
As far as who's using in actual comet applications -- it's hard to say. The last time I tried looking for a comet implementation, what appeared to be the canonical "cometd" was written in twisted. I ended up not using it and rolled my own twisted based server that was closer to my requirements. It's been in production for a few years now, but is still a somewhat secret project.
I'm pretty sure you could research their userbase as well as I could.
I'm not saying twisted is perfect and all other technology sucks (though deferreds, once you understand them, are really the only way to do this sort of thing).
When tornado was launched, I started playing with it and couldn't understand why it prevented me from integrating so many asynchronous tasks. I spent an hour or two separating the good parts of tornado from the reimplementation of twisted and built tornado on top of twisted. It was, as far as I could tell, at the starting point, minus 1,297 lines of python.
One advantage to using something like Node.js, however, is language homogeneity: having all your browser client-side code and server-side code in 1 programming language. While it's good to use The Right Tool For The Job there's also a benefit to having the simplest solution possible, with the least amount of moving parts, and requiring the least amount of tech knowledge (esp languages) to deliver that solution. While I prefer Python to JavaScript, if we never get to a world where Python is built-in to every browser there is some attraction to moving in the other direction. "If you can't beat 'em, join 'em."
Templating is a perfect case for reusing code on both sides of the connection. In the optimal scenario, the browser can render a template based on requests for JSON data. However, if the client doesn't support JavaScript, the same template can be rendered on the server-side and fed to the browser traditionally. Great for accessibility and SEO.
Input validation is another situation that's a great candidate for shared code.
Another nice benefit is that server-side JavaScript brings an assortment of mature DOM selection/manipulation engines with it. I believe there was an example of using jQuery on the server-side with node.js posted here recently.
Jaxer[0], which was ahead of its time, had a nice approach to sharing client/server logic with its runat="both". It's a shame that project never got much traction.
The other is more appealing. The wins for client/server code share are for things like field validations and templates.
nodejs and jsdom perhaps? "jsdom + jQuery in 5 lines with node.js" ~ http://news.ycombinator.com/item?id=1665999
I thought there was fairly universal agreement that while javascript has many strengths, its syntax was not one of them.