是否有充分的理由避免针对非实时Web应用程序使用node.js？

我已经看到很多关于实时Web应用程序的Node.js多么出色的讨论-需要套接字，Comet，AJAX大量通信等等的东西。我知道，它的事件驱动，异步，线程驱动模型也适用于低开销的并发。

我也看到了Node.js教程，这些教程用于更简单的“传统”非实时应用程序（例如，标准博客示例，对于那些学习应用程序开发的人们来说，这似乎是标准的“ Hello World”）。我也知道，节点静态允许您提供静态资产。

我的问题是：是否有充分的理由要避免针对传统Web应用程序使用Node.js，例如分类，论坛，上述博客示例或为内部业务应用程序构建的CRUD应用程序？仅仅因为它在所有时髦的实时信息方面都表现出色，这是否就禁忌它用于更固定的用途？

我唯一能想到的就是缺乏成熟的库（尽管情况正在发生变化）。

（我问的原因是，我正在考虑放弃PHP以使用Node.js，主要是为了克服语言之间切换的阻抗不匹配问题，而且还可以重用验证代码和其他功能。我的超我劝告我选择最好的工具；但是，我没有太多的时间学习十五种语言及其所有的userland库，只是为了拥有一个全面的工具库，而且还可以确保Node.js可能为我提供比PHP /以后我必须开始考虑流量大的Apache。）

[编辑]到目前为止，谢谢大家。我只想看看在选择答案之前是否还有其他人会考虑。@Raynos的答案有点证实了我的想法，评论者的链接为我们提供了很好的思考，但是我想看看是否还有其他人有任何特定于节点的答案，例如“不要将节点用于问题X” '。（除了高CPU任务，我已经知道了:-)

有什么充分的理由要避免针对传统Web应用程序使用Node.js

是的，如果您在Web平台X中已有N年，那么显然您可以更快地在X平台上开发应用程序。

如果要执行Y，并且平台X具有执行X的预制解决方案Y，则可以这样做。

为什么您应该使用一个平台而不是另一个平台的所有一般原因。

您为内部业务应用程序构建的哪种CRUD应用程序？

是的，还有其他平台可以让您更快地编写通用应用程序。

但是，那样说。我对节点有丰富的经验，不能断言我会选择另一个平台而不是节点，除非它为我提供了大量功能。

基本上，这是一个简单的问题

是否存在为我完成所有这些工作的工具？不，然后选择最方便的平台来编写工具。

没有可靠的理由说明node.js是一个不方便的平台（除了“我讨厌javascript”之外）

在使用node几周后，我会说是的，它非常酷。但不一定是您想要使用的东西来替换您的常规Web应用程序... imo也不是。

记住，节点是它自己的服务器。如果您要运行的不仅仅是一个node.js应用程序，这将带来复杂性。即，如果您在一台计算机上托管了多个站点/域。它与LAMP堆栈不同，在LAMP堆栈中，您可以在同一个服务器上（至少在端口80上）运行六个针对不同域的PHP应用程序。有一些节点框架可能使之成为可能，但这增加了复杂性，如果您坚持使用传统的Web平台，则不需要这些复杂性。（当然，您也可以通过将Web服务器放置在节点的前面来设置代理，但这不利于使用节点的好处）。

imo，Node非常适合与传统的Web服务器一起使用。我现在组织的事情的方式是通过apache提供静态html / js / images，并通过长时间轮询节点应用程序来处理“实时”数据需求。

对节点有几秒钟思考的一个很好的理由不是技术性的-它的功能令人赞叹不已。

它们是业务，特别是人力资本，即知道它的程序员，它们的成本和可用性。学习起来并不难，但是与任何新技术一样，非常了解（或想要知道）的人只是大量工人中的一小部分。

我们必须问这是一个很好的问题，以免太过先进。

我很好奇（像Paul d'Aoust一样）知道Node.JS的局限性在哪里。可悲的是，许多答案都充满了主观偏见和暂时相关的理由。

我问自己：我们能否过滤出主观偏见并获得有关此问题的可靠答案？

其余几点似乎是：

1. NodeJS不如传统框架成熟。正如Paul d'Aoust所建议的那样，这只是暂时相关的原因，并非完全避免-而是进行审查和尽职调查。期望以Web专业人士的身份完成我们的作业，确定技术最适合组织，他们的需求，他们的未来，团队（而不是我们）的工作是我们的工作。成熟是需要澄清和判断风险偏好的判断，而不是避免风险的判断。

2. NodeJS作为代理服务器。事先讨论的明智建议值得回顾和考虑。这是将Node与现有技术相关联用作前端接口代理设计模式的概念。但是，这也不是要避免使用节点的原因，而是要避免将其完全替换的原因。而是选择推论方法。

