如何决定何时使用Node.js？

我是这种东西的新手，但最近我听到很多关于Node.js的好处。 考虑到我一般喜欢使用jQuery和JavaScript，我不禁想知道如何决定何时使用Node.js。 我想到的Web应用程序就像Bitly一样 – 需要一些内容，将其归档。

从过去几天所做的所有功课中，我获得了以下信息。 Node.js的

• 是一个命令行工具，可以作为一个普通的Web服务器运行，让一个运行JavaScript程序
• 利用伟大的V8 JavaScript引擎
• 当你需要在同一时间做几件事情是非常好的
• 是基于事件的，所以所有精彩的Ajax类的东西都可以在服务器端完成
• 让我们在浏览器和后端之间共享代码
• 让我们与MySQL交谈

我遇到的一些来源是：

• 潜入Node.js – 介绍和安装
• 了解NodeJS
• 通过示例节点 （ Archive.is ）
• 让我们做一个Web应用程序：NodePad

考虑到Node.js几乎可以在Amazon的EC2实例上直接运行，我想了解什么types的问题需要Node.js而不是像PHP ， Python和Ruby那样的强大国王。 我明白，这实际上取决于对语言的专业知识，但是我的问题更多地归结为以下几个方面：什么时候使用特定的框架，哪种types的问题特别适合？

Answer 1

总结了Node.js的优点，你做了很棒的工作。 我的感觉是，Node.js特别适用于想要维护从浏览器到服务器的持续连接的应用程序。 使用称为“长轮询”的技术 ，您可以编写一个实时向用户发送更新的应用程序。 在Ruby on Rails或Django等许多Web巨头上进行长时间轮询会在服务器上造成巨大的负载，因为每个活动客户端都会占用一个服务器进程。 这种情况相当于一次攻击。 当你使用像Node.js这样的东西时，服务器不需要为每个打开的连接维护单独的线程。

这意味着您可以在Node.js中创build基于浏览器的聊天应用程序 ，几乎不需要任何系统资源即可为大量客户端提供服务。 任何时候你想做这样的长轮询，Node.js是一个很好的select。

值得一提的是，Ruby和Python都有这样的工具（分别是eventmachine和twisted ），但是Node.js却做得非常好，从头开始。 JavaScript对于基于callback的并发模型来说非常适合，而且它在这里非常出色。 另外，能够使用本地客户端和服务器的JSON来序列化和反序列化是非常漂亮的。

我期待在这里阅读其他的答案，这是一个奇妙的问题。

值得指出的是，Node.js对于在整个客户端/服务器间隙重用大量代码的情况也非常有用。 Meteor框架使得这非常简单，许多人认为这可能是Web开发的未来。 我可以从经验中得知，在Meteor中编写代码非常有趣，其中很大一部分花费的时间less于思考如何重构数据，因此浏览器中运行的代码很容易操纵它并将其传回。

这里有一篇关于金字塔和长轮询的文章，结果很容易在gevent的帮助下build立起来： TicTacToe和金字塔长轮询 。

Answer 2

我相信Node.js最适合于实时应用程序：在线游戏，协作工具，聊天室，或其他用户（或机器人或传感器）对应用程序所做的任何事情都需要立即被其他用户看到，没有页面刷新。

我还应该提到，与Node.js结合使用Socket.IO将比使用长轮询的可能性更大地减less实时延迟。 作为最糟糕的情况，Socket.IO将回退到长轮询，而是使用web套接字甚至是Flash（如果可用的话）。

但是我也应该提到，几乎所有可能因线程而阻塞的情况都可以通过Node.js解决。 或者你需要应用程序是事件驱动的任何情况。

另外Ryan Dahl在一次演讲中表示，我曾经参与过Node.js基准testing，与Ng​​inx的老版本HTTP请求密切对抗。 所以如果我们使用Node.js构build，我们可以非常有效地为普通资源提供服务，而当我们需要事件驱动的东西时，就可以处理它了。

再加上它一直都是JavaScript。 Lingua Franca在整个堆栈。

Answer 3

使用NodeJS的理由：

• 它运行Javascript，所以你可以在服务器和客户端上使用相同的语言 ，甚至可以在它们之间共享一些代码（例如用于表单validation，或者在任何一端渲染视图）。

