为什么 Meteor 使用 Fiber 而不是 promises 或 async 或其他东西? [英] Why does Meteor use fibers rather than promises or async or something else?
问题描述
为什么 Meteor 使用 Fiber 而不是 promises 或 async 或者可能是左异步调用?纤维有什么好处?有人可以解释一下架构决策吗?
Why does Meteor use fibers rather than promises or async or maybe left asynchronous calls? What are the fibers benefits? Can someone explain that architectural decision?
推荐答案
直接出身，首席 Meteor 开发人员 Geoff Schmidt:
Straight from the horse's mouth, lead Meteor developer Geoff Schmidt:
Meteor 专注于为用户提供最佳体验应用开发者.我们不得不做出一些看似不受欢迎或有风险的决定才能达到目标，但这产生了一套工具更简单、更强大、使用起来更有趣....事实证明这些决定几乎没有风险或不受欢迎有些人可能会察觉.最好说他们去反对 node.js 社区的传统智慧.只取一个例子，thread-per-request 或 process-per-request 模型是在较大的软件工程社区中非常普遍，而有时会使用节点的延续传递(异步")样式用于聊天服务器和消息总线，但几乎从未用于商业逻辑.我认为服务器端 JavaScript 的使用将会在未来几年内以多个数量级增长，我们正在将有大量新开发人员涌入.大部分新代码这些开发人员编写的将是业务逻辑，他们会想要用他们使用过的直线控制流来编写它几乎所有其他框架.
Meteor is focused on giving the best possible experience to the application developer. We've had to make some seemingly unpopular or risky decisions to get there, but that has resulted in a set of tools that are simpler, more powerful, and more fun to use. . . . it turns out that these decisions are not nearly as risky or as unpopular as some people might perceive. It would be better to say that they go against the conventional wisdom in the node.js community. To take just one example, the thread-per-request or process-per-request model is very common in the larger software engineering community, whereas node's continuation passing ("asynchronous") style is sometimes used for chat servers and message busses but is almost never used for business logic. I think that server-side JavaScript usage is going to grow by multiple orders of magnitude in the next few years, and we're going to have a massive influx of new developers. Most of the new code that these developers write will be business logic, and they'll want to write it with the straight-line control flow that they've used in almost every other framework.
Meteor 用它的 API 抽象出 Fibers，让您可以编写您的应用程序没有回调.最好的部分是你可以写你的代码方式，完全忘记纤维.它正常工作.
Meteor abstracts Fibers with its APIs, allowing you to write your app without callbacks. The best part is that you can write your code this way and be completely oblivious to Fibers. It just works.
纤维是 Meteor 如此受欢迎的最好原因之一.既然允许我们编写没有回调的 Node.js 应用程序，它吸引了许多开发人员因此讨厌 Node.js.
Fibers is the one of the best reasons Meteor is so popular. Since it allows us to write Node.js apps without callbacks, it has attracted many developers who hated Node.js for that reason.
换句话说，开发人员无需输入Fiber"一词即可创建 Meteor 应用程序.这一切都发生在后台.因此，大多数应用程序的大多数开发人员真的没有理由关心为什么使用 Fibers"与 Promise 或其他东西，因为无论如何开发人员都不会直接使用"任何这些技术.Meteor 团队可以在幕后重写 Meteor 核心以使用 Promises 而不是 Fibers，并且大多数应用程序应该像以前一样继续运行，而无需考虑更改.
In other words, you the developer can create Meteor apps without ever typing the word "Fiber". It all happens in the background. So most developers for most apps really have no reason to care "why Fibers" versus Promise or something else, because the developers aren't "using" any of those technologies directly anyway. The Meteor team could rewrite Meteor core under the hood to use Promises instead of Fibers and most apps should continue running just as before, oblivious to the change.
至于为什么在 Meteor 核心本身中，核心团队更喜欢 Fibers 而不是 Promises 等，从我读到的(并且在上面的 Geoff Schmidt 引用中暗示)，这主要是他们的个人偏好——即他们厌恶回调和过度意识到其异步性质的代码.他们希望为自己创造与 Meteor 应用程序开发人员相同的无回调体验.
As for why in the Meteor core itself the core team preferred Fibers over Promises etc., from what I've read (and is hinted at in the Geoff Schmidt quote above) it's mostly their personal preference—i.e. their aversion to callbacks and code that is overly conscious of its asynchronous nature. They want the same callback-oblivious experience for themselves that they create for Meteor application developers.
这篇关于为什么 Meteor 使用 Fiber 而不是 promises 或 async 或其他东西?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