3.调试节点。与Joyent的核心Node开发人员交谈时，围绕可调试性和追溯由核心导致的问题的根本原因（基于单线程执行和无法查看过去的线程）有很多麻烦。这是值得考虑和评估的-但是（再次）对于普通用法而言，可能不会仅仅避免可能会推波助澜的边缘情况。也许您的特定需求会属于此类，也许不会。

4.人力资源。这是在此页上避免使用JS的最佳原因，而我拙见，这是一个鲜明而又不便的事实。这就引出一个问题：您的公司是否有合适的专业人才来在整个生命周期中观察该项目？如果没有，那么毫无疑问您需要避免使用NodeJS。或者考虑A）寻找合适的人才，或B）教育现有人才。

投诉： 我对JavaScript的抱怨是，很多原因是用户错误，而不是源源不断的语言失败。我们已经对“ The Hate JavaScript Diatribe”的许多要求进行了揭穿，并且我们将继续对更多内容进行揭穿。这样的问题-文档不够好，不够性感，但是人们不喜欢它，它是癌症，它是魔鬼，或者它太“容易犯错”（-CRichardson），主观有偏见的投诉，需要剔除这些投诉才能做出准确的公司决策。

最后，正确的答案可能是- 没有充分的理由来避免使用NodeJS。也许这就是为什么它正在经历快速的增长，采用和贡献。但是对于我们所有人来说，这里的答案可能是继续更好地评估，研究和理解NodeJS-并寻求具体的厌恶情绪。在寻求开放以准确了解Node.JS不成熟的地方时-我们确切地找到了需要改进的地方。那是一种祝福。

好问题。我仍然对有人提出避免NodeJS的更好理由感到好奇-而不是这些。

对于非实时应用程序，在X上使用节点是否有任何好处：

• 扩展性：Node具有良好的性能，但其他平台也有。PHP，Ruby，Python和Java均可扩展。您可以找到数以百万计的用户使用的BIG名称。
• 前端和后端的一种语言：这是个玩笑，就像Java的“编写一次可在任何地方运行”
• 炙手可热：唯一有效的方法。但没人会在乎您的网站使用的是前卫技术！

对于非实时应用程序，使用X over Node的好处：

• 最佳实践：由于Node是新的，因此它的最佳实践比其他平台少，特别是针对CRUD Web应用程序。
• Javascript语言：人们不喜欢Javascript。尽管Node.js很热，但Javascript却不是。这就是为什么人们创建Coffeescript来避免甚至为客户端编写Javascript的原因。
• 开发速度：对于CRUD网站，经过多年测试和改进的旧的无聊框架（包括但不限于Rails和Django）。尽管您可以在Node中实现类似的应用程序，但是在您爷爷的框架中做起来就更容易了。
• 稳定性：Node的Web框架以更快的速度变得越来越好。这意味着它们正在变化，并且在不久的将来将具有更多的API不兼容。
• 库和工具：具有更多用户的较旧技术具有更多库和工具。

我的回答肯定在2015年将无效。2014年，对于非实时Web应用程序，请跳过Node，但请注意。

每个Web框架都有其长处。在这一点上使用它会很高兴。非实时Web应用程序不是Node Web框架的优点。

Node.js是非常流行的平台，它具有许多有趣的功能等等，但是使用工具是个人喜好。我给了Node.js四次，对此我感到不满意。这是我的原因。请记住，其中某些原因已过时，或者仅仅是个人原因：P

• 我喜欢其他语言/语法（我喜欢Python，Scala，我最喜欢的语言是Prolog，是的）。
• 我使用的框架和库的文档质量不如Java，Scala和Python库。
• Node.js的设计者非常着迷于回调，而不是事件模型，观察者或期货。
• 对于早在2005年开发的Ruby，Python和Java，我已经准备好解决方案，我只需要编辑配置文件即可。

HTTP是无状态的，因此实际上没有非实时Web应用之类的东西，因此没有理由不能为所有内容使用节点。

也就是说，节点更适合于特定类型的应用程序体系结构。PHP是包含一些代码的html文件。节点是可选包含一些html的代码。

这意味着，如果您的应用是没有任何客户端脚本的标准html表单，则PHP会更容易。Node确实具有模板工具，但显然不如PHP那样成熟。

如果您有很多客户端脚本，并使用ajax保存数据，那么最终在服务器上将出现静态html客户端调用函数。这正是节点所擅长的。虽然不是通常使用CRUD应用程序构建的方式，但是使用正确的框架可以产生一些不错的东西。