@vlasky see my earlier comment highlighting the parts of Ben’s presentation where he seems to acknowledge the points being echoed in this thread w.r.t Fibers.
Sure Fiber makes many things appear “easy”, as long as it works. But it’s a nightmare when it does cause a problem, the likelihood of which increases as you scale and/or use more 3rd party libraries. So far, the “ease of use” argument perhaps rightly trumped over the cons, justifying the tradeoffs. But there was no alternative then. Now we have one, in the form of async/await, and the best part is that it’s a proper standard!
Not only would removing Fiber make Meteor more approachable to other Node.js app developers and authors of libraries & tools, but it would also save the few precious resources currently working on the framework (mainly Ben, as per github stats) from spending time on unproductive work (i.e. no new framework feature) that Fiber keeps demanding… just look at some of the current open issues to get an idea:
- Consider removing fiber_pool.js · Issue #14 · meteor/promise · GitHub
- Don't force non-fiber-dependent code into fibers · Issue #9 · meteor/promise · GitHub
- Upgrade to Node 8.12 to address CPU usage problems related to fibers · Issue #10117 · meteor/meteor · GitHub
- react SSR with fibers and concurrency issues · Issue #10279 · meteor/meteor · GitHub
- Cannot step over a fiber yield when debugging server with Meteor 1.6 · Issue #9275 · meteor/meteor · GitHub
- Memory Leak/Fiber Bomb when EJSON type not declared · Issue #10032 · meteor/meteor · GitHub
All this just to pretend that we’re writing synchronous code on a platform that’s inherently asynchronous! Is that really worth all the trouble now that there’s a good/better alternative?
As an example of the overhead it would eliminate: the whole meteor/promise package won’t be needed if Fiber were to be removed! Note that Promise.await and Promise.async are not standard APIs.