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
I’m a big fan of this library direction.
I personally think that’s the right architecture/path forward, and this is how I’m developing some of my Meteor apps, decoupling client from sever and offloading the caching and updates to each view layer framework. In the case of React for example, there is useQuery and SWR doing very close to what tracker/minimongo are doing.
This could potentially evolve to be the Meteor 2.0 client data layer, a thin client downloadable from NPM and pluggable to any front-end framework or client.
Its good to note that its pretty much a work in prigress package. I’m fully committed to it though. 
If there is an agreement on this direction I think many will step in to help building it.
My take on building survivable open source projects is the same on my viewpoint for larger projects.
Fibers is not a problem, Minimongo is not a problem, DDP is not a problem. In fact, they are great. What makes them less great is that they can’t go without each-other in the current setup. All of these packages are tightly coupled. Removing one will destroy the other.
We need to start focusing on decoupling features, have the individual packages be cross-compatible with the entire ecosystem and leverage Meteor’s build tool with smart packages to create drop-in features for Meteor.
I’ve started the DDP package for that reason. To have something that allows me to optionally connect with other very popular framework and have the best of both Meteor and for example Nuxt and Next.
This is what makes Vue so great. It has been rewritten in the background without actually changing a lot to its high level facade.
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
The former maintainers of mdg worked full time on that, they got paid for that. It was their business. Tiny now took over this business.
The point of tiny acquiring meteor was to keep it alive for current users, to maintain galaxy, give support. I don’t think that they have the intention to do something new. A non-backwards compatible version 2 won’t be accepted by the community, not without a clear migration plan.
The only way out is to slowly reduce the usage of fibers. First in the core and core packages, afterwards i user-space, which is quite hard as explained above. It is not possible to remove fibers (co-routines) without breaking changes for everyone. So there is a long way until a breaking meteor 2.
Its probably easier to either just maintain fibers (its anyway unclear whether it will break at all) or to deprecated the whole pub/sub/collections data-layer (which has other flaws than fibers in my opinion).
To their credit, Tiny and the new Meteor team are way more communicative and in touch with the community than MDG so I don’t think we need to speculate too much on their position and direction.
I agree and understand, that is why it is Meteor 2.0 it will be breaking change but given the author warning, I think it make sense to invest in that direction slowly, again it is not urgent but desirable direction. And frankly Meteor has been on this path for several years now (since they open up the view layers), although I do see a path technically of migrating existing classical Meteor apps, and I think it can be done gracefully, also put this in perspective, this discussion is long-term planning and due diligence, not to cause any additional FUD for newcomers etc.
@macrozone what is your position/recommendation on this? it is not clear to me, there are really two choices here as far as I can see (feel free to suggest others):
Meteor team (and whoever else happen to use Fibers) invest in maintaining Fibers after Node14, despite the authors warning and hope for good, while slowly minimizing the dependency on Fibers in case it broke and revisit this discussion again when it does break and Meteor needs catch up to latest Node, that is the pragmatic approach, and I think it is ok. I’ve a feeling that this library won’t break in any major way, but the author warning is concerning, that is why I suggested that the Meteor team reach out to him try to get more info.
Start the migration effort soon on a breaking Meteor 2.0 branch and use this an opportunity to modernize other aspect of the stack well
I think anyone who has been using open source (and specailly node/npm) for some time has been in similar situation. Again I see this as opportunity now and that is why I switched my view from maintaining to migrating, but I’m keen to see what others think.
i wouldn’t start a meteor 2.0 branch. With typical semantic versioning, you would increase this number on a breaking change and its not the time for a breaking change.
i would only maintain fiber if and when it won’t work for any future node version.
instead someone should go to the whiteboard and sketch out how a fiber less pub/sub could work (giving up isomorphic code? working with promise in a smart way?) and provide a new api that does not rely on fiber without removing the old way of doing things, but try to deprecated it (and warn).
Personally i have only one bigger project that uses pub/sub anymore and tend to migrate to graphql in that project (if i need to migrate at all). I would advice to at least consider switching to another (existing) datalayer as an option.
Hence why I started a DDP library. Its client only at first, but maybe I should aim to build a server version as well. A bit like how the Apollo Server and Apollo Client work together
I believe when most of us mention MDG we mean whoever currently responsible for codebase and its open source roadmap. While it’s community-powered and open for contributions, it isn’t open for merging by contributors.
Oh, for sure. I said that in case you meant you were contacting the actual previous owner of Meteor (they are still MDG, afaik). I see the new owner, Tiny, mentioned all the time since the acquisition.
I genuinely thought you didn’t know.
just want to make sure we are on the same page, and we are
