【问题标题】:Why and when to use Node.js? [duplicate]为什么以及何时使用 Node.js? [复制]
【发布时间】:2011-08-02 19:49:51
【问题描述】:

可能重复:
How to decide when to use Node.js?

对不起,如果我有点模棱两可,但我试图了解使用 Node.js 而不是其他服务器端语言的真正优势。

我是一名 JavaScript 爱好者,所以我可能会使用 Node.js,但我想知道是否应该在我的项目中使用它。

【问题讨论】:

  • 可能想看看这个video
  • @Raynos 感谢分享视频。
  • @kjy112 我建议你用谷歌视频搜索“ryan dahl node.js”,应该有4个左右。都很好。
  • 我觉得奇怪的是,none 的答案将node.js 与当今最具可比性(且使用率最高)的替代方案php 进行比较/对比!

标签: javascript node.js serverside-javascript server-side


【解决方案1】:

最常被引用的两个优点是:

  • JavaScript 既是服务器端又是客户端。需要学习的东西更少,上下文切换更少,并且能够在两端重用代码。
  • 使用非阻塞 I/O 和 Chrome 的 V8 引擎,提供快速、高度可扩展的服务器。

但对我来说,最有趣的部分是该领域发生的活动量。有很多非常有趣的节点正在开发中 - 请务必查看list of Node.js modules

【讨论】:

  • 可能会重新订购这些。代码重用没什么大不了的。事件非阻塞 IO 和真正快速的可扩展服务器是一个交易。
  • 我们几乎必须使用 Javascript 客户端。当有更好的语言(如 Python)可用时,我认为必须在服务器端使用它是一个缺点
【解决方案2】:

就个人而言,我最有可能在以下情况下使用 Node.js:

  • 我想写一个不使用HTTP protocol的服务器。
  • 我正在设计一个服务器实现的原型。
  • 我正在编写一个预计不会产生大量流量的服务器(尽管我从未在一个匹配的 C++ 实现旁边分析过 Node.js 实现)。
  • 我想在社区中活跃起来(显然这个社区正在迅速增长)。

【讨论】:

  • @DemianBrecht 我想你会发现 node.js 是一个 真正 快速的服务器,可以处理 很多 的流量。如果你想要更好的东西,用 C 手写一个 HTTP 服务器。
  • @Raynos 我认为它可以简单地基于它使用 V8 的事实:) 话虽如此,请原谅我的无知,但恕我直言,在构建大型服务器时(例如游戏等) ) 你在强类型、OO、编译语言中损失了太多 FAR。
  • @Raynos 可能是我对自己的解释不够好。无论如何,我真的需要进一步深入研究 node.js :) 我并不担心优化我是整体系统架构。我意识到编写一些子系统的脚本的好处,但是我看不到用 Javascript 开发一个完整的系统框架有助于扩展性等等,这就是为什么我提到你会因偏离使用而遭受的损失以强类型、OO、编译语言为基础。
  • @DemianBrecht 你不会失去任何远离强类型、OO 和编译的东西。只是态度不同而已。您编写函数式风格的代码。您可以像在 JavaScript 中一样轻松地使用 C++ 编写意大利面条式维护噩梦。您还可以使用 JavaScript 编写与使用 C++ 一样强大的可维护架构。 JavaScript 不是一种玩具语言。就像Scheme。
  • @DemianBrecht 在某些方面我同意经典 C++ 风格的 OO 允许您处理所有开发人员都具有一系列培训专业知识的大型代码库。至少我可以确认这是基于合理的原因而不是无知。在 node 中编写大型可维护的 100k+ 代码库是一项艰巨的任务。 C++ 已经有它的跟踪和错误阶段。你的权利,尽管在 SO 上喝几杯酒是不可行的,也许是几品脱的争论?
【解决方案3】:

如果您是(或者即使您不是)JavaScript 爱好者,您可以/应该使用 Node.js,原因有很多:

  • 它是一个低级、轻量级的独立框架,将 JavaScript 的强大功能带入服务器端环境。
  • 如果您喜欢更高级别的抽象,那么有大量的 modulesnpm 包管理器,您可以在其中找到各种即用型应用程序。
  • 快速/无阻碍的开发过程 - 例如,您无需大量额外工具即可开始编写严肃的内容。
  • 基于开源的大型社区,充满了爱好者和才华横溢的人。
  • 专为创建面向 Web 的实时应用而设计 - 这就是(不远的)未来。

【讨论】:

  • 您不必是 JavaScript 爱好者!
【解决方案4】:

它是在 V8 之上构建的异步非阻塞 I/O

所以我们获得了谷歌 JavaScript 解释器 V8 的所有性能提升。由于 JavaScript 性能竞赛尚未结束,您可以期待 Google 不断更新 V8 的性能(免费)。

我们有非阻塞 I/O,这是执行 I/O 的正确方法。这是基于事件循环并为您的 I/O 使用异步回调。

它为您提供了有用的工具,例如创建 HTTP 服务器、创建 TCP 服务器、处理文件 I/O。

它是一个低级高性能平台,可用于执行任何类型的 I/O,而无需从头开始用 C 语言编写整个东西。由于非阻塞 I/O,它可以很好地扩展。

因此,如果您想使用非阻塞 I/O 编写高度可扩展且高效的应用程序,同时仍然拥有可用的高级脚本语言,那么您想使用 Node.js。如果需要,您可以通过用 C 编写扩展来手动优化部分代码。

有很多用于 Node.js 的操作系统库可以为您提供抽象,例如 Express.jsnow

如果您希望(缓慢的)高级抽象为您做所有事情,您不想使用 Node.js。如果你想要RAD,你就不想使用 Node.js。如果你不能信任一个年轻的平台,你就不想使用 Node.js,要么是因为必须自己编写大量代码来执行构建到其他框架中的事情,要么是因为你不能使用 Node .js,因为 API 还不稳定,或者它是 1.0 的子版本。

【讨论】:

  • > "如果你想要 RAD,你就不想使用节点。"你的意思是说在 Node 中开发东西通常需要更长的时间吗?
  • @Gerry RAD 包含一个非常高级的框架,它可以为您完成很多的工作,但代价是非常小的灵活性。它基本上为你做了很多通用的样板。 node 是一个低级库。
  • @Gerry 取决于您对“框架”的定义。 Express 是一个非常有用但仍不支持 RAD 的 http 框架。我相信人们将 cakephp 和 rails 移植到节点。这类框架可能允许 RAD,但也充满了糟糕的设计和反模式
  • @Gerry Rails 没有问题。这只是一个巨大的抽象。有取舍。我只是不会在节点上构建类似rails的东西,因为节点有更好的模式
  • 啊,反模式,因为它最初不是为节点构建的?有道理。
猜你喜欢
  • 2015-12-10
  • 2011-08-14
  • 2012-03-06
  • 2011-01-08
  • 1970-01-01
  • 1970-01-01
  • 2015-06-20
  • 1970-01-01
  • 2013-06-13
相关资源
最近更新 更多