When are threaded frameworks better than event-driven frameworks? (i.e., when is rails better than node.js?)

Question

I understand what a threaded framework is (Rails, Django, Symfony2, …). And I understand what an event-driven framework is (Node.js, EventMachine, Twisted, …) and why it's great for live, chat, speed, … In addition they don't seem to cause problems for normal use cases. So:

• What are the drawbacks of event-driven frameworks?
• When should I prefer Rails to Node.js?
• Why aren't all new web servers written with EventMachine, Twisted, or Node.js?
• Will famous frameworks such as Django or Rails become event-driven or die?

Answer 1

So where are the drawbacks of event-driven frameworks?

1. Familiarity. Because event-driven web programming is so different, it will be a while before programmers are comfortable with it. When you are working on a deadline, it’s easier to use what you know, that works.
2. Library support. Node has an amazing number of modules, but has a long way to go to catch up with Ruby and Python. Update: Node now has more published modules available than Python or Ruby.
3. Deployment. IT staff are used to threaded frameworks. To take advantage of event-driven frameworks, you’ll want to be asynchronous top-to-bottom. Right now you can develop in Node.js, but will you be able to deploy it effectively, or will you have to administer your own servers?
4. Unfounded concerns. Things that seem like problems, but aren’t really:
   • Event-driven programming is bad for CPU-intensive apps: The reason being that a CPU-intensive calculation would block the server. This is strictly true, but practically, it is overcome by spawning another process and treating it as I/O, for example, by using Node’s child_process.exec.
   • Event-driven programming is only for apps that need high concurrency: The reason here is that event-driven programming is “harder” than traditional web app programming, so it’s not worth doing unless you have a good reason to. I personally do not think this is the case—event-driven programming is no more difficult, but it is very different. At some point, a critical mass of programmers will be familiar with the event-driven approach and this concern will vanish.
   • Event-driven programming is a mess of nested callbacks. This may be true when you first learn it, but eventually you’ll discover how to structure your code in a readable way.
5. Documentation. The documentation for Node and its 3rd-party libraries is terrible, usually consisting of nothing more than a README.md. Coming from the Python world, where we are used to excellent documentation, this is a big drawback. This is slowly getting better (we need more documentation like this).

When should I prefer Rails to Node.js?

• When you or your team just prefer Ruby over JavaScript.
• When you or your team are not familiar with Node and you need to get the job done.
• When you need to use functionality that’s in Rails that Node doesn’t have yet.
• When you need to deploy to existing Rails-based infrastructure.
• When you have to convince management that you should use Node.js, but you don’t want to be the one to take the fall if the project fails.

Why all new web server are not written with EventMachine, Twisted, or Node.js?

See above.

Will famous framework as Django or Rails turn event-driven or die?

Django and Rails will be around a long time. There are lot of apps in those frameworks, and there’s no reason to rewrite them. And there is a large talent pool, which is often a consideration when developing a new web app.

(But see this Quora answer from the lead developer of Django, endorsing Node).