I don’t understand the whole story. It seems that switching a fiber switches the whole stack while pausing the generator only switches the call stack one level deep. Or perhaps I misunderstood the problem completely. But I understand that this subtle difference would make it impossible to just swap out fibers by generators.
On the Stack Overflow question other people however claimed that they found a solution. Confusing. Are they right?
What do you think? Is it possible to swap out fibers by generators? What changes would this entail to Meteor?
From my point of view I always compared fibers with something like (service/web/…)workers, so something more thread-like, only with ‘more’ shared scope. But please correct me if I am wrong! And if thats the case, in any kind, it would not make a lot of sense to replace fibers w/ generators, at least to me.
I think generators (ES6) are intent to do iterations. But async/await (ES7) are definitely a replacement for fibers.
I mean, not using fibers at all. I think babel can output async/await transpiled code for both generators ready (node >= 4.x) and not yet ready (today’s browser’s, node <= 0.12) environments.
Fibers played really well on meteor’s mission (in fact, I never liked this non isomorphic server only feature provided by fibers), but we can’t forget to embrace the ecosystem (ES7). Not to say that fibers is a native compiled dependency, slowing down meteor upgrades/adoption of newest node.js releases.
Now meteor going full npm and node 4 on the way, it’d be really interesting to get some feedback from core about the plan with Fibers.
Over the last few years of Meteor London meetups the “what the fibers!?” question has come up time and again. It has always felt like that the gains in readability it added for server side code never quite justified the net increase in complexity it adds to the system as a whole, particularly with regards to the mismatch it causes between the functionality of the server and client apis.