Why does Meteor use fibers rather than promises or async or something else?

Question

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?

Answer 1

Straight from the horse's mouth, lead Meteor developer Geoff Schmidt:

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.

And to quote a great article about Fibers in Meteor:

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.

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.

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.

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.