As most of you already might know, Deno is a new JavaScript server, built by the original Node.js developer Ryan Dahl. Version 1.0 will be released very soon, release candidate 3 is already released: https://github.com/denoland/deno/blob/master/Releases.md
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.
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.
Out of all the other hyped Javascript frameworks, I think this is something, for the Meteor community, that is worth looking into. There is some serious brains and potential behind it and I believe the Meteor community is very well experienced and positioned to pioneer the future of web development experience once again.
Perhaps we can call it PlutoJS since it’s still a bit far and small .
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 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.
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.
.