[vmg12]

Deno and Bun had very different focuses when they launched. Deno was trying to fix a lot of what Ryan (the original creator of Node) thought was wrong with Node. Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning.

A lot of dependencies and frameworks simply did not work with Deno for a long time. In the beginning it didn't even have the ability to install dependencies from npm. (In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things).

So Bun was a better Node with a lot of very nice quality of life features that just worked and it required much less configuration.

I think the Deno team kind of realized they needed to have compatibility with Node to succeed and that has been their focus for the past couple years.

Edit: And Deno is now more compatible with node than bun.

[gslepak]

> In hindsight with all the npm supply chain attacks Ryan was probably right about all of these things

"Probably"? Are you saying there's a chance he wasn't right?

I really think Ryan deserves a lot more credit than a "probably". He put in a lot of effort to do the right thing and improve the security of the entire ecosystem he created.

[MrJohz]

I think the biggest issue with Deno is that it fixes real issues but in the wrong way.

Take the sandboxing stuff. In theory, you have always been able to sandbox your applications. There are so many tools that let you limit what domains an application can access or restrict access to the file system. This doesn't need to be handled at the language/runtime level. It's just that people were lazy before, and they will continue to be lazy afterwards by running Deno applications with fewer than the minimum set of restrictions because that's easier.

The more complete way of solving the problem would have been capabilities. Rather than sandboxing the whole application, you instead sandbox each individual function. By default a function can make no requests, access no files, execute nothing, etc. But while the application is running, you can pass individual functions a token that grants them limited access to the filesystem, say. This means that trusted code is free to do what is necessary, but untrusted code can be very severely limited. It also significantly reduces what dependencies can do: if you're using something like `lodash` which provides random utilities for iterating over object keys and the like, and suddenly it starts asking for access to the web, then clearly something is wrong, and the runtime can essentially make that impossible.

It's also great for things like build scripts, which are a common attack vector right now. If your runtime enforces that the build script only has access to the files in the project folder, and can't access arbitrary files or run arbitrary commands, then you're in a much safer position than if your build script can do basically anything.

This concept has been explored before, but JavaScript is basically ready-made for it. The language already has everything you need — a runtime that also acts as a sandbox, unforgeable tokens (e.g. `Symbol` or `#private` variables), etc — and you can design an API that makes it easy to use capabilities in a way that enforces the principle of least privilege. The biggest problem is that there's basically no way to make it backwards compatible with almost anything that works with Node, because you'd need to design all the APIs from scratch. But one of the great things about Deno at the start was that they did try and build all of the APIs from scratch, and think about new ways of doing things.

[lenkite]

Are there languages and runtimes which have done stuff at this low-level before ? Sandboxing at the individual function level ?

[nesarkvechnep]

There's Capsicum on FreeBSD.

[mcdonje]

seL4 is an operating system that uses capabilities

[stephbook]

Use a .devcontainer and you're done in 10 seconds without any new runtime implementations.

[oblio]

I'm not sure how this solves lodash wanting network access.

[sysguest]

this

we nodejs devs were just ignorant/lazy

npmjs should mark libs "deno compatible" and move over to deno gradually for security

[VerifiedReports]

I started a new project with Deno specifically to avoid the NPM mess, and because it was created by Node's creator to fix its shortcomings. I'm new to Web development, but so far the experience has been pretty good.

Nice to see Deno being maintained. The features listed seem pretty substantial.

[tuananh]

> Bun focused on compatibility with Node and the ability to run popular frameworks like Nextjs from the beginning.

and yet Bun's npm compat is much much lower than deno

https://x.com/rough__sea/status/2057579066744881188

[vmg12]

I was talking about the history and not the current state of the projects if that was not obvious.

[nailer]

(thinking emoji) they could merge.

Seriously, they're both Rust now. They share goals.

[tomjakubowski]

I doubt it would work out. The engineering cultures could not be any different.

[sellmesoap]

I think different cultures can contribute to eachother, they don't have to hold hands. I'm sure open minded curious developers can look over the fence and appreciate the differences and adopt practical aspects of each other, maybe the time to stop and smell the roses is to poetic and altruistic. It's a JavaScript server/packager/framework drag race for pink slips!

[sysguest]

well bun could 'gradually become deno':

1. add 'enhanced security mode' that's actually 'deno-compatible/like' (permissions, etc)

2. mark libs/executables/etc as 'enhanced security compatible'

3. ...merge by buying out deno?

[andrewflnr]

> The engineering cultures could not be any different.

A Bun team willing and able to execute your plan is not one willing to merge a vibe-coded rewrite in a couple weeks.

[notnullorvoid]

They may share some goals, but also have differing and opposing goals.

But it's possible that all 3 Deno, Node, and Bun could share some code in the future considering they now all require Rust as part of their build process.