我是这类新手，但最近我听到很多关于Node.js 的好处。考虑到我一般喜欢使用 jQuery 和 JavaScript，我不禁想知道如何决定何时使用 Node.js. 我想到的 Web 应用程序就像Bitly一样 - 需要一些内容，归档它。
从我过去几天所做的所有作业中，我获得了以下信息。 Node.js 的
我遇到的一些消息来源是：
考虑到 Node.js 几乎可以在亚马逊的 EC2实例上运行，我试图了解哪些类型的问题需要 Node.js，而不是像PHP ， Python和Ruby那样强大的国王。 。我知道这实际上取决于人们对语言的专业知识，但我的问题更多地涉及一般类别：何时使用特定框架以及它特别适合哪种类型的问题？
你做了很好的总结 Node.js 的精彩内容。我的感觉是 Node.js 特别适合于您希望保持从浏览器到服务器的持久连接的应用程序。使用称为“长轮询” 的技术 ，您可以编写一个实时向用户发送更新的应用程序。对许多网络巨头进行长时间轮询，比如Ruby on Rails或Django ，会在服务器上产生巨大的负担，因为每个活动客户端都会占用一个服务器进程。这种情况相当于一个tarpit攻击。当您使用 Node.js 之类的东西时，服务器不需要为每个打开的连接维护单独的线程。
这意味着您可以在 Node.js 中创建基于浏览器的聊天应用程序 ，几乎不需要任何系统资源来为很多客户端提供服务。任何时候你想做这种长轮询，Node.js 是一个很好的选择。
值得一提的是 Ruby 和 Python 都有工具来做这种事情（分别是eventmachine和twisted ），但是 Node.js 非常好地完成了它，并且从头开始。 JavaScript 非常适合基于回调的并发模型，它在这里很有优势。此外，能够使用本机的 JSON 序列化和反序列化客户端和服务器是非常好的。
我期待在这里阅读其他答案，这是一个很棒的问题。
值得指出的是，Node.js 对于在客户端 / 服务器间隙中重复使用大量代码的情况也很有用。 Meteor 框架使这很容易，很多人都认为这可能是 Web 开发的未来。我可以从经验中说，在 Meteor 中编写代码非常有趣，其中很大一部分是花更少的时间考虑如何重构数据，因此浏览器中运行的代码很容易操纵它并将其传回。
这是一篇关于金字塔和长轮询的文章，结果很容易在 gevent 的帮助下设置： TicTacToe 和 Long Polling with Pyramid 。
我相信 Node.js 最适合实时应用：在线游戏，协作工具，聊天室，或者其他用户需要立即看到一个用户（或机器人？或传感器？）对应用程序做什么的任何事情，没有页面刷新。
我还要提一下，Socket.IO 与 Node.js 相结合，可以比长轮询更进一步减少实时延迟。作为最坏的情况，Socket.IO 将回归长轮询，而是使用网络套接字甚至 Flash（如果可用的话）。
但是我还应该提一下，使用 Node.js 可以更好地解决因线程而导致代码阻塞的任何情况。或者您需要应用程序进行事件驱动的任何情况。
此外，Ryan Dahl 在一次谈话中说，我曾经参加过 Node.js 基准测试，与 Nginx 的常规旧 HTTP 请求密切相关。因此，如果我们使用 Node.js 构建，我们可以非常有效地服务我们的常规资源，当我们需要事件驱动的东西时，它就可以处理它了。
另外，它一直都是 JavaScript。 Lingua Franca 整个堆栈。
使用 NodeJS 的原因：
它运行 Javascript，因此您可以在服务器和客户端上使用相同的语言 ，甚至可以在它们之间共享一些代码（例如，用于表单验证，或者在两端呈现视图。）
可通过 NPM 访问的不断增长的软件包池，包括客户端和服务器端库 / 模块，以及用于 Web 开发的命令行工具。其中大部分都方便地托管在 github 上，有时您可以报告问题并在几小时内找到它！把所有东西放在一个屋檐下很好，标准化的问题报告和简单的分叉。
它已经成为运行Javascript 相关工具和其他与 Web 相关的工具的事实标准环境，包括任务运行器，缩小器，美化器，链接器，预处理器，捆绑器和分析处理器。
它似乎非常适合原型设计，敏捷开发和快速产品迭代 。
不使用 NodeJS 的原因：
它运行 Javascript，没有编译时类型检查。对于大型，复杂的安全关键系统或项目，包括不同组织之间的协作，鼓励合同接口并提供静态类型检查的语言可以从长远来看节省一些调试时间（和爆炸 ）。 （虽然 JVM 卡住了null ，但请将 Haskell 用于你的核反应堆。）
除此之外，NPM 中的许多软件包都有点原始 ，并且仍处于快速发展阶段。旧框架的一些库经历了十年的测试和错误修正，并且现在非常稳定 。 Npmjs.org 没有对包进行评级的机制 ，这导致包大量增加或多或少相同的东西，其中大部分不再维护。
嵌套的回调地狱。 （当然有20 种不同的解决方案 ......）
不断增长的软件包池可以使一个 NodeJS 项目与下一个项目显得截然不同 。由于可用的选项数量巨大（例如 Express / Sails.js / Meteor / Derby ），实现方式有很大差异。这有时会使新开发人员更难进入 Node 项目。与Rails开发人员加入现有项目相比：他应该能够很快熟悉应用程序，因为鼓励所有 Rails 应用程序使用类似的结构 。
处理文件可能有点痛苦。在其他语言中微不足道的事情，比如从文本文件中读取一行， 对 Node.js来说很奇怪 ，有 80 多个 upvotes 的 StackOverflow 问题。 从 CSV 文件中一次读取一条记录没有简单的方法 。等等。
我喜欢 NodeJS，它既快速又狂野又有趣，但我担心它对可证明的正确性几乎没有兴趣。让我们希望我们最终可以融合两全其美。我很想知道将来取代 Node 会有什么...... :)