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.
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.
@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.
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).
@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 !
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.
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.
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!
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.
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.
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.
! I think