Exactly that. I am really surprised by the amount of comments with this huge sentiment and doom mongering. These days it’s really not a big deal. Million lines of deno based ts is not a problem because pretty much any functionality provided to deno is available for node as well. You probably can migrate off much of the external deps without much hassle. You can even migrate to different language ecosystem altogether like others have mentioned in comments.

It's one of those things that the technical aspect is simple but the paperwork dehumanizes me. Just a couple more bullshit engineering design documents to generate

what other runtime has runtime security features?

Node only has experimental permissions support (making it not as good for local scripts), and no WebGPU (though you can import dawn wrapper). Deno desktop is way ahead of anything available for Node.

Exactly. Probably an hour if you just tell your model of choice to do it for you and implement a logical testing framework.

And this is why deno is exiting.

There's no business here anymore.

As long as the competition forced Node to become better then it's all good.

What did it get you?

For my projects, I am used to maintaining package manager configuration, bundlers, linters etc.

So I never had much interest in looking into benefits of Deno or bun.

Yup, Bun is at the mercy of Anthropic, and we know the extents they go to protect their competitive advantage.

Bun always seemed weird because they decided to build it with Zig. I want Zig to succeed, but it's not stable yet.

It reminds me of game engines. If you want to make a game engine, there's nothing wrong with that, but you should acknowledge that you're building a game engine, not a game--or rather, if your goal is to make a game, starting by making a game engine probably isn't optimal.

It's the same for Bun. It's clear that they wanted to build a JavaScript runtime, and also they wanted to use Zig. They are doing both of these things, but when push comes to shove, their desire to use Zig was more important than their desire to make a JavaScript runtime, I believe.

I lead a project built on Deno; it was not my call, just to be clear. Deno turned out unfortunately to be a miss and we had seen the writing on the wall. FWIW, we're moving to a much bigger Rust core program with node for JS user extensibility. (In other words, I'm not willing to risk using the deno_core crates.)

The one silver lining here is that Deno had already increased their node/npm compatibility. Migrating off of the jsr ecosystem and back to npm is going to be less painful than one might imagine. I expect present LLMs to be sufficiently good at the task, for example.

Do these runtimes have some value today? Sort of. But the cost of reimplementing them goes down, down, down. I made two bespoke JS runtimes within a year. Next year it will be even easier.

Deno/Bun see the picture better than I do, and they decided it was the right time for an acquihire.

Indeed, seems like it should be pretty straightforward.

I understand why the venture-backed entity couldn't do this, but given the reactions here, could a new maintainer not take over and simply charge for support and future enterprise features like the Sidekiq guy?

Maybe but only if that gives them a competitive advantage.

It probably depends on how much of the deno-specific api is being used, and then how similar that is to whatever you're going to switch to.

https://docs.deno.com/api/deno/

The way i see it, cloudflare acquired celld. Deno was just given a decent burial as part of the package

> I was really surprised that cloudflare was acquiring deno to be honest

It's an acquihire. They hired the people behind Deno

For me Deno has a really nice security posture, the permissions model is just something I haven't seen in from other runtimes (JS or otherwise). There were other nice features (native typescript support, compilation to a standalone binary), but the permissions model was just unique.

https://docs.deno.com/runtime/fundamentals/security/

Like a decade ago I got into a huge fight with a Staff Eng at our company over Dart. I had just been put in charge of the company's architecture and one of the first things I did was migrate everything to TypeScript (which was relatively new at the time). He was so angry I didn't pick Dart. Good choice by me in retrospect (though picking Angular 2 over React not so much).

well Deno was the only player who could have prevented recent npm security disasters:

built-in permission system for filesystems and etc

just forbid writing to important folders like ~/.ssh

But it is Open Source, so if said companies like Deno enough, all they have to do is pay for its continued maintenance and development. This is one major thing that sets Open Source apart from proprietary software.

> Do they also do their front-end in Dart?

Hey, you jest, but Flutter has a lot of traction!

(I conceptually like Flutter, but I can't get over the Dart thing, so I'm not part of that traction.)

Slack? I think some of their plugins API was all Deno based for a while.

> Do they also do their front-end in Dart?

This is actually a good decision though.

> Companies went all-in in a barely established niche player with 1/100 the traction, instead of sticking with Node, and even better an LTS Node, and are now surprised?

Wait till you hear about this thing called Bun.

Though with a tiny core team and almost carte blanche AI credits, they are a lot leaner.