穿上石棉长裤……
昨天我在 Packt Publications 的头衔，Reactive Programming with JavaScript。它并不是一个真正以 Node.js 为中心的标题。前面的章节旨在涵盖理论，后面的代码繁重的章节涵盖实践。因为我真的不认为不给读者一个网络服务器是合适的，所以 Node.js 似乎到目前为止是显而易见的选择。案子还没被打开就已经结案了。
我本可以对我使用 Node.js 的体验给出一个非常乐观的看法。相反，我对遇到的好点和坏点很诚实。
让我在这里引用一些相关的引述：
警告：Node.js 及其生态系统热--热得足以让你大吃一惊！
当我担任数学老师的助理时，有人告诉我的一个不明显的建议是不要告诉学生某事“容易”。回想起来，原因有点明显：如果你告诉人们某事很容易，那么没有看到解决方案的人最终可能会觉得（甚至更）愚蠢，因为他们不仅不知道如何解决问题，而且还知道问题所在。他们太愚蠢了，理解起来很容易！
有些陷阱不仅会惹恼来自 Python / Django 的人，如果您更改任何内容，它们会立即重新加载源代码。对于 Node.js，默认行为是，如果您进行一项更改，旧版本将继续处于活动状态，直到时间结束或您手动停止并重新启动服务器。这种不恰当的行为不仅惹恼了 Python 爱好者；它还激怒了提供各种解决方法的本地 Node.js 用户。在撰写本文时，StackOverflow 问题“在 Node.js 中自动重新加载文件”已经获得了 200 多个赞成票和 19 个答案；编辑将用户定向到保姆脚本 node-supervisor，其主页位于 http://tinyurl.com/reactjs-node-supervisor。这个问题让新用户有很大的机会感到愚蠢，因为他们认为他们已经解决了这个问题，但旧的、有缺陷的行为完全没有改变。而且很容易忘记弹服务器；我已经多次这样做了。我想传达的信息是，“不，你并不愚蠢，因为 Node.js 的这种行为咬了你的背；只是 Node.js 的设计者认为没有理由在这里提供适当的行为。尝试应对它，也许从节点主管或其他解决方案那里获得一点帮助，但请不要因为你很愚蠢而走开。你不是有问题的人。问题在于 Node.js 的默认行为。”
经过一番讨论，这部分被留下来，正是因为我不想给人一种“很容易”的印象。我在让事情正常工作时反复割伤，我不想平息困难，让你相信让 Node.js 及其生态系统运行良好是一件简单的事情，如果它对你来说也不简单，你不知道你在做什么。如果您在使用 Node.js 时没有遇到令人讨厌的困难，那就太好了。如果你这样做了，我希望你不要走开感觉，“我很愚蠢——我一定有什么问题。”如果您在处理 Node.js 时遇到令人讨厌的意外，您并不愚蠢。不是你！这是 Node.js 及其生态系统！
在最后几章的渐强和结论之后，我并不真正想要的附录讨论了我在生态系统中能够找到的东西，并为白痴字面主义提供了一种解决方法：
另一个看起来非常合适并且可能还可以赎回的数据库是 HTML5 键值存储的服务器端实现。这种方法具有 API 的主要优势，大多数优秀的前端开发人员都非常了解。就此而言，它也是一个大多数不太好的前端开发人员都很好理解的 API。但是使用 node-localstorage 包，虽然不提供字典语法访问（您想使用 localStorage.setItem(key, value) 或 localStorage.getItem(key)，而不是 localStorage[key]），但实现了完整的 localStorage 语义，包括默认的 5MB 配额——为什么？服务器端 JavaScript 开发人员需要保护自己吗？
对于客户端数据库功能，每个网站 5MB 的配额确实是一个慷慨且有用的喘息空间，让开发人员可以使用它。您可以设置一个低得多的配额，并且仍然可以为开发人员提供比跛行和 cookie 管理不可估量的改进。 5MB 的限制并不能很快地用于大数据客户端处理，但是有一个非常慷慨的余量，足智多谋的开发人员可以用来做很多事情。但另一方面，在最近购买的大多数磁盘中，5MB 并不是特别大的一部分，这意味着如果您和网站在合理使用磁盘空间的问题上存在分歧，或者某些网站只是贪得无厌，它并不真正花费你很多，除非你的硬盘驱动器已经太满，否则你没有被淹没的硬盘驱动器的危险。如果余额少一点或多一点，也许我们会过得更好，但总的来说，这是解决客户端上下文内在紧张的一个不错的解决方案。
但是，可以温和地指出，当您是为您的服务器编写代码的人时，您不需要任何额外的保护来防止您的数据库大小超过可容忍的 5MB。大多数开发人员既不需要也不希望工具充当保姆并保护它们免于存储超过 5MB 的服务器端数据。 5MB 配额是客户端的黄金平衡行为，在 Node.js 服务器上有点愚蠢。 （并且，对于本附录中介绍的多用户数据库，可能会有点痛苦地指出，除非您在磁盘上为每个用户帐户创建单独的数据库，否则每个用户帐户不是 5MB；这是在每个用户帐户之间共享的 5MB所有用户帐户放在一起。如果病毒传播，那可能会痛苦！）文档指出配额是可自定义的，但是一周前给开发人员的一封电子邮件询问如何更改配额没有得到答复，因为StackOverflow 的问题是一样的。我能找到的唯一答案是在 Github CoffeeScript 源代码中，它被列为构造函数的可选第二个整数参数。所以这很容易，您可以指定一个等于磁盘或分区大小的配额。但是除了移植一个没有意义的特性之外，该工具的作者完全没有遵循一个非常标准的约定，即将 0 解释为变量或函数的“无限”，其中整数用于指定某些资源使用的最大限制。解决这个错误的最好办法可能是指定配额为 Infinity：
if (typeof localStorage === 'undefined' || localStorage === null)
{
var LocalStorage = require('node-localstorage').LocalStorage;
localStorage = new LocalStorage(__dirname + '/localStorage',
Infinity);
}
按顺序交换两个 cmets：
人们不断地使用 JavaScript 作为一个整体，不必要地自取其辱，而 JavaScript 成为受人尊敬的语言的一部分是道格拉斯·克罗克福德 (Douglas Crockford) 所说的，“JavaScript 作为一门语言有一些非常好的部分，也有一些非常糟糕的部分。这是好的部分。只是忘记那里还有其他东西。”也许炙手可热的 Node.js 生态系统会发展出自己的自己的“Douglas Crockford”，他会说，“Node.js 生态系统是一个编码狂野的西部，但也有一些真正的瑰宝可以找到。这是一个路线图。以下是几乎不惜一切代价避免的区域。以下是在任何语言或环境中都能找到的一些最富有的领域。”
也许其他人可以把这些话当作挑战，并效仿 Crockford 的做法，为 Node.js 及其生态系统写出“好的部分”和/或“更好的部分”。我要买一本！
鉴于所有项目的热情程度和纯粹的工作时间，可能需要在一年、两年或三年内大幅缓和在撰写本文时对不成熟生态系统的任何评论。五年后说“2015 年 Node.js 生态系统有几个雷区”可能真的有道理。 2020 Node.js 生态有多个天堂。”