will meteor move to async/await?
NOTE OF OBSOLESCENCE – The author of this project recommends you avoid its use if possible. The original version of this module targeted nodejs v0.1.x in early 2011 when JavaScript on the server looked a lot different. Since then async/await, Promises, and Generators were standardized and the ecosystem as a whole has moved in that direction.
Seems something to add to the roadmap. node-fibers should be good until Node 14
The discussion on this has already been started, but nothing concrete so far.
Fibers !== async/await
While async/await can turn asynchronous tasks into synchronous we all should think of Fibers as of coroutines.
At the same time async/await+workers can be a good substitution for Fibers.
Maybe MDG can respond to my applications (yes, plural) and hire me to solve this task 
I agree, Fibers is more than just syntactic sugar for writing asynchronous code.
However, MDG does not own Meteor anymore.
I think this topic is worth visiting again.
At this state, I wonder if it is possible to remove fiber in a backward compatible way given the large packages ecosystem Meteor has and the amount of code that has been written on top of it. It is the legacy of Meteor embracing coroutines and async/await style before JS ecosystem finally adopted it.
I like to be pragmatic rather than idealistic, so I really question the value of removing it, is it really worth the effort? or should that effort be directed to other Meteor potential growth areas? in fact, in some regards Fibers seems superior to async/await. Thus alternatively, the Meteor community can look into maintaining the fiber code base instead of removing it.
Either way, I think the consensus here is that something has to be done.
removing fiber IS a breaking change for every application, in particular if you are using pub-sub with meteor collections.
Fibers was primarly used to make this isomorphic:
MyCollection.find(selector).fetch()
this returns the results synchronous on both client and server (there is no await). On client its done by Tracker running the surrounding function whenever the data change and on the server its done with fibers.
Removing fibers would require to use await here and/or to give up isomorphic code.
This is a very challenging problem. maintaining fiber code is probably the easier way out. And deprecating the whole meteor.Collections data layer and replace with something new…
On the other hand this could have high potential for Meteor to evolve into a new lifeform aka 2.0 and regain it’s traction in the overall JS community.
That is my thinking.
I hope you are not proposing that, can you clarify this statement?
It might, but honestly, I don’t think so. I don’t think Fibers is holding Meteor back, we can still use async/await and Fibers, and frankly the larger community doesn’t know about Fibers in fact they don’t even know what is happening with Meteor in its entirety. I’d put my money on HMR, tree-shaking, NPM meteor client library, scaling, etc. And most importantly better documentation, marketing, stability and long-term support.
I think that there is a good chance Meteor 2.0 might be on Deno, that is to say, porting Meteor’s style of development and experience to Deno land. There is a reason why Ryan (author of Node) created Deno from scratch, at this stage of Node maturity, it is almost impossible, and would could argue to even desirable, to fundamentally change Node (adding sandboxing or removing package.json, changing the APIs, etc.) without breaking the entire ecosystem, so people are fine living with Node legacy and accepting the tradeoffs, I think the same can be said about Fibers and todays Meteor.
meteor is kindof stuck in DDP+pub/sub+Meteor.Collections. kadira voted for a new datalayer end left the community because meteor could not move forward. mdg itself adapted graphql with apollo but could not make it the default for meteor. The community itself got splitted. Some want to keep the things the way there are and that is ok. But the world keeps spinning and so does the ecosystem. Deprecation of fibers is another nail in the coffin for the classic meteor datalayer.
So either:
When thinking about it, its probably doable as it only affects server code. The problem is, that much code is shared between server and client.
Well, I don’t see it that way, you can use GraphQl today with in Meteor environment, and a lot of folks migrated to this data layer already.
But I personally I like the simplicity of websockets, DDP and meteor methods. Not every app will scale to be facebook and require their API flexibility and scale, most apps will run just fine with web sockets/DDP.
This classical Meteor deprecation and changing it completely has been debated to death on this forum. I personally like it the way it is today plus some improvements. And frankly I believe any major refactoring and breaking change won’t happen, it is just not feasible at this stage, it takes tons of investment and there is tons of code/products/businesses built on top of the existing system already. Like I said, we’ve to be pragmatic and opinionated and not try to morph Meteor to something that is not.
I think we should keep the discussion focused on what to do with Fibers in the short-term.
The culprit is exactly that. meteor is stuck like node.
But a new “meteor 2.0” would neither be compatible with meteor and would probably have very little to do with it (and would require funding, etc.). Personally i also think there are enough alternatives, but the simplicity of meteor is still unmatched and i would love to see a spiritual successor.
Yup, that sums up my thinking, another way of stating my pragmatic argument.
I like that spirit, I’m open to trying to get Meteor spiritual successor on Deno and I’m willing to collaborate with anyone who is onboard with that vision. But yeah I think the NodeJS ecosystem is maturing, stabilizing and getting saturated already.
And I personally won’t choose anything other than Meteor on Node. It is battle-tested, has very well understood behaviour, has tons of packages and it glues a lot of stuff together nicely while maintaining backward compatibility. I evaluated every NodeJS framework out there and it is either DIY webpack, express, graphql, passport and 50+ other packages, or some legacy MVC framework, or let us outsource/lock-in our entire server (aka serverless), or new shiny framework that wraps express, graphql, passport and the 50+ other packages but hey we now have Typescript as well.
Frankly, I think the entire NodeJS/NPM/JS ecosystem is a cluster mess (to put it politely) that needs refactoring and it is getting constantly patched, it came along way over the last decade, ES6 is just a Javascript language patch, Meteor managed to abstract a lot of that churn thankfully, and there are good/valid reasons for Deno creation.
[quote=“alawi, post:12, topic:53539”] Like I said, we’ve to be pragmatic and opinionated and not try to morph Meteor to something that its not.
I think we should keep the discussion focused on what to do with Fibers in the short-term.
[/quote]
well, then there is only the way of maintaining fibers or as mentioned above find patterns that would not work with fibers, identifiying them and warn.
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: https://github.com/meteor/promise
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:
cursor.fetch, HTTP.get, or Meteor.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?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.
Although this statement from Fibers github repo is worrying and is true:
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.
Just read that sorry,
Yeah, after reading this statement I’m getting on the fence as well, I guess @macrozone has a strong point then. I mean if the author is claiming that it might get too complex to maintain that integration/library, then the long-term plan should be considered carefully.
Perhaps phasing out Fibers gradually needs a serious thought and long-term planning.
It looks like Fibers currently supports Node 14 which will be supported until 2023-04-30, around 2 years and 9 months from now (assuming no minor patch will break Fibers).
NodeJS v15 (2020-10-21) might give us a hint on how Fiber might behave in v16 which if it turns out to be compatible with Fibers might extend the usage by another 2.5 years. Perhaps it might also help if the Meteor core team can get in touch with library author to see if he can elaborate on his statement and check if he has any visibility on near-term potential challenges. Lots of credits and respect to the author for building and maintaining this library thus far.
After thinking more about it, and reading the author’s statement, I came to agree with rjdavid, zodern, macrozon and dr.dimitru I think it is worth considering the longer-term phasing out of the dependency on Fibers to ensure Meteor can stay up to date with the latest Node for the foreseeable future.
And as jkuester suggested that refactor might indeed be on a Meteor 2.0 branch, it might also be an opportunity to modernize the entire code base to ES6, move some stuff to NPM and add types where needed, this work can be done gradually and gracefully if planned long-term correctly, it is important by not urgent task. Furthermore, by starting this effort on the right direction (i.e Meteor 2.0 branch), the meteor team/community will surely give a very strong social signal on their intention to keep Meteor around for a very very long time. And I hope benjamn has to some interest in this task, as I’m sure he gave this effort a lot of thought, at least he can be consulted on it.
Every challenge brings new opportunities for growth and I think there is enough smart/skilled people around this system with strong incentives to pull this refactor off elegantly.
What about this: https://github.com/chris-visser/ddp/tree/master/packages/client by @cloudspider
