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.

this

we nodejs devs were just ignorant/lazy

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

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

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

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.

Deno's goal was to address Node's design weaknesses, while Bun came out with the promise of faster performance. Especially if you're coming from Node or migrating an existing project, it's easier to justify switching to Bun than to Deno.

Since then, all three runtimes have been gradually converging (adopting Web APIs, first class TypeScript support), so there's little reason to move away from Node's vast ecosystem to Deno; most npm packages weren't made with Deno's security model in mind.

Deno's biggest strength is when you want its security model and don't plan on using npm packages, e.g. if you want to let agents write and run quick scripts on your machine without awaiting your permission.

Mainly DX.

Deno has many of those things now, but my past experience wasn’t good. The first versions of Deno had a lot of friction; Bun however was more or less useful from day 1.

Bun simplified the pain with the ecosystem switch to esm. deno, at the time, made it worse by doing stuff with url based packages that didn’t fully catch on

Deno originally was not Node compatible at all, and required you to do everything in a Deno way:

- Deno plugin in editor, otherwise types dont work

- All imports via absolute URL, like Golang

- No backwards compatibility, so no existing code worked.

Since Deno 2, they've taken Node compatibility much more seriously, hence the 50% to 70% compatibility jump claimed here.

Bun on the other hand, tried to make things Just Work without requiring any thinking for Nodejs / TypeScript developers. It's basically the `node` development experience with all incidental frictions removed (but some segfaults added).

tl;dr: you can use `bun` to write node projects, but `deno` can only be used for deno projects

well benchmarks that's why

if the numbers look good, I pick it up -- though whether the numbers actually hold in reality is... well something I should check... but won't due to laziness...

I should check actual perf numbers... well next week or month?

Insanely better, at 76% Node compliance in Deno 2.8.

Bun 1.3.14 is at just 40.6% with same compliance test.

https://node-test-viewer.deno.dev/

I guess Bun had the better marketing then. I liked how every new feature came with a benchmark against the previous version and node. See this for example: https://xcancel.com/bunjavascript/status/2048228152397459590

I'd love to see a site comparing the 3 of them in a similar way.

