I don’t think maintaining Fibers ourselves is necessary or a good long term plan. According to the readme, he is willing to continue maintaining Fibers, but warns that someday an update to Node or v8 could make it impossible to use Fibers.
I’ll continue to support newer versions of nodejs as long as possible but v8 and nodejs are extraordinarily complex and dynamic platforms. It is inevitable that one day this library will abruptly stop working and no one will be able to do anything about it.
Meteor uses Fibers to implement async/await: GitHub - meteor/promise: ES6 Promise polyfill with Fiber support · GitHub
If you look at a server file that uses async/await in a built Meteor app, they’ve been replaced with Promise.async and Promise.await. MDG’s plan was to hide the use of Fibers over time with promises to simplify using Fibers and reduce the impact of removing them in the future.
As far as I know, there are 3 main uses of Fibers:
- Meteor’s apis that use Fibers to allow writing synchronous code, for example
cursor.fetch,HTTP.get, orMeteor.user. We could create a separate method that returns a promise, and over time encourage it and depreciate the old methods. Though as @macrozone mentioned there would be challenges with getting this to work with Tracker/Blaze. Maybe it is time to rethink how we write reactive code? - App code that expects to be in a Fiber and is called by Meteor, for example methods, publications, and Meteor.startup.
- Some information is stored on the fiber’s object (accessible from Fibers.current). This is used for
Meteor.userId(), by core packages to detect if running in a Method simulation, and Kadira/Monti APM use it as a lower overhead alternative to async hooks.
Depreciating the use of Fibers would probably be a very long and difficult process, but I think it is worth starting due to the warning given by the node-fibers maintainer.