Today, we’re thrilled to announce Deno 2, which includes:
- Backwards compatibility with Node.js and npm, allowing you to run existing Node applications seamlessly
- Native support for package.json and node_modules
- Package management with new deno install, deno add, and deno remove commands
- A stabilized standard library
- Support for private npm registries
- Workspaces and monorepo support
- Long Term Support (LTS) releases
- JSR: a modern registry for sharing JavaScript libraries across runtimes
5 Likes
I have not tried it with a meteor app yet. However, the backward compatibility with Node piqued my interest.
1 Like
Supposedly, the biggest gain will be performance vs node. Then there is typescript (but it depends on which side of the fence you are on). Other native modern features include promises, fetch, modern js, etc.
Cons - the normal candidates: community, ecosystem, and tooling (which is normal for a younger project trying to compete with the old guard).
2 Likes
I was about to post about this on the official discord. It’s definitely interesting as to how such runtime could help us out and the importance of making Meteor truly agnostic. But it’s best to wait things out and see who wins in the long run.
importance of making Meteor truly agnostic
Is it possible to use some Meteor or https://atmospherejs.com like Meteor Accounts package with Express or Deno? Without using full Meteor? Or does it require somehow converting it to npm package?
Is it possible to use Meteor Accounts package without MongoDB ?
I agree. It will take some time to know this, but if Deno wins this battle, the node backward compatibility might have been the one that accelerates this.
I also just realized that I do not know a lot about node 
looking at the compatibility features:
https://docs.deno.com/runtime/reference/node_apis/
To me it seems the primary benefit of Deno over Node might be their focus on simplicity. At some point it might be worth a deeper look if Meteor might benefit from moving from Node to Deno. But for now let’s just be happy that there are actual competitors in that field.
I don’t think it’s possible; there are many interdependent parts in there, possibly even Meteor context, which requires ALS/Async Hooks, and it is not implemented in Deno yet
1 Like
@leonardoventurini, I believe that you posted previously some performance-related topic related to AsyncLocalStorage. Is that about moving away from async-hooks towards AsyncLocalStorage? Or just lowering the use of AsyncLocalStorage in general?
Right now, ALS uses Async Hooks behind the scenes, which is inefficient, just having it enabled once, adds overhead to async execution in the entire application. Node.js 22 adds a new strategy for ALS called Async Context Framing, which should be more performance, however is still experimental. We are upgrading Meteor to Node 22 as we speak and will run more tests in the following days.
However there is still an overhead, and we need to be careful not to use ALS in very high frequency code, and things like that. Just be mindful of where we use it.
2 Likes