There might be tremendous value (as well as effort) in a rewrite from scratch of Meteor on top of Deno, but by the same team. The link is to an old but excellent article on the value of rewrites.
I think Google’s Fuchsia is in a similar place as Deno. A capability-based OS not encumbered by the deadweight of UNIX leftovers.
Haha, I was thinking the exact same thing, my conspiracy theory is that MDG folks are already building on Deno behind our backs 
! I think @benjamn and @glasser can do wonders with Deno.
This just seems like such a heavy lift. But if we broke the various parts in to projects, and then talked about rewriting individual projects, it becomes conceivable.
Honestly I wish Meteor’s parts were more well orchestrated in to individual projects (the way React Native and other projects are built on a collection of other projects). I’d probably tackle an effort like this first, then talk about a port of the necessary sub-projects to deno.
Another nice article about Deno, changing the mental model around codes import.
I really think Deno is into something here. I for one enjoys the simplicity ( I like simplicity in general) of URL based import over npm modules, it feels more “webby” and decentralized, also I think it fits really neatly with the Meteor mindset (which is largely about simplicity).
i also think Fibers is the thing that will prevent meteor from moving anywhere. Fibers was a smart choice for meteor back in the day where promises did not exist yet as a standard in js. It enabled to use meteor collections both in client and backend identically, altough they work very differently.
But Fibers makes meteor a “non-standard” runtime, which not only prevents it from other runtimes than node (e.g. deno), but also infers with many libraries, in particular with SSR.
The tricky part is that removing fibers would result in a major breaking change, it would break the whole usage of the classical reactive collections. :-/
Fiber gave Meteor a fast track to the future (avoiding callback hell) back in 2012, it got the job done at the expense of legacy code, I don’t see it as a big issue, although it would be nice to remove it and make it opt-in. Anyway, that is legacy, I have seen banks running on a 1960’s code, and nobody wants replace it, because it works and they have better problems to solve, software systems ain’t as fragile and malleable as the JS ecosystem likes it to be and it is expensive manual labour.
But anyway, I don’t think the goal would be to reuse Meteor, it doesn’t seem possible to share code either between Node/Deno as of today, since the import locations are different and not compatible.
I think the goal would be to recreate Meteor like experience in Deno, and to be clear neither Node nor Meteor will be replaced by Deno, there is so much man-hours put into Node/Meteor ecosystem that it would take years to replicate. There is an advantage to being firsr mover and innovate, you for sure will do mistsks since you have no example, but also you would reach the furthest and lead the way, assuming you don’t lose your way and do many major mistakes.
Rebuilding from scratch does sound like a TON of fun. I just wish I had the time…
I agree that Fibers being non-standard and odd to most people will hold Meteor back. It’s just one more barrier to entry that people need to understand. I think just about everyone hits that fibers error (you know the one) and has to google it.
But yeah, if there was something done in Deno it would probably be done from scratch
The question is if it should be a 1:1 port. That would hardly bei possible. They even disabled importing json as module, making the whole json fetching centered around either filsystem or http calls. The other thing is, that if the Meteor deno Framework is built top early then the same issued as with fibers will arise. Look all the fancy frameworks that are collecting millions in vc and they started not long time ago.
