@hluz, I’m not sure if you’re using that reference to support continuing with Fibers? Could you clarify?
My interpretation of the presentation is that Fibers helped Meteor to adopt async/await in a backward compatible way. But I don’t think Benjamin made any arguments about Fibers being worth sticking with even in future. In fact he seems to support the idea that async/await is the solution (slides: 20, 21) for coroutines not being suitable for Javascript (slides: 18, 19)
I think nobody contests the reasoning behind adopting Fibers when Meteor was first released. That was probably a great decision at that time, especially since Promise was not common and async/await were unheard of in JS-land. But I also believe Meteor faltered in not incorporating the mainstream Node.js conventions fast enough. Situation improved drastically since Meteor 1.3, but I’m afraid that Fibers is one big obstacle still remaining (and releasing Meteor as npm packages would be the other thing, but Fibers is a bigger problem imho).
Also, the problems that I alluded to in my previous comments are in fact detailed by Benjamin himself in this presentation; see slides 40-50
If some developers still find Fibers (co-routines) making sense to their projects, it could be an opt-in (just like it is for other Node.js projects, using node-fibers) – maybe Meteor could make that a tad easier through a compiler plugin/package.