Just wanted to point out the apples to oranges comparison being made:
The article argues that node's sweet-spot is: "to enable real-time propagation of events and state-changes between clients. You could do the same thing with long-polling ajax or even frequent polling, but those both come with the cost of tying up unnecessary worker threads on the server and dealing with extra requests."
yes we all know that, that is why no one is suggesting that. the better comparison would be to put it up against twisted or event machine, which also use an event loop to do non-blocking IO. but you dont have to deal with callback hell, and even as a javascripter myself, I would say that I would rather code in python or ruby.
you dont have to use node to do real time, web sockets, etc.
Node.js has much better marketing. From the outset Node made a big deal of its event driven architecture and why I should want to use it.
Twisted's website, on the other hand, fills the front page to use verbose, boilerplate-heavy code examples. They mention an "event-driven web server" but don't say why I'd want that. If I'm still interested and click through to their example's I see stuff like "pbsimple.py - simplest possible PB server" or "ampserver.py - do math using AMP". Thrilling.
There's other reasons to like node besides the non-blocking IO. For me, its being able to reuse code on the client and the server. Not sure why the node bashers seem to overlook that one.
The model. For example, including a backbone.js collection/model definition in the server-side node environment and serving the same model code to the client. The controller-y stuff will be different on each: on the node server the model is persisted by overwriting backbone.sync backbone-redis, and the client could choose to do local caching by extending the sync function with a localstorage plug-in.
For the client-server communication, by default backbone.sync on the client uses restful cruddy urls (for rails), which would need to be handled in a node.js router. There's a lot of boilerplate-type stuff out there to help handle routing those urls, building on e.g. express.js. It seems to be more straightforward on rails which already established conventions.
That's probably why a lot of the backbone/node demos and tutorials forego the restful server interface. Its simpler to just do client-server communication using a real-time pipe like socket.io (which itself is shared code on the server the client). not restful but comes with an added wow factor.
The article argues that node's sweet-spot is: "to enable real-time propagation of events and state-changes between clients. You could do the same thing with long-polling ajax or even frequent polling, but those both come with the cost of tying up unnecessary worker threads on the server and dealing with extra requests."
yes we all know that, that is why no one is suggesting that. the better comparison would be to put it up against twisted or event machine, which also use an event loop to do non-blocking IO. but you dont have to deal with callback hell, and even as a javascripter myself, I would say that I would rather code in python or ruby.
you dont have to use node to do real time, web sockets, etc.