为什么Meteor使用光纤而不是promises或async，或者可能是异步调用？ 什么是纤维的好处？有人可以解释这个架构决定吗？
答案 0 :(得分：22)
Straight from the horse's mouth，领导Meteor开发人员Geoff Schmidt：
Meteor致力于为游戏提供最佳体验 应用程序开发人员。我们不得不做出一些看似不受欢迎或冒险的决定，但这导致了一套工具 更简单，更强大，更有趣。 。 。 。事实证明 这些决定几乎没有风险或不受欢迎 有些人可能会察觉到。最好说他们走了 反对node.js社区的传统智慧。采取正义 例如，每个请求的线程或每个请求的进程模型 在较大的软件工程社区中很常见，而 有时会使用节点的连续传递（“异步”）样式 对于聊天服务器和消息总线，但几乎从未使用过 商业逻辑。我认为服务器端的JavaScript使用将会发生 在接下来的几年里，我们会增长多个数量级，我们就是这样 将有大量新开发人员涌入。大多数新代码 这些开发人员编写的将是业务逻辑，他们会想要 使用他们使用的直线控制流程来编写它 几乎所有其他框架。
引用a great article about Fibers in Meteor：
Meteor使用API提取Fibers，允许您编写应用程序 没有回调。最好的部分是你可以编写你的代码 方式，完全忘记纤维。 只是有效。
纤维是Meteor如此受欢迎的最佳原因之一。既然如此 允许我们编写没有回调的Node.js应用程序，它吸引了 许多开发人员出于这个原因讨厌Node.js。
换句话说，开发人员可以在不输入单词“Fiber”的情况下创建Meteor应用程序。这一切都发生在后台。因此大多数应用程序的大多数开发人员都没有理由关心“为什么是Fibers”而不是Promise或其他东西，因为开发人员并没有直接“使用”任何这些技术。 Meteor团队可以在引擎盖下重写Meteor核心，使用Promise而不是Fibers，大多数应用程序应该像以前一样继续运行，不知道变化。
至于为什么在Meteor核心本身，核心团队更喜欢Fibers over Promises等，从我所读到的（并在上面的Geoff Schmidt引用中暗示），这主要是他们的个人偏好 - 即。他们厌恶回调和代码，这些代码过于清楚其异步性质。他们希望为Meteor应用程序开发人员创建相同的回调 - 不经意的体验。