I would say at that point it will be too late. This is really about first mover advantage.
2 Likes
I understand the “bet” it could be. But currently, there’s already quite a lot of things to do / fix / add to Meteor already. Migrating it to deno might :
- potentially makes Meteor loose some developpers if some have reasons to prefer Node (or would require 2 versions of it to be maintained)
- require a certain amount of work without being sure that Deno’s traction is going to be cost-effective at short / mid term
- potentially pay off a lot if Deno become widely used / prefered over Node, and quickly enough so that no potential new meteor developpers is lost in the process.
But well, Meteor made such a bet once, and it clearly paid off 
2 Likes
I don’t think it needs to be migrated, I think it is a parallel long-term R&D effort. We’ve flexible frontend layer and we could potentially as well have flexible backend.
I’ve no doubt that a backend framework will get developed on Deno (and someone will port DDP to it) and I agree with @storyteller it’ll be about first mover advantage. Therefore, might as well start that initiative from within the Meteor ecosystem.
I see Deno as a serious potential competitor to Node, which is a good thing, kind like NPM and Yarn. I’m doubtful it would be as popular anytime soon, nevertheless, it might be superior to Node on multiple fronts, and I think we’re talking about at least few years of R&D. It took Meteor 8 years to mature and 10 years for NodeJS to get a competition, most likely we’re looking at similar timelines. So yeah, it’s not another let us drop everything and refactor to today’s trendy JS framework, but more like a long-term parallel R&D to strengthen the Meteor ecosystem down the road.
With that said, I do understand and share @fen747 concerns. Needless to say, there is still a lot to work and improvements to be done within the Node/Meteor ecosystem. Apollo regretfully “stole” a lot of the brains and resources from Meteor, although personally, I think Meteor is far more impactful and interesting project than Apollo will ever be. I don’t think any of us here want to see this brain drain happens again, and I believe the current stack (Node/Meteor) will be the leading choice for years to come.
It is an interesting topic, happy discussion!
4 Likes
I’m likely missing a LOT here, but there are at least a couple things to consider if trying to swap out node.js for Deno:
- All the stuff others have said about the client side bundle - there doesn’t seem to be anything in Deno for that yet (luckily - Meteor has a bunch of stuff for that!)
- Meteor has a foundation on Connect.js - is there an effort to port connect.js to Deno?
- Meteor’s node.js async system is built on Futures (or Fibers? I can’t remember) - that would either need to be ported, or abandoned and replaced with Deno’s async system (which is a top selling point, from what I can tell). This would not be an insignificant amount of work.
I’ll also say that I’m not sure I’m a super big fan of Deno’s module system. I’ll need to see how that works in practice. I suspect there will be much iteration on that front.
4 Likes
@qnipp correct me if I am wrong but I don’t think the suggestion was to swap Node within the current codebase, but the possibility of creating “Meteor like experience” from scratch on Deno since all the main components are there.
I think the point of the thread is provoke some thoughts and discuss that possibility.
5 Likes
@alawi Yes, you’ve got the point.
I’m not thinking of replacing Node with Deno, but of making a modernized version of Meteor, which fixes some of the current pain points. I see it as a possibility to make a clear cut with obsolete concepts like Fibers (superseded by Promises and async/await) and Atmosphere packages (or maybe a rebirth of them in a new way, as I see some advantages of them over NPM). And it could be the step to convert the code base to TypeScript.
This could be the long awaited Meteor version 2.0 (and in this case not only for marketing purposes).
Meteor 2.0 a.k.a. PlutoJS 
6 Likes
@qnipp l totally agree with this approach and l do think it is the point. I even think there is only one way to analyze the meteor/deno question. That one !
1 Like
With all the man hours in the Meteor build system, the dynamic imports, the modern bundles - all that - why not consider swapping out node? There’s a lot I like about Meteor.
3 Likes
I think someone who has produced such a great project (nodejs), who questions what he himself has achieved, who takes two years to come up with a project where he takes into account the weaknesses and shortcomings of nodejs , deserves special attention. It’s like an athlete who puts his title back into play, when nothing forces him to do so, only for the sake of rigor and to do better. That said, I played a bit with Deno, I think the project will only be mature in a year or a year and a half. And for Meteor, maybe this is the right time to get interested.
3 Likes
I have not thought about it that way, I was thinking more of a greenfield/clean-cut approach.
But I think it is an interesting point, given that Meteor internals don’t use NPM (which is not compatible with Deno) it might be possible to share a subset of the Meteor code between Node and Deno. Parhaps that is the be the best outcome if it is technically feasible. It will decouple and improve a lot of the Meteor internals and convert it to Typescript reusing those many man hours and the battle tested logic. So instead of focusing on porting Meteor internals to NPM, it gets shared with Deno…interesting thought.
Imagine being able to decide the runtime (deno or node) from Meteor’s CLI when starting a Meteor project!
4 Likes
Here is an interesting article listing some of the well known patterns within the NodeJS ecosystem and how it can be implemented in Deno.
3 Likes
Deno comes with http functionality as node does and I think there will be very soon a middleware stack for http calls like connect or express for deno, if not already available. Maybe we as a community start some proof of concept work on some topics.
For the fibers being replaced by async/await I can’t commont on, since I not 100% know how it works internally.
There are of course much more things to consider, like the whole isobuild process and code splitting (as I already indirectly mentioned with the comment on the client bundling) dynamic imports, EJSON, DDP, Mongo (the Meteor-way-Mongo) etc. and I am still unsure how far they are depending on a more complex build system than deno currently provides.
Now to the positive: I think however, that this could be a huge chance to place Meteor on the top of a new era of web-development. Deno has capability-based security built into it’s core and typescript as system-wide language - two aspects that are often used by critics on the Javascript fullstack by foreign developers (you know… those who program with a “real” language) so I think it will grow into a serious platform sooner or later.
7 Likes
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.
3 Likes
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.
1 Like
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).
1 Like
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. :-/
2 Likes
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…
2 Likes