One issue was that all dependencies had to be pinned to exact versions. If some sub-dependency of yours got a bugfix in a minor or patch update, your project only gets that update once the dependency updates to bump its dependencies and then you update that dependency. (Pinning exact versions of everything has its place but that place generally should be in your own project's lockfile.)

Also, if multiple dependencies of yours share a sub-dependency, then unless they pick the exact same patch version then you're almost always going to have multiple versions of common sub-dependencies loaded. (It's great that multiple versions of a dependency can be loaded at once because it lets you avoid the classic "dependency hell" issue, but having multiple versions of nearly all of your common sub-dependencies gets wasteful at some point. Generally there's rarely a good reason to have multiple versions of the same dependency that only differ in patch or minor version.)

(Deno's current support for NPM and JSR avoids these issues.)

I don’t consider them a problem at all. It’s how browsers have worked for a long time.

My point was at the time when deno came out it was completely different to node with its imports and that meant a lot of existing packages just didn’t work out of the box. That just slowed its traction.

Personally I would have like deno it stick with url imports and not added the npm support.

Ryan set out to “fix” his mistakes with node only to fully embrace them again.

Annoying to update instead of a package.json, which they now have an equivalent of, realizing their mistake.

I'm not suggesting it is a conscious decision point. Node has since done a lot to catch up on "less configuration" but Bun still seems to be growing even as what Bun does well Node starts to emulate. Runtime performance is mentioned in this thread here and elsewhere and while some are attributing that to Zig I think some are overlooking the different runtime experience of JavaScriptCore. It's also the "only" runtime difference between Deno and Bun if you assume that Rust and Zig are similarly performant native layers for some saying they like Bun's runtime performance better than Deno's.

one more reason I would have preferred a world in which lua was used in js's place

That's a yes and no. Venture funded companies like Anthropic have a history of low follow through with peripheral projects (like Bun is for them). Of course they do - their responsibility is ultimately primarily to their investors - not to Bun. So the risk now is that Anthropic will can Bun whenever they just lose interest or feel it's just a drain that's not contributing directly to their bottom line.

Node.js itself did have trouble finding a corporate home that was interested in providing good support for the project, and that's how we got the oi.js fork of Node, which luckily led to Node being transitioned to a foundation and the projects merged. This whole history is what made me so surprised that Ryan of all people would attempt another js runtime (Deno) project as a corporate project.

And it's the reason I'm staying away from both Bun and Node. I can't afford platform risk like this. I need my startup to be built on a project that has a more reliable future trajectory, which is what you get with a proper open source project (emphasis on project) that you get with Node. Node is stable and still getting features, but most importantly it's not going away.

Only if you think Anthropic is a sustainable business per se which remains to be seen.

It really doesn't. You think Anthropic will still be in business in 10 years? If they are, it's not likely they'll be in the same shape.

Running out of money is never the issue with a big company buying an open source project. There are countless examples of projects dying or changing significantly for the worse after acquisition.

Also “no human wrote any of this code” is not my personal benchmark for a reliable dependency.

> It means they're a whole lot less likely to run out of money, which makes them a safer bet as a dependency.

I don't think this logically follows. That is, yes being acquired makes one less likely to run out of money, but doesn't necessarily make something safer as a dependency.

Plenty of open source projects have little to no funding and continue on for years with no problems. But being acquired suddenly creates a requirement of return-on-investment. A corporation will happily shut the whole thing down if and when it's decided that they're just not gaining enough value from it.

(There's also the general fact that, a corporate-acquired project is going to first and forement serve the needs of the corporation vs. the community at large - if your use case or edge case doesn't align with the needs of Anthropic then you should probably not hold your breath waiting for the Bun project to address it.)

> safer bet as a dependency.

The recent 1 million line vibe coded PR suggests it is not so reliable as a dependency.

Yes, famously, acquisitions only make services more reliable, as in the case of Microsoft and Github, or Apple and DarkSky.

running out of money, for an open source project of almost any kind, is safer than "running into money" with the wrong strings attached

(still reserving judgement on Bun, though — I mean, we'll soon see, one way or the other!)

Afaik there is no proof Anthropic is profitable. This, and uv buyout by OpenAI only adds a risk to supply chains. In few years these companies can be overrun by open source models or startups delivering new hardware/software breakthrough in LLM. It is not like uv and bun are acquired by IBMs or Alphabets of today.

> which makes them a safer bet as a dependency

Wouldn't node be the safest bet as a dependency?

For those who care about their dependencies being "safe bets", Bun should already be out of the question after the recent "vibe code the entire thing into a different language in a week with zero human intervention" fiasco.

I agree that frameworks are abundant but there are not that many JS engine alternatives.

Interesting, I'm not aware of that many nodejs alternatives...

B2B, ~10k active users/month.

Interpreted that's right, in fact it's super slow and adding types adds up to parsing time. Javascript is jitted. Python types serves no purpose if not for documenting or letting the lsp doing some lightweight type checking. And btw typescript introduced many breaking changes and the spec is managed by microsoft something you don't want for the open web. What we would really benefinit from would be having WASM being able to do more inside the browser, like rendering, managing user input, accessibility, dom manipulation. Then u could compile your favorite static types lang down to wasm. Hell even a strictier version of TS could be made to do that, iirc there's something similar called assembly script

Python containing type hints doesn't get transpiled the way typescript does. The transpiling rewrites the TS to varying degrees depending on the target and the extra TS features being used.

Python "just" (that word is doing a lot of work) updated the interpreter to ignore the type hints. It still runs the same way as code without hints.

There's a bit more going on with TS that you couldn't just have the runtime ignore the types.

Typescript is only a linter, except for types annotations it is regular JS, quite different from C with Classes.

If you are going to mention enum and namespaces, the team considers them a design error, and only keeps them around due to backwards compatibility.

It doesn't make any sense tho. Typescript is nothing much to do with runtime. It's a build/dev concern. To get JS from TS you're mostly removing the type annotations.

Theres no reason to ship TS to an end user browser.

True but t only became the "default" choice a couple of years ago.

Before eg 2020 it still wasn't clear if TS was another CoffeeScript.

Typescript certainly hasn't been resting on its laurels.

Typescript has always worked pretty well in the browser. You can use the full Typescript LSP in vscode.dev or github.dev just fine.

I've even seen websites ship the Typescript compiler as a part of their bundle. It's not the most efficient use of bandwidth, but especially for corporate internal sites if it increases velocity it might not be a bad trade-off. Though it made more sense in the AMD and SystemJS days than in the ESM.

Typescript also support JSDoc mode very well where you have all your types in comments instead of inline. JSDoc type checked files run just fine in the browser without transpilation.

Typescript has also invested a lot into "Isolated Modules" and "Verbatim Module Syntax" and linting for such. This tooling makes it easier to keep modules cleanly type strippable without needing to run the full compiler. (This is something that Node support for Typescript requires, for example.) "Isolated Modules" also get code ready for the Type Annotations support if that gets to the next stage with TC-39. It also makes it possible to bundle a small, fast type stripper in the browser as a module loading plugin, should ESM get module loading plugins ahead of Type Annotations support. (There are proposals for that in front of TC-39 as well.)

Oh, for sure. But I'm old enough to remember when standard IT tools would have never supported Node in the first place and the idea of JS on the server made everyone scream. You just need to build demand for that support.

"standard" IT tools?