📢 Big changes ahead for Deno

It'd be useful if Deno released a comprehensive benchmark suite, otherwise it's difficult to compare runtimes, like Deno may measure one thing and Bun may measure another thing, if the measurements aren't about the same thing they are a bit meaningless.

We’re working on this.

Awesome! That could be huge for improving performance across the ecosystem.

Why is Deno slower than Node?

If you find that its slower in your benchmarks, open an issue... we'll get it fixed

That's nice to hear, hypothetically that may not always be possible, like V8 doesn't have proper tail call optimization for example, realistically how can Deno optimize that if V8 doesn't even want to ship this optimization? Most scenarios should be fixable though.

I guess Node doesn't have proper TCO either though, I guess I was thinking about other non-V8 runtimes.

True but most slowdowns are at the runtime/bindings level and not V8. ...and V8 usually accepts performance improvements, like this patch that adds Uint8Array support in Fast calls chromium-review.googlesource.com/c/v8/v8/+/3767…... it had direct impact on Deno FFI performance).

I personally don't see the huge benefit of TCO. There are isolated cases where it may make some sense, but it's not the magic performance pixie dust that some people make it out to be. It's more of runtime feature than a performance optimization IMO.

I agree with that, I guess I was just being annoyingly pedantic regarding: > Our goal is to make Deno the fastest JavaScript runtime - full stop. Like that's just not possible under every scenario. Being faster on average is much more interesting though, sure.

Small note, but not calling out Bun by name in the article feels a bit petulant...

starting war between runtimes😆😆

You’ve still got the cutest mascot! Can’t wait to see what you come up with!

OooOooooo. Exciting! Would love to see Deno reach a performance parity with Bun.

Deno FTW!!!

Shadamn this is some competitive shit Hey Crockford maybe #javascript shouldn't be retired after all

Really interested to see how the integration with NPM packages go. Should make it a lot easier for large code bases to move to Deno.

I suspect that bun's performance compared to Deno may come from Deno optimizing for size instead of speed, but I haven't been able to build it myself yet to try it

Sounds exciting!

Really nice to see increased deno - node compatibility. I am a bit worried the huge influx of npm packages will kill the fledgling deno ecosystem though

If they can isolate pretty well the interoperability of both system, I think there will be no effect in deno develooment.

This is BIG! I finally see that this focus on speed and npm compatibility will convert most people as those were the most "meh" things about Deno

We at @StripeDev recently put in a bunch of work to make sure stripe-node works in non-Node environments. It was hard, but worth it. Very happy to see Deno making npm modules "just work" without requiring the effort we had to put into it.

"Competition is good for the ecosystem!" Indeed

patiently awaiting native Deno images for AWS Lambda with comparable cold start times to Node. it's the only thing preventing me from adopting Deno

Would be nice to see

Can't wait!

not gonna lie... I am not happy about adding greater support for node packages. Deno felt like a clean start without the dumpster fire... I wish you guys would reconsider

How viable would running on an older version be if you liked it pre update. Curious as i just started messing around with this stuff.

whatcha thinking? Soft fork/ Hard fork?

I've only ever heard that term used with blockchain haha kinda cthrew me off. But a soft fork would be ideal imo. 🤷🏼‍♂️

Threw* not cthrew. Jesus.

Many of us use node/JS both for backend & front-end. Eg write schemas, models and validations as an npm package and utilize it on both ends. It is an enormous productivity booster when you write this way vs doing it the traditional way,ie repeating same logic on front and back

Seems like you could do that without npm in Deno. You can just do module routes the deno way. Or use deno for one fullstack code base.

I build SPAs (PWA/offline capable). So running it in a browser is a must. Plus it must be compatible with TS in React/Vue/Angular without any acrobatics involved. Correct me if I am wrong but it is not possible at the moment unless you embrace wasm builds

In node I can spit out ESM compatible library easily and on the front-end side I can do all the tree-shaking. I just do not see how it is possible in Deno. I did look into it and the message was pretty clear - it is not for browsers period

Besides Deno does not stick with TS specs fully it seems ...

Feel like Node had its chance to make a clean break and force a spring cleaning of NPM by making ESM first-class, so ".js" and not ".mjs". ESM will never be serious on the Node platform.

The thing is this enables incremental migrations. You can move to native packages where they exist, but aren't cut off from *the rest of the ecosystem* if you need something

Besides, they've been building out the node compat module in stdlib for *a while*, so it shouldn't be shocking that this is coming

(Plus, stuff like Denoify can also benefit from this same piping)

The npm support is fantastic news. Thanks for making it happen.

Yet I prefer nodejs over deno, for a lot more reasons, though I'd love to see their future changes, and the npm ecosystem, especially.

Super exciting stuff! > “… will allow Deno to easily import npm packages and make 80-90% of npm packages …” Do we know what will differentiate the 10-20% of packages that won’t work?

Good question

Interesting, will deno.land/x packages allow NPM imports?

I was thinking in regard to moderation of modules on deno.land/x. Although, the handling of NPM package imports in remote modules would also be interesting.

How you guys will handle security issues that comes with npm packages?

I thought the whole point of Deno was that npm packages were "a mistake"? What's differentiating you now from Node? Other than the unsubstantiated claims of the "fastest web server"...

Not sure, maybe: Pretty better developer experience for newcomers to javscript/typescript ecosystem. Easy Rust ecosystem access, compared to hard C/C++ nodejs ecosystem access. Easy to newcomers to install, run, distribute and deploy code. WebAssembly? I don't know.

Just want support for @prisma

We have an open issue for this here, it would be great if you could leave 👍 on it to help us prioritize 🙂

this is amazing. Thank you all so much for this. :)

It kinda felt like Deno felt out of the "hype" about a year ago, I’m happy to see it’s being actively developed and maintained. Let’s go!

Reconsider my tech stack

Deno eats Bun... 🦕🥟

I think, being fastest should not be the goal. 90% of the so called apps will not require that much performace. Instead focus on dev velocity and rich ecosystem. Rest you are on absolutely right track! Keep rocking!

When the past Hunt your sleeping night:P

“Our goal is to make Deno the fastest JavaScript runtime” like, faster than Bun??

How do you deal with CJS packages and TS definitions?

Finally! This upcoming npm support is going to be huge, and change many developers minds. Supporting most npm packages might be challenging, e.g. many npm packages I’ve tried importing into bun have failed and needed an issue and a fix. I predict the same teething with deno.

Any plans to document package compatibility as the broader npm support ships? It'd be great to have a searchable db of what still doesn't run vs what runs under a compat layer vs what doesn't depend on node libs in the first place/is isomorphic

Please have a deno: and a github: prefix, i want to use deno as well but those import urls irk me