Can we know the updates regarding the plan on removing Fibers from Meteor and changing how async code works? There are three essential things that we need updates about:
Do we know how significant a change is required for our apps once Meteor removes fibers?
Do we have solutions (or plans) to problems raised by different developers about removing Fibers? I believe developers raised many items, but I am not seeing a place where these items are being tracked
Do we have target dates for releasing this, including beta versions, to start testing? The end of life for Node 14 is April 2023, which is a year away. But depending on the two items above, it might require months to migrate for those with large apps. Worst case scenario, those cases without compatible solutions through Meteor might require a re-write/re-design/migration, etc.
One year before the end of life for Fibers looks like a lot of time, but the author noted node-fibers obsolescence two years ago (April 23, 2020).
Try to make V8 support how Fibers work and coordinate with the NodeJS team to make it official for the subsequent versions of node (node 20 since node 18 is already out). This plan relies on multiple parties, and it seems no one is leading this effort (the author of Fibers does not want to be the proponent for this)
Compile a custom version of Node, removing the v8 commit that breaks fibers. Someone tried this for Node 16, and it worked. Not sure up to what version this will work, but Node 16 can give us until 2024.
I can’t say what the detailed plan is as I don’t really know it (yet…?), but I can assure you, that the async MongoDB API (the one that @harry97 linked) is being worked on. I know that as I’m actually working on it
Now I’d like to – at least partially – address the questions from @rjdavid. Keep in mind that there’s not a lot done already, so it may change.
It really depends on your app. I can imagine that for most apps, the async MongoDB API is going to be the most severe one. Next are any Promise.await() calls (they won’t be possible anymore) and probably some changes to Meteor.EnvironmentalVariables (I hope the API will stay the same, but some technical details may change).
All of that affects both our apps but also the packages, and that’s a bigger thing to do. There are a lot of them out there and as soon as the Fibers get removed and the API will change, I’d say that more than 80% of them will no longer work (I may be a little pessimistic on this one, but the most common packages are patching the APIs that will behave differently won’t be there at all). That means a lot of work for the Meteor Community Packages and Meteor Compat Packages.
As far as I know, there’s nothing written down except for the GitHub discussion you’ve already linked and the MongoDB PR that @harry97 linked. There’s also #async channel on Slack, but there’s not much in there (maybe there were but got removed already).
I do have to say that the list of places where Fibers are being created gathered by @filipenevola is a good start and something to be worked on.
Again, nothing I know of. However, I can imagine a request for testers of the async MongoDB API soon.
I don’t think it will happen.
As far as I remember, this made Fibers work, but broke with async_hooks and WebAssembly. As both are being used by more and more packages, I don’t think it’s a viable solution. (However, it may give us some time at the cost of the burden of maintaining it.)
Hmmh, vs 80% of all packages no longer working this seems to me the smaller problem and thus should seriously be looked at as an alternative.
I don’t want to sound too pessimistic but this project is either make or break. Meaning it fails and we can all put Meteor to the grave as those with (a lot of) problems will decouple from Meteor and it doesn’t seem at the same time that we were successful in selling Meteor as the hottest thing in town for a while (so basically no one will switch over).
But hey, I’d be happy if I’ve proven totally wrong on this and it will be a smooth ride
I don’t want to sound too pessimistic but this project is either make or break. Meaning it fails and we can all put Meteor to the grave as those with (a lot of) problems will decouple from Meteor and it doesn’t seem at the same time that we were successful in selling Meteor as the hottest thing in town for a while (so basically no one will switch over).
I agree with you on the severity of this update but we all understand how breaking this is and ready to bite the bullet in return of freeing Meteor from fibers so it’s not as pessimistic as it seems and many in the community would happily update their applications even if it requires more work. In the long run, this would actually help make Meteor “the hottest thing” as it’d be more aligned with the great Node.js ecosystem.
Unsure if it’s ok to share this, pls don’t mind me @pozylon but one of the reasons Unchained chose to migrate off of Meteor is how regressed it’s to bleeding edge Node and inability to keep up. And in hind sight, they’re kind of right with Node 16 and other issues looming in the distance. Which again, makes this update all the more important/necessary and even better for Meteor’s future.
I would love an informal meeting on that where all ppl interested in this topic can get on the same level. It’s a complicated topic and we need all power we can get. I also would love to see some ppl from Meteor Software there.
Maybe those who are already very deep into that topic can give a wrap up on the current state and how things work and how things suppose to work (in terms of code).
Maybe we can even make a regular meeting on this.i think this is the most important topic for Meteor’s future since it’s beginning.
As you have noticed @radekmie restarted the work in one of the first items related to Fibers. This is not an isolated work, we are reviewing the GitHub discussion and refining what has been discussed to reshare a clearer plan. This is our main priority now.
I hope that we can have this plan set by the end of the next week.
Just answering briefly…
We don’t need to remove Fibers that soon, as it works in runtime we can have something like a flag which your app could choose to enable/disable it.
We are reviewing this within our team and also with @filipenevola. His schedule is very busy but we had one initial discussion and we will have another in a few days.
We don’t have a target yet but we should have by the end of this planning. In my mind, I have one, the end of Q3. But this is just a guessing.
We all really appreciate @radekmie and @jkuester (I just saw a PR) availabilities. This is really important for the future of Meteor. Once we have the plan @denyhs will be also 100% focused on this. There are related tasks like supporting Top Level Await which @zodern can work on. We may have another developer from Quave also working on this. And, if any of you want to put your hands on this, it’s going to be very helpful, either by developing or testing.
I think a meeting with everyone would very though due to people schedule, timezones and so on. But we could create a new channel or use the #async channel to discuss this with a better frequency.
Like I said, in a few days we are going to have a newer plan and once we do, we will share it. We can name this a beta plan and then discuss it with who is really willing to help to make a final plan.
ps: we are in the final discussion to hire a new developer for Meteor, this person will also be focused in the framework. I hope to have a job description ready to be published it in the next week.
The job opportunity you sent here is not related to Meteor Software. We are still discussing the new developer position with Tiny.
Tiny and Meteor Software are both based in Canada, and here at Meteor Software, we’re a remote-first company, and the country we live in doesn’t matter. Currently, our team is made up of people living in Canada, Brazil, the Philippines, Portugal and the USA.
