In the near future, I don’t see an impact on Meteor, as Node.js won’t disappear soon. It is a well maintained piece of software.
On the other hand, would it be worth to recreate a Meteor-like experience on the new platform? Is it worth to be one of the first, who adopt this technology, just as Meteor did about 8 years ago, when Node.js was version 0.7.4?
Honestly, I don’t know the answer (yet). But I think, it is worth to think about.
I agree with this idea. A new meteor with a new name 0.0.1 based on deno 1.0. But: is there any thing in the core code that should be changed only by rewriting from scratch with new ideas and new concepts?
I remember seeing the talk where Deno was originally announced. Like always it is a bit of a balancing act, fixing some issue and having some “questionable” choices.
As for Meteor adaptation to Deno… I don’t think that is possible in the near term given the complexity. Though it might be a fun exercise. At the end of the day though, to justify this (beyond academic curiosity) would be what would be the benefits to the end user and consumers of apps. If there would be some significant improvement then I think it would be worth it to go in so that we can get the early adopter advantage.
I think deno will have to grow first. There is currently nothing for developing client bundles, all is basically http server with SSR, I am even not sure if there is a templating engine or similar available. Correct me if this is outdated info.
Of course, it’s a young technology, but it will grow.
There are already some web frameworks available on https://deno.land/x/, which provide server-side templating. But this is not in the scope of Meteor, which generates an SPA.
deno bundle creates a JS bundle from the TS files, which should run in the browser (not tested by myself, but see https://github.com/denoland/deno/blob/master/docs/tools/bundler.md). Compiling and bundling will also be available from TS directly with
So, this could be used for the bundling part.
There’s already a Mongo driver available, based on rust’s official mongodb library package.
Websockets are also already implemented in Deno, so it should be able to do DDP between the client and server.
Something comparable to Next.js is already on the way: https://github.com/imaginamundo/deno-react-server (WIP) It already uses the
So, the main building bricks of Meteor (which I’m aware of) already exist in the Deno world.
Just tell me, if I’ve missed an important part.
I think it would be interesting to see a DDP server with authentication and MongoDB driver running on top of Deno, pub/sub can be implemented using a port of redis-oplog, and it can be deployed on Galaxy, Atmosphere can be used as well since NPM is not applicable to Deno. I think it’ll be a nice add-on to the Meteor ecosystem and a potential source of revenue as well.
Perhaps we can call it PlutoJS since it’s still a bit far and small .
Another aspect came to my mind. Meteor become famous for its isomorphism: You write code once for server and client.
Deno is based on the ECMAScript standard more then Node. Browser compatibility is one of the goals of the project.
In this aspect, Deno seems to be a natural fit for Meteor.
BTW: 1.0 was released yesterday: https://deno.land/v1 (Beautiful new homepage with manual, etc.)
I propose Tiny to hire Alawi at marketing / branding
I haven’t dived into Deno right now, so I’m not (yet)? really over-hyped, and am looking forward to a deeper VS comparaison with node before pronoucing myself, but I’m sure Meteor will benefit of discussing it when once Deno will be better known
I would say at that point it will be too late. This is really about first mover advantage.
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
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!
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.
@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
@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!
Here is an interesting article listing some of the well known patterns within the NodeJS ecosystem and how it can be implemented in Deno.
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.