Differences between node.js and Tornado

Question

Besides the fact that node.js is written in JS and Tornado in Python, what are some of the differences between the two? They're both non-blocking asynchronous web servers, right? Why choose one over the other besides the language?

Solution 1

The main advantage of node.js is that all its libraries are async so you don't have to worry much about blocking. There are async libraries for mysql, postgres, redis, etc. All is async by default.

Python have a library for anything - but most of these libraries are not asynchronous. In order to take advantage of tornado (and not to block the process) special libraries for are necessary (e.g. you can't just 'pip install redis' and use it, you'll need something like brukva), and there are much less tornado libraries than node.js libraries. There is no async mysql tornado driver available at the moment, for example (or at least I'm not aware of it).

But you can still use many python libraries with tornado (ones that doesn't do i/o), and tornado community is raising and filling the gaps.

It is easier to write an app using node.js than using tornado in my experience. I personally switched to tornado from node.js because it fits into existing infrastructure of my python project better (integration between django site serving html pages and tornado server providing realtime features was quite painless).

Solution 2

As Rich Bradshaw points out Node.js is written in JS, which means you can keep the front end and the back end in the same language and possibly share some codebase. To me that is a huge potential benefit of Node.js. Node also comes with more asynchronous libraries out of the box it seems.

V8 should make JS faster than Python at least that's what benchmarks seem to suggest, but it may not matter much, because both Node.js and Tornado (and most other web frameworks for that matter) use wrappers for native libraries. A lot of the Python standard library is written in C or can be replaced by a faster alternative, which mitigates potential differences even more.

Web services are usually I/O bound, so that means we're spending the time waiting for the data store and not processing the data. That makes the synthetic speed difference between JS and Python irrelevant in many applications.

Solution 3

node.js uses V8 which compiles into assembly code, tornado doesn't do that yet.

Other than that (which doesn't actually seem to make much difference to the speed), it's the ecosystem. Do you prefer the event model of JS, or the way Python works? Are you happier using Python or JS libraries?

Solution 4

Nodejs also has a seamless integration / implementation of websockets called Socket.io. It handles browsers supporting sockets - events and also has backward polling compatibility for older browsers. It is quite quick on development requiring a notification framework or some similar event based programming.

Solution 5

I would suggested you go with NodeJS, if there is no personal pref to python. I like Python a lot, but for async I choose Tornado over node, and later had to struggle finding way to do a thing, or libraries with async support (like Cassandra has async in tests, but nowhere could I find way to use cqlengine with async. Had to choose Mongo since I already surpassed the deadline). In terms of performance and async, Node far better than tornado.

View more solutions

Comments

[Mikhail Korobov]

It should be noted that tornado now has an acces to all async libraries from twisted (see tornadoweb.org/documentation/twisted.html). And however the original question explicitly proposes not to take language in account, it is important that Python have generators and they make writing async code much easier: there is no such a thing in javascript. There are dozens of libraries trying to workaround missing yield in V8 (Step, etc.) but without language suport they have not-so-pretty syntax and handle less edge cases than python's 'yield'.

[Sushant Khurana]

well there is socketTornad which is a forked implementation of socket.io which depends solely on when the next update comes in in terms of support. The whole point of mentioning this here was the beauty of socket.io in nodejs which reduces handling a lot of scenarios.

[jdi]

No idea what you are talking about. That project is old and outdated. Tornadio stays updated with the releases of socket.io reference: github.com/MrJoes/tornadio2

[jholster]

I just run httperf against simple single-process helloworld apps. Tornado on PyPy 1.8 (~8k req/s) is not far behind Node's performance (~11k req/s).

[Tadeck]

Mikhail, you are incorrect about lack of support for generators in JavaScript. See the information about generators implementation in JavaScript 1.7 (and note that the current version, 1.8.2, is from the mid 2009): New in JavaScript 1.7: Generators.

[Mikhail Korobov]

The language node.js uses in not Javascript 1.7 or 1.8, it is closer to ECMAScript5. That's because node.js uses V8 engine which doesn't implement all JavaScript 1.7 features (see code.google.com/p/v8/issues/detail?id=890 ). This may change in future, and there may be valid reasons for that (e.g. JS 1.7 is not a standard), but JavaScript 1.7 was introduced in 2006 and 'yield' is not in v8 in 2012.

[Tadeck]

You are right, I somehow interpreted your comment as if you were saying JavaScript has no generators. My mistake.

[Mikhail Korobov]

Yep, "there is no such a thing in javascript" is not very preciese.

[securecurve]

Very right point of view

[nkint]

Is this answer updated after 2 year?

[Max Heiber]

V8 compiles to machine code, not assembly. And it's important that the compilation is just-in-time rather than static: en.wikipedia.org/wiki/V8_(JavaScript_engine)

[Max Heiber]

@nkint nope. Generators are in ES2015 and are used in the koa framework, for example: koajs.com