由事件驱动的框架的缺点何在?

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).

我什么时候应该更喜欢铁路而不是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.

为什么所有新的网络服务器不与事件Machine、Twisted或Node.js一起写入?

见上文。

著名的“决哥”或“铁路”框架会变成事件驱动还是死亡?

江哥和铁道将存在很长一段时间。 这些框架中有很多应用程序,也没有理由重写它们。 还有一个巨大的人才库,这在开发新的网络应用程序时常常是一个考虑因素。

(但见"http://www.quora.com/What-are-the-forests-forming-in-node-js-versus-Python" rel=“noreferr”>这个Quora回答来自Django的主要开发者,赞同节点)。