• 单线程事件驱动系统即使在同时处理大量请求的情况下也很快 ，而且与传统的multithreadingJava或ROR框架相比也很简单。

• 通过NPM可访问的软件包不断增加，包括客户端和服务器端的库/模块，以及用于Web开发的命令行工具。 大多数这些方便地托pipe在github上，有时你可以报告一个问题，并find它在几个小时内修复！ 把所有东西都放在一个屋檐下，用标准化的问题报告和简单的分叉，是很好的。

• 它已经成为运行Javascript相关工具和其他networking相关工具 （包括任务运行者，缩小者，美化者，短毛绒，预处理器，捆绑器和分析处理器）的事实标准环境。

• 这似乎非常适合原型devise，敏捷开发和快速产品迭代 。

不使用NodeJS的原因：

• 它运行Javascript，它没有编译时types检查。 对于大型，复杂的安全关键系统，或包括不同组织之间协作的项目，鼓励合同界面和提供静态types检查的语言可以为您节省一些debugging时间（和爆炸 ）。 （尽pipeJVM卡住了null ，所以请将Haskell用于您的核反应堆。）

• 除此之外，新公共pipe理中的许多软件包都有些粗糙 ，而且还在迅速发展。 一些较老的框架库经历了十年的testing和bug修复，到目前为止非常稳定 。 Npmjs.org没有机制对软件包进行评分 ，导致软件包的扩散程度差不多相同，其中很大一部分不再维护。

• 嵌套的callback地狱。 （当然有20个不同的解决scheme …）

• 不断增长的软件包池可以使一个NodeJS项目与下一个NodeJS项目显得截然不同 。 由于有大量的可用选项（例如Express / Sails.js / Meteor / Derby ），因此实现方式差异很大。 这有时会使新开发人员更难以joinNode项目。 与join现有项目的Rails开发人员相比，他应该能够很快熟悉应用程序，因为所有的Rails应用程序都被鼓励使用类似的结构 。

• 处理文件可能有点痛苦。 在其他语言中微不足道的东西，比如从文本文件中读取一行，对于Node.js来说是非常奇怪的 ，那就是StackOverflow有80多个upvotes的问题。 从CSV文件中一次只能读取一条logging，没有简单的方法 。 等等。

我喜欢NodeJS，它是快速，狂野和有趣的，但我担心它对可certificate的正确性没有兴趣。 希望我们能最终融合两全其美。 我渴望看到什么将在未来取代节点… 🙂

Answer 4

为了简短：

Node.js非常适合具有大量并发连接的应用程序，并且每个请求只需要很less的CPU周期，因为事件循环（与所有其他客户端）在执行一个函数期间被阻塞。

关于Node.js中事件循环的一篇很好的文章是Mixu的技术博客：了解node.js事件循环 。

Answer 5

我有一个真实世界的例子，我已经使用Node.js。 我工作的公司有一个客户想要一个简单的静态HTML网站。 这个网站是用PayPal销售一件商品的，客户也希望有一个柜台可以显示出售商品的数量。 客户预计将有大量的访问者访问这个网站。 我决定使用Node.js和Express.js框架来制作计数器。

Node.js应用程序很简单。 从Redis数据库获取已售物品数量，在出售物品时增加计数器，并通过API向用户提供计数器值。

在这种情况下，我select使用Node.js的一些原因

1. 这是非常轻量级和快速的。 这个网站在三周内已经有超过20万的访问量，而最less的服务器资源已经能够处理这一切。
2. 柜台真的很容易做到实时。
3. Node.js很容易configuration。
4. 有很多模块可以免费使用。 例如，我为PayPalfind了一个N​​ode.js模块。

在这种情况下，Node.js是一个很棒的select。

Answer 6

使用Node开始下一个项目的最重要的原因…

• 所有最酷的家伙都进入了它…所以它一定很有趣。
• 你可以在冷藏室聚会，并有很多的冒险冒险。
• 当涉及到云托pipe成本时，你是一分钱捕手。
• 在那里用Rails做到了
• 你讨厌IIS部署
• 你以前的IT工作变得相当沉闷，你希望你在一个新的启动。

什么期望…

• 使用Express，您将感到安全，无需任何您不需要的服务器臃肿软件。
• 像火箭一样运行，尺度很好。
• 你做梦吧。 你安装了它。 节点包repo npmjs.org是世界上最大的开放源码库生态系统。
• 你的大脑会在嵌套callback的土地上时间扭曲…
• …直到你学会遵守你的承诺 。
• Sequelize和Passport是你的新朋友。
• debugging大多数asynchronous代码将得到嗯… 有趣的 。
• 所有节点掌握Typescript的时间 。

谁使用它？

• PayPal，Netflix，沃尔玛，LinkedIn，Groupon，Uber，GoDaddy，道琼斯
• 这就是为什么他们切换到节点 。

Answer 7

没有什么像银弹。 一切都伴随着一些相关的成本。 这就像是如果你吃油腻的食物，你会伤害你的健康，健康的食物不会像油性食物一样的香料。 他们是否需要健康或香料，如他们的食物是个人select。 同样的方法Node.js考虑在特定情况下使用。 如果你的应用程序不适合这种情况，你不应该考虑你的应用程序开发。 我只是把我的想法一样：

何时使用Node.JS

1. 如果你的服务器端代码需要很less的CPU周期。 在其他的世界，你正在做非阻塞操作，并没有繁重的algorithm/任务，消耗大量的CPU周期。
2. 如果你是从Javascript的背后和舒适的写单线程代码就像客户端JS。

何时不使用Node.JS

1. 您的服务器请求取决于沉重的CPU消耗algorithm/作业。

使用Node.JS的可伸缩性考虑

1. Node.JS本身不利用底层系统的所有核心，默认情况下是单线程的，你必须自己编写逻辑来利用多核处理器并使其成为multithreading。

Node.JS的替代品

还有其他的select来代替Node.JS，但是Vert.x似乎很有希望，并且有很多额外的特性，比如polygot和更好的可伸缩性考虑。

Answer 8

另外一个我认为没有人提到的关于Node.js的伟大的事情是令人惊叹的社区，包pipe理系统（npm）以及存在的模块数量，只要将它们包含在package.json文件中即可。

Answer 9

我的作品：nodejs非常适合制作分析，聊天应用程序，apis，广告服务器等实时系统。地狱，我在2小时内使用nodejs和socket.io创build了我的第一个聊天应用程序，在考试周也是这样。

编辑

自从我开始使用nodejs已经有好几年了，我已经用它来做许多不同的事情，包括静态文件服务器，简单的分析，聊天应用程序等等。 这是我采取什么时候使用nodejs

何时使用

制作强调并发性和速度的系统。

• 仅插入聊天应用程序，irc应用程序等服务器
• 强调地理位置，videostream，audiostream等实时资源的社交networking
• 处理小块数据的速度非常快，就像分析web应用程序一样。
• 作为暴露一个REST唯一的api。

什么时候不用

它是一个非常灵活的networking服务器，所以你可以使用它，无论你想要的，但可能不是这些地方。

• 简单的博客和静态网站。
• 就像一个静态文件服务器一样。

请记住，我只是挑剔。 对于静态文件服务器，apache主要是因为它是广泛可用的。 多年来，nodejs社区变得越来越大，越来越成熟，可以肯定的是，如果您有自己的托pipeselect，nodejs可以在任何地方使用。

Answer 10

它可以用在哪里

• 高度事件驱动的应用程序和严重的I / O限制
• 处理大量与其他系统连接的应用程序
• 实时应用程序（Node.js是从头开始实时devise的并且易于使用）。
• 应用程序，串stream来自其他来源的大量信息
• 高stream量，可扩展的应用
• 移动应用程序必须与平台API和数据库进行交stream，而不必进行大量的数据分析
• build立networking应用程序
• 需要经常与后端交谈的应用程序

在移动方面，黄金时段的公司依靠Node.js来提供移动解决scheme。 看看为什么？

LinkedIn是一位杰出的用户。 他们的整个移动堆栈build立在Node.js上。 他们从每个物理机器上运行15个服务器的15个实例运行到只有4个实例 – 可以处理双倍的stream量！

eBay推出了ql.io，一种HTTP API的网页查询语言，它使用Node.js作为运行时栈。 他们能够调整一个普通的开发人员素质的Ubuntu工作站来处理每个node.js进程的超过120,000个活动连接，每个连接消耗大约2kB的内存！

沃尔玛重新devise了其移动应用程序以使用Node.js并将其JavaScript处理推送到服务器。

阅读更多： http : //www.pixelatingbits.com/a-closer-look-at-mobile-app-development-with-node-js/

Answer 11

最适合并发请求处理的节点 –

所以，让我们从一个故事开始。 从过去两年来，我正在从事JavaScript和开发Web前端，我很享受。 后端人提供了我们用Java编写的一些API，python（我们不关心），我们只是写一个AJAX调用，获取我们的数据，并猜测是什么！ 我们完了。 但实际上并不容易，如果我们得到的数据不正确，或者有一些服务器错误，那么我们就会卡住，我们必须通过邮件或聊天联系我们的后端人员（有时在whatsApp上:)）不是很酷。 如果我们用JavaScript编写我们的API并从我们的前端调用这些API呢？ 是的，这很酷，因为如果我们面对API中的任何问题，我们可以研究它。 你猜怎么了 ！ 你现在可以做到这一点，怎么样？ – 节点在那里为你。

确定同意你可以在JavaScript中编写你的API，但是如果我对上述问题还好，该怎么办？ 你有任何其他的理由使用节点的restAPI？

所以这里是魔法开始。 是的，我还有其他的理由来使用我们的API的节点。

让我们回到我们传统的基于阻塞操作或线程的rest API系统。 假设发生两个并发请求（r1和r2），每个请求都需要数据库操作。 所以在传统系统中会发生什么：

1.等待方式：我们的服务器开始服务r1请求并等待查询响应。 在完成r1 ，服务器开始服务r2并以相同的方式进行。 所以等待不是一个好主意，因为我们没有那么多时间。

2.线程方式：我们的服务器将为请求r1和r2创build两个线程，并且在查询数据库之后为其目的服务，以便冷却它的快速。但是由于你可以看到我们启动了两个线程，所以当这两个请求都是查询时，相同的数据，那么你必须处理死锁types的问题。 所以它比等待的方式好，但仍然是问题在那里。

现在是，节点将如何做到这一点：

3. Nodeway：当同一个并发请求进入节点时，它将用callback注册一个事件，并向前移动它不会等待特定请求的查询响应。所以当r1请求到来时，节点的事件循环（是的，有一个事件循环在服务于此目的的节点中）注册具有其callback函数的事件并向前移动以提供服务r2请求，并以其callback类似地注册其事件。 每当任何查询完成时，触发其相应的事件，并执行其callback完成而不会中断。

所以没有等待，没有线程，没有内存消耗 – 是的这是服务rest API的节点。

Answer 12

我另外一个selectNode.js的理由是：

能够做纯粹的基于云的开发

我已经使用Cloud9 IDE一段时间了，现在我无法想象没有它，它涵盖了所有的开发生命周期。 所有你需要的是一个浏览器，你可以随时随地在任何设备上编码。 你不需要在一台计算机上登记代码（比如在家里），然后在另一台计算机上登记（比如在工作地点）。

当然，其他语言或平台也可能有基于云的IDE（云9 IDE也增加了对其他语言的支持），但是使用Cloud 9做Node.js开发对我来说真的是一个很棒的体验。

Answer 13

节点提供的另外一件事是能够使用节点的subprocess（ childProcess.fork（） ，每个文档需要10MB内存）创build多个v8节点实例 ，因此不会影响运行服务器的主进程。 因此，卸载需要巨大服务器负载的后台作业就成了孩子们的玩耍，我们可以在需要时轻松杀死它们。

我一直在使用节点，并在我们构build的大多数应用程序中，同时需要连接服务器，因此networkingstream量很大。 像Express.js和新的Koajs （删除callback地狱）的框架，使节点工作更容易。

Answer 14

穿石棉长裤

昨天，我与Packt出版社合作， 使用JavaScript进行反应式编程 。 这不是一个真正的Node.js为中心的标题; 前面的章节是为了涵盖理论，后面的代码重的章节涵盖了实践。 因为我真的不认为不给读者一个networking服务器是合适的，所以Node.js似乎是一个明显的select。 这个案子在开放之前就已经closures了。

我可以对Node.js的使用体验给予非常好的看法。 相反，我对我所遇到的好点和坏点诚实。

让我包括几个在这里相关的引用：

警告：Node.js及其生态系统很热，足以烧毁你！

当我是math老师的助理的时候，我被告知的一个不明显的build议就是不要告诉学生有什么“容易”的东西。回想起来，这个理由有些明显：如果你告诉人们一些容易的事，没有看到一个解决scheme可能最终感觉（甚至更多）愚蠢的，因为他们不仅没有得到如何解决这个问题，但他们太笨的问题是一个容易的问题！

有一些小问题不仅会让来自Python / Django的人感到烦恼，如果您更改了任何东西，它们会立即重新加载源代码。 使用Node.js，缺省行为是，如果进行一次更改，则旧版本将一直保持活动状态，直到时间结束，或者直到您手动停止并重新启动服务器为止。 这种不恰当的行为不仅仅会惹恼Pythonistas; 这也刺激了提供各种解决方法的本地Node.js用户。 在写这篇文章的时候，StackOverflow问题“在Node.js中自动重载文件”有超过200个upvotes和19个答案; 一个编辑会将用户导向一个保姆脚本，节点监督员，在http://tinyurl.com/reactjs-node-supervisor上有主页。; 这个问题使得新用户有很大的机会感到愚蠢，因为他们认为他们已经解决了这个问题，但是旧的，bug的行为是完全不变的。 而且很容易忘记弹回服务器。 我已经多次这样做了。 我想给出的信息是，“不，你不是愚蠢的，因为Node.js的这种行为会让你退缩; 只是Node.js的devise者没有理由在这里提供适当的行为。 试着去应付它，或者从节点主pipe或其他解决scheme那里得到一些帮助，但请不要走开，觉得你是愚蠢的。 你不是那个有问题的人。 问题在于Node.js的默认行为。“

这个部分经过一番辩论后，留下来，正是因为我不想给人一个“很容易”的印象，我一边工作，一边反复剪手，我不想平息困难，让你相信让Node.js及其生态系统正常工作是一件很简单的事情，如果你也不直截了当，你就不知道自己在做什么。 如果你使用Node.js不会遇到令人讨厌的困难，那太棒了。 如果你这样做，我希望你不要离开感觉，“我很愚蠢 – 我一定有什么问题”。如果你遇到与Node.js相关的令人讨厌的惊喜，那么你并不愚蠢。 不是你！ 这是Node.js及其生态系统！

附录在最后几章和结论中的渐增高潮之后并不是我真正想要的，它谈到了我在生态系统中能find的东西，并提供了一个解决方法：

另一个看似完美的数据库可能还可以兑换，它是HTML5键值存储的服务器端实现。 这种方法有一个API的主要优点，大多数优秀的前端开发人员都能理解。 对于这个问题，这也是大多数不太好的前端开发人员所理解的API。 但是对于node-localstorage包，虽然没有提供字典语法访问（您想要使用localStorage.setItem（key，value）或localStorage.getItem（key），而不是localStorage [key]），但实现了完整的localStorage语义，包括一个默认的5MB配额 – 为什么？ 服务器端JavaScript开发人员是否需要受到保护？

对于客户端数据库function，每个网站5MB的配额实际上是一个慷慨和有用的呼吸空间，让开发人员使用它。 你可以设置一个低得多的配额，并为开发人员提供一个无法比拟的改进，同时还有cookiepipe理。 一个5MB的限制不适合大数据客户端处理，但是有一个非常慷慨的余地，资源丰富的开发人员可以用来做很多事情。 但另一方面，5MB不是大多数最近购买的磁盘的一大部分，这意味着如果你和一个网站不同意什么是合理使用磁盘空间，或者某个站点是简单的哈希，它并不真正花费你很多，除非你的硬盘已经满了，否则你不会有硬盘的危险。 也许如果余额稍微less一点，我们会好一些，但总的来说，解决客户端环境的内在紧张是一个体面的解决scheme。

但是，可能会轻轻地指出，如果您是服务器的一个编写代码，则不需要任何额外的保护就可以使您的数据库超过容许的5MB大小。 大多数开发人员既不需要也不需要工具作为保姆，并保护他们存储超过5MB的服务器端数据。 而在客户端的5MB配额是一个黄金的平衡行为，在Node.js服务器上相当有点愚蠢。 （而且，对于本附录中介绍的多用户数据库，可能会稍微痛苦地指出，除非您为每个用户帐户在磁盘上创build一个单独的数据库，否则每个用户帐户不得超过5MB;所有的用户帐户在一起，如果你病毒化，这可能会变得很痛苦 ）文档指出配额是可定制的，但一个星期前发给开发者的电子邮件询问如何改变配额是没有答案的，就像StackOverflow问题一样。 我能find的唯一答案是在Github CoffeeScript源代码中，它被列为构造函数的可选第二个整数参数。 所以这很容易，你可以指定一个等于磁盘或分区大小的配额。 但是，除了移植一个没有意义的特性之外，该工具的作者没有完全遵循一个非常标准的解释约定0，意思是“无限”的variables或函数，其中整数是为某些资源使用指定最大限制。 对这种错误行为做最好的事情可能是指定配额是无限的：

 if (typeof localStorage === 'undefined' || localStorage === null) { var LocalStorage = require('node-localstorage').LocalStorage; localStorage = new LocalStorage(__dirname + '/localStorage', Infinity); } 

依次交换两个评论：

人们不断地用JavaScript作为一个整体，脚本中的一部分，JavaScript的一部分成为可敬的语言是道格拉斯·克罗克福德（Douglas Crockford）本质上所说的：“JavaScript作为一种语言有一些非常好的部分和一些非常糟糕的部分。 这是好的部分。 只要忘记其他东西就可以了。“也许热门的Node.js生态系统将会发展自己的 ”道格拉斯·克罗克福德“（Douglas Crockford），他会说：”Node.js生态系统是Wild West的一个编码，但是还有一些真正的gem可以find。 这是一个路线图。 这几乎是任何成本都要避免的地方。 这里有一些在任何语言或环境中都可以find的最富有的支付方式。“

也许别人可以把这些话作为一个挑战，并且按照克罗克福的领导，写出Node.js及其生态系统的“好的部分”和/或“更好的部分”。 我会买一份！

考虑到所有项目的热情程度和绝对的工作时间，可能需要一两年或三年的时间来对本文写作时对于一个不成熟的生态系统所做的任何评论进行尖锐的调整。 在五年内确实有意义的说，“2015年的Node.js生态系统有几个雷区。 2020 Node.js生态系统有多个天堂。“

Answer 15

如果您的应用程序主要是限制web apis或其他io频道，给予或采取用户界面，node.js可能是您的一个公平select，特别是如果您想挤出最可伸缩性，或者，如果您的主要语言在生活是JavaScript（或各种各样的javascript transpilers）。 如果你构build微服务，node.js也是可以的。 Node.js也适用于任何小型或简单的项目。

Its main selling point is it allows front-enders take responsibility for back-end stuff rather than the typical divide. Another justifiable selling point is if your workforce is javascript oriented to begin with.

Beyond a certain point however, you cannot scale your code without terrible hacks for forcing modularity, readability and flow control. Some people like those hacks though, especially coming from an event-driven javascript background, they seem familiar or forgivable.

In particular, when your application needs to perform synchronous flows, you start bleeding over half-baked solutions that slow you down considerably in terms of your development process. If you have computation intensive parts in your application, tread with caution picking (only) node.js. Maybe http://koajs.com/ or other novelties alleviate those originally thorny aspects, compared to when I originally used node.js or wrote this.

Answer 16

I can share few points where&why to use node js.

1. For realtime applications like chat,collaborative editing better we go with nodejs as it is event base where fire event and data to clients from server.
2. Simple and easy to understand as it is javascript base where most of people have idea.
3. Most of current web applications going towards angular js&backbone, with node it is easy to interact with client side code as both will use json data.
4. Lot of plugins available.

Drawbacks:-

1. Node will support most of databases but best is mongodb which won't support complex joins and others.
2. Compilation Errors…developer should handle each and every exceptions other wise if any error accord application will stop working where again we need to go and start it manually or using any automation tool.

Conclusion:- Nodejs best to use for simple and real time applications..if you have very big business logic and complex functionality better should not use nodejs. If you want to build an application along with chat and any collaborative functionality.. node can be used in specific parts and remain should go with your convenience technology.

Answer 17

1. Node is great for quick prototypes but I'd never use it again for anything complex. I spent 20 years developing a relationship with a compiler and I sure miss it.

2. Node is especially painful for maintaining code that you haven't visited for awhile. Type info and compile time error detection are GOOD THINGS. Why throw all that out? For what? And dang, when something does go south the stack traces quite often completely useless.