Hacker News Reader

Comment by theodorejb | Hacker News Reader

> We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime. Deno will remain open source, and we welcome others who want to continue its development.

So unless someone else picks up development, Deno will no longer be supported.

View on HN

This is a wild detail to just bury at the bottom. So many companies went all-in on Deno in recent years. Some even did major migrations off Node.js. Sucks for them I guess, but that's always the risk in chasing the shiny new thing over sticking to the old and dependable.

I went all-in with bun. Did I bet wrong?

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

Use bun when it's drop in replacement of npm, never use Bun API itself.

"we know the extents they go to protect their competitive advantage"

I don't. What do you mean?

Like any other late stage capitalism corporation, curve must go up exponentially, otherwise shareholders will be depressed.

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.

As a former bun user, speed.

However I now work with software that requires PQC resistance and node's native ML-KEM and ML-DSA abilities made me switch back. Also I'm not particularly an Anthropic fan so that was also a separate nail in its coffin for me.

Now I'm fascinated why you've chosen the node/npm ecosystem for something with such high security requirements. Are you doing anything special to deeply pin dependencies, etc.?

Finding the right balance of "being responsive to bugfixes, some of which may patch disclosed zero-days" and "not allowing a compromised package to be installed" is tough, these days.

npm has supported min-release-age since Februrary, both that and pinned dependencies are stuff I think everyone should be doing. wrt sensitive environments, I can't say too much about our internal processes but we have an audited private registry among other things. for containers, Iron Bank provides a free and publicly accessible baseline https://p1.dso.mil/iron-bank to build on top of.

I thought iron bank got shutdown...Be cool if its still running! goes to look

edit: Sweet! seems to be all intact!! Thanks!!

I mean I used to do a lot of things I'm glad I don't have to anymore. I'm not a big fan of doing repetitive work just because I understand how to.

Node at least picked up --run, TS stripping support, .env loading, watch mode, and sqlite (plus some other things I'm probably forgetting) since Deno started so at least theres that.

I also don't like repetitive work, but I think it can be beneficial to understand how the tools you use work, and bun/Deno seem to abstract much of it away.

Random example: I've worked with many frontend developers who seemed to believe listing dependencies in package.json in devDependencies instead of 'dependencies' controls what ends up in the production bundle.

I'm under the impression few understand that this is only a cosmetic distinction unless you use the package manager's --omit=dev or --production flags during install.

What is included in the production bundle is of course determined by the bundler's dependency-graph reachability from the entry point.

For people who never configured these tools themselves, it's probably difficult to understand how the modern web stack works.

However, nowadays you can probably have AI explain it to you well enough while it fixes the issues.

Silly drive by take:

> I've worked with many frontend developers who seemed to believe listing dependencies in package.json in devDependencies instead of 'dependencies' controls what ends up in the production bundle.

If so many believe that it’s how it should work, maybe it just should work that way. Principle of least surprise and all that.

You can and probably should set up your production builds that way but it's not automatic.

It also gets messy if you're building 2 or 3 services simultaneously out of the same node_modules dir. E.g frontend, backend, shared, scripts...

How would you set that up?

Like say you installed only the production dependencies, then you'd be missing the build tools, bundler, etc.

One idea would be to use hooks of your bundler to enforce that each module resolved during the production build is declared in the regular dependencies.

It would be far from a standard solution though.

NX Monorepos work that way. Broadly speaking (and with many exceptions) all packages end up in the root. It “builds” release distributions with the correct package.json files and transpiled js.

It helps keep all your related packages on the same dependencies. It’s hell for react native sometimes though.

I don't see what you mean.

With nx you define the dependencies between your tasks, so that the packages build in the right order and with caching.

I do not think it changes anything about how packages are installed by the package manager or bundled by the bundler.

You can declare build tools in either the root package.json or packages/a/package.json, and I don't think anything prevents you from bundling something declared in devDependencies.

On second thought, I see now that you probably mean it helps keep shared dependencies at the same version when you declare them in the root package.json.

That's a feature of npm/pnpm/yarn workspaces though, not nx itself. And it only works with bundled dependencies, since they would be undeclared in the package itself and thus couldn't be installed externally. If you need that, I think pnpm catalogs would be the right tool.

https://github.com/import-js/eslint-plugin-import/blob/HEAD/...

It's not built in to ESLint, but it's fairly widely used in my experience and helps ensure that you've got a sensible split between production and non-production.

One should understand how their tools work but there's no such thing as doing that without understanding things across the abstractions involved and at least a good portion of what happens under them, Deno or not.

It works the same way you use a bundler instead of assembling your own and so on and so forth down the tree. The farther down the tree, the less focus you should give your understanding to, but that's not an excuse for giving no understanding below the first layer.

This is why I'm not overly concerned about AI taking our jobs. Those who do not RTFM* are doomed to rewrite it in blood, toil, tears, and sweat.

* Or, in the absence of well-written documentation, the source code, the decompiled object code, or at the very least inspect the end result.

On most projects you really only need one person to set it up one time with any deep level of understanding. Having each person on a project go deep into the weeds on how the package manager works is not very useful. That time would be better spend on almost anything else.

As a non-js developer, Bun compiles my ts code to local executables nicely. Allows me to experiment with the new diversity of ts frameworks and distribute the binaries (hobby scope).

I'm using Vercel PKG to compile my JS code to executables "nicely".

But PKG is not supported by anyone any more (?) and it has an upper limit on the version of Node.js base-image it will support.

If Bun supports compiling executables nicely I hope that feature somehow stays alive and is migrated to other runtimes. Or maybe it can become a standalone tool for exe-compiling?

That being the case, why not use a compiled language in first place?

One of my software engineering maxims is that popularity is a feature.

I don't mean that in a "social proof" kind of way. Popularity brings it own advantages. Because lots of people use something, you get the advantages of lots of other people using it:

a larger ecosystem, more libraries, easier to find new team mates, easier to find people willing to learn, better and more answers on Stack Overflow (or in LLMs now, I guess), etc., etc.

And there's just no compiled languages more used and known than JavaScript/TypeScript. Java and C# come closest, but they're still far off and still require runtimes.

JavaScript is partially compiled, given the limitations of using JIT compilers in dynamic languages, and Typescript is basically a linter.

All compiled languages require runtimes, the only difference is how big they are, and JavaScript runtimes are not among the smallest ones.

> compiled languages require runtimes

Hmmm, no ?

Then what was the point of asking why they used JS over "a compiled language"?

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.

Didn’t they switch to Rust?

Bun was converted fully into Rust overnight, works fine so far.

As of bun 1.4, it's all rewritten in rust instead of zig: https://bun.com/blog/bun-v1.4

I was really surprised that cloudflare was acquiring deno to be honest, I have written about this here before, Deno was always sort of dead to me due to how little they cared for compat of all kinds (nodejs, CJS, backwards). It was refreshing to see bun care a lot about it (well, now its on a different path in other ways).

Then I read that paragraph, and it made more sense that they're acquihiring + killing.

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

https://i.postimg.cc/d13vq3fk/x.png

And seems they want to compete with Anthropic, by having expertise on JS runtimes? A big feature I think is the ability to produce an executable application and have your AI agent-tools work well with that.

How will this affect those of us relying on those projects? It's not just those companies but also the customers of those companies.

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.

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.

Can you elaborate on why it was a “miss”?

A few things off the top of my head (we've been on deno since 2022)

- They originally bet on being a TypeScript dialect that didn't quite match the expectations of node in a few small places that ended up mattering hugely.

- One of the original value propositions was "deno compile" and "deno bundle", and those never actually worked well enough to be robust for our real-world use cases (early on they didn't support TLA, then dynamic imports didn't work, then they had issues with ARM compilation)

- Then they simultaneously tried to support node syntax out of the box with npm import specifiers _and_ create a new javascript registry (jsr.io)

- At the point where we expected them to actually make their base-level ecosystem robust, they pivoted to edge compute, and then the writing was on the wall

LLMs writing rust that no one reads will spell doom for all the server side JS stuff in time.

Hopefully, it should never had left the browser.

Server side compiled languages were working perfectly fine, but we had to have this scripting languages, performance doesn't matter 2010's vibe.

Only for all to realise 15 years later that performance actually matters when paying the electricity bill.

It still doenst really matter for most people.

JS running on a raspberrypi can support most sites on the internet.

Sure it matters at scale but what tech interviews forget is most don't every get to the scale where it matters.

A 2015 machine with duel xeons can run many many small tech companies stacks.

Curious what the GUI part of the stack looks like if you don't mind sharing

> So many companies went all-in on Deno in recent years.

They should hire a few devs to develop it then.

>So many companies went all-in on Deno in recent years.

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?

Do they also do their front-end in Dart?

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

This is actually a good decision though.

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

Netlify and Supabase have also been using them for edge functions.

Given these two are both comparable to the Cloudflare developer stack that I often think of as alternatives, this makes the decision to let Deno die feel at least a bit more calculated.

I do wonder if it's been shopped around to any of these large-scale users as potential maintainers. Seems in the overall wheelhouse for Supabase in particular.

Netlify used to be but is not anymore: https://www.netlify.com/blog/edge-functions-firecracker-micr...

To be extra clear, Netlify no longer uses Deno's managed infrastructure, but still uses the Deno runtime. (Source: I work at Netlify.)

Did they have any heads up about this, and/or do they have any roadmap for what's happening now?

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

> 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.

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

Bun's release cadence dropped like a rock after the rewrite, in spite of the radical AI militancy and virtually infinite AI budget.

They shipped a metric ton of new features in 1.4 and it seems relatively stable enough that it doesn't require too much hot bug fix releases.

> They shipped a metric ton of new features in 1.4 and it seems relatively stable enough that it doesn't require too much hot bug fix releases.

Nonsense. They paused releases to get the rewrite out, and following the rewrite it was rather obvious they lost the ability to release production-grade software.

It would have been trivial to release patch versions with little cleanup work, but evidently the project isn't even able to put that together.

You guys should stop to hear yourselves talking about these vibecoded projects. How come they can simultaneously do major rewrites but be completely useless at refactoring and maintaining their own code?

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).

It's really a bummer that Dart gets a bad rap, because of its early versions. The recent versions of Dart are a lovely language to work with. Pub is the only package manager I've used that approaches Cargo in quality.

All TypeScript competitors got out-engineered by Microsoft. It’s a triumph of experience over new ideas.

How well designed the initial versions of TypeScript were can be seen by how smoothly later versions were able to build on them, and even after so many major improvements the language has barely a wart (enums probably being the only one).

namespaces are the other one, and that's a fun legacy because Typescript had to implement a half dozen module systems in the early days: no modules (jQuery-era globalThis pollution), AMD, UMD, CommonJS, SystemJS, Typescript's own which was proto-ESM inspired but not ESM, then Typescript's realignment with ESM.

Something of its own sign of Microsoft out-engineering some of the hiccups of the ecosystem as a whole. (I started using Typescript < 1 simply because it was the safest and easiest way to write AMD modules also with an eye to UMD or SystemJS output with just a compiler flag change if you needed to ship something compatible outside the house.)

I don't know enough about Angular 2 to know exactly how much of a bad choice that was, but my experience in React has always been "they should have used something else". I vaguely recall our lead backend being unhappy with his decision to do the original admin panel in Angular, but I chalked that up to him not being a frontender.

For context: I begrudgingly adopted Vue a while ago after finding React to be too unwieldy, and part of that opinion is definitely related to a poorly written Redux implementation.

> He was so angry I didn't pick Dart. Good choice by me in retrospect (though picking Angular 2 over React not so much).

1/3rd of apps on the iOS and Android app store use flutter and that percentage is growing over time. Whereas people are moving away from JS/TS frameworks like React Native.

I wonder if TS could evolve into a compiler whose output would use either Deno, Bun or Node? When the exe is compiled it no longer matters what libraries it uses underneath?

Where is that stat from?

My dart story. While in college for computer programming our professor telling us if we wanted to get ahead of the curve start learning dart. It was the future

> though picking Angular 2 over React not so much

It sounds like you're coming at this from a perspective of popularity and thus access to engineering candidates with expertise in it which is fair, but speaking as someone who also went with Angular 2 over React during those times, I'm still using Angular and I'm very happy with it from a technical perspective. Yes, it does mean there are less options for hiring, but it has been a positive experience for my team and for me in my own projects to stick with it.

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/

Which Node now has:

https://nodejs.org/api/permissions.html - since v20 - Apr 17, 2023

https://nodejs.org/learn/typescript/run-natively - stable and without a flag since v22.18.0 - which sometime after Apr 24, 2024 which was the v22.0.0 release

https://nodejs.org/api/single-executable-applications.html - Added in: v19.7.0, v18.16.0 but still in Active Development (not stable yet) - 2022

For reference, Deno was released in 2020 with all of these features from the start.

Feels like it always take some healthy competition for Node to make big strides like this. Like the whole io.js fork thing a long while ago.

I didn't know node got that too but it says right at the start that malicious programs can bypass it. What's the point then?

The Docker of JS runtimes. Deno will get picked up by the community. But CF should sponsor it for at least 250k a year.

You can give permissions to Web Workers when starting them in Deno, which afaict Node cannot do.

The security model has always been a half-baked afterthought. The initial versions were riddled with vulnerabilities .

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.)

Exactly why any company that cares about long term maintenance should stick with Node.js except in cases that justify alternative runtime.

I wouldn't be surprised if Bun is abandoned at some point as well.

(Which is why I am happy to see new runtimes but never care enough to seriously use or adopt them.)

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

Communities aren't always in competition with one another.

Yes they are. If opensource product A does not have better features than competing opensource product B, uses move to the better product A and pretty soon, almost nobody will use product B. Take BSD vs Linux for example. We get "we've migrated to BSD" or "we've migrated to Linux" posts all the time and arguments for one or the other. Is there a winner and loser? Yes. Larger communities, more developers, more corporate sponsors, more contributions, etc. Certainly looks like competition to me.

That’s because you’ve been brainwashed by capitalism. The alternative getting less attention might have fewer resources, but there is nothing to “win” here.

Getting “funded” is to get a job maintaining the project. Great! This happens to incredibly few, high-profile projects. Those people wouldn’t be working on the alternative if they didn’t get paid to work on the one they care about.

>but there is nothing to “win” here.

In the context of Deno here, it obviously implies market share.

There's no "market" to have a "share" of.

Yeah this is it, Bun, Deno etc are 100% good for JS/TS in the aggregate because they push Node.js and npm to actually improve.

However that doesn’t mean it’s a good idea to use them, it is not

But if that becomes common wisdom and nobody ends up using such new projects going forward out of such fears, how will they get the momentum to meaningfully affect change on Node? This worked out with Bun and Deno but not sure about the future.

There are always hype train/resume driven development developers (in fact, there's way too many).

I wish it were otherwise but I don't think anyone running a hype-driven project of dubious utility needs to worry too much, humans are not rational creatures

It wasn't that long ago that Nodejs was the new kid on the block, and companies were worried it would go under.

If my timeline is correct, that was over a decade ago.

Which is forever in the tech industry.

Even longer I'd say. Node was the new kid on the block when I was in college 2010-2011. By 2016 it was entrenched.

Or they could pay for their dependencies.

Asking as a non-JS person - what's the cost and effort to switch?

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/

You can migrate off deno in a single day. It's not a big deal.

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

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.

> ...pretty much any functionality provided to deno is available for node as well.

Unfortunately Node still can't do something like this out of the box (AFAIK at least):

    import { Bla } from "npm:bla@^5";

Such direct imports are basically the killer feature of Deno for simple standalone tooling scripts in otherwise non-JS/TS projects, e.g. it made TS a perfect replacement for Python even without a "batteries included" standard library.

Deno also has a builtin TS type checker, linter, formatter, test runner with coverage support, package manager, language server etc etc... In node these are all separate (and often 3rd-party) tools.

This doesn't seem like a big deal. Don't you just npm install whatever you need and then change the import names?

I don't want the install step. That's redundant. Just a .ts script I can run via `deno run bla.ts` and which directly pulls in any dependency it needs from the web.

I understand the point of this, just saying an existing codebase importing things this way doesn't seem all that hard to convert if you need to get off Deno.

Bun has auto-install for you, but you do have to enable it.

Deno's is slicker. Deno's built-in LSP works with the automatically installed package's types.

Well, nobody is supporting that any more. So you either support it yourself or stop using it.

That wasn't the question though

Is it?

It's a different mental model I'd say. Specifically: First, I add the part to the pile, then I wire it up.

I wouldn't call it redundant to explicitly spell out what actually happens. If anything, I'd call it good to remind people that they are adding something into their scope of responsibility.

There are use cases like small scripts where people just want a single js file. So the top of that file basically functions as the package.json.

> and which directly pulls in any dependency and exploit

Fix't it for ya.

this one is actually a bad pattern to avoid.

Only when you have no control over the version you're pulling in, but the semver resolution works as expected. Also we're talking about small standalone 'shell scripts', not 'real projects'. Think 'bla.sh', just with a .ts extension. Deno is really great for such small helper scripts.

> Also we're talking about small standalone 'shell scripts', not 'real projects'. Think 'bla.sh', just with a .ts extension. Deno is really great for such small helper scripts.

Okay. Now I'm confused and my head hurts. You want to randomly download dependencies for a "shell script" at the time of invocation?

I think I need to lie down.

Please explain what exactly is the problem with installing dependencies on demand compared to an 'npm install -g bla', 'brew install bla' or 'apt install bla'? It requires exactly the same amount of trust and is the the same thing under the hood, just that it happens automatically on first invocation of a script.

Then put shell function to your globals which will mimic install + run. It’s literally like 5 minutes of work max and you’ve spent way more arguing over it already.

Nobody says Deno is not better overall than Node. It clearly is, across the board. And nobody cares.

If Deno would provide actual improvements people would care about then for sure it would survive. The problem is that it didn’t. It was just fun project and creators learned a lot for sure. And entire js ecosystem improved thanks to Deno’s push.

If we were talking in the context of large TypeScript projects, you would be right. Central management helps the project avoid adding too many dependencies.

But you replied to a comment that said "for simple standalone tooling scripts in otherwise non-JS/TS projects" where this absolutely is not a bad pattern.

FWIW, almost this exact syntax for imports (without the `npm:` prefix) is supported for standalone scripts with Bun.

Bun is not an alternative, it was also acquihired and will probably become an internal project of Anthropic for claude code.

And this is why deno is exiting.

There's no business here anymore.

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.

what other runtime has runtime security features?

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

Not really. Tons of platform lock in Apis, Deno.serve, KV etc..

You can't just switch over to nodejs

I don't use KV, but I doubt it's hard to migrate to another key-value store.

Deno has tons of browser APIs, e.g. Deno.serve uses the standard Request and Response objects. That's not platform lock in.

It requires a rewrite and to migrate production systems away from it. Its not a small task.

Honestly migrating back is trivial now. It just isn't that big of a pain.

It's why I usually look more closely at the comments here than at the story for stories like this.

Seems like an extremely risky thing to do. Luckily they can keep maintaining it and improving it if their business is truly dependent on it.

I wonder how much they have financially contributed to Deno.

At least open source gives them an opportunity for the community to find a way to support it going forward. But I suppose that's just table stakes these days.

Anybody who has been bitten by the many issue with Yarn over the years can tell you, just stick with stock tools and deal with it.

I dunno, we've been using pnpm for years now without issue, and it's been faster and a little more secure to boot!

Radical idea here, but maybe those many companies could _fund_ the development of key components of their infrastructure.

Maybe but only if that gives them a competitive advantage.

There's no reason companies can't fund mutually beneficial entities. In fact, it's quite common in the form of trade associations.

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?

Developers as well, all other professionals pay for their tools.

If only those that boast online how X is greater than Y in every single thread, actually paid even a Starbucks coffee to X.

I guess "joining" was the key word here. But I'm not particularly surprised now that I see it meant acquihire.

Well, the license Deno is distributed under explicitly warns you (sorry for all caps):

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

Node is old I’ll give you that. Dependable is debatable.

I mean, if you have any test suite worth a damn, then this should only cost a few dollars in tokens for the average team and be nothing more than a minor inconvenience.

If it was truly “so many companies” then they wouldn’t be in this situation… reading between the lines here it’s clear Deno was not a successful project.

Being successful or not depends on the scale of the company. I'd wager at Cloudflare scale, many otherwise decent businesses would have virtually no effect on their baseline and wouldn't be worth running.

Regardless of the size, being successful means, is there enough money in the bank at the end of each month.

You're defining being sustainable. IMHO "successful" is a lot more relative and defined by expectations.

To jest, businesses can be successful without sustainability. Instagram definitely was.

If being successful means pumping an idea for acquisition.

Or if being successful means building something billions of people use on a regular basis

like, idk, nginx?

It might not have been a successful project as a VC growth startup, but lots of people saw that coming here in HN when they started raising millions.

In the space of such foundational technologies, there’s always been a vast gap between the number of private vs open-source projects that succeed. Even all the way back to proprietary compilers 40-50 years ago.

If they had stuck to being an open-source project, the kind of adoption and mindshare they achieved would have put them among the most successful ever. And I am sure they would have been able get their team paid very well sustainably. The unicorn model cannot fit every single venture.

If they cannot pay bills, because no one pays upstream, then it is a failure as company, regardless of VC growth.

Some day devs will learn FOSS projects don't survive on good will alone.

An open-source project with their success could have easily paid their bills through sponsorships and support contracts, as many others do.

But the VC path pushed them to increase costs more than they should. They didn’t need that money to deliver on the mandate of Deno, they had to inflate the vision to some grand cloud solution, which didn’t make much sense.

> then it is a failure as company

Perhaps it shouldn’t be a company at all. Private companies cannot attract the same support as open-source foundations do, since they are for-profit organizations.

No they don't, they survive like street performers, some days the hat is full enough for a warm meal.

Foundations are companies in disguise, with taxes benefits, and there isn't one without industry partners.

Which programming language survives with support contracts, no company sponsorship, and has mainstream adoption?

C? c++?

Was going to suggest Python but that doesn’t pass your “foundations don’t count” logic (that I don’t really agree with)

Of COURSE there are industry partners. That’s not a bad thing!

> An open-source project with their success could have easily paid their bills through sponsorships and support contracts, as many others do.

I have great news for you, then. You are free to pick up the project for free and rake in all that free sponsorship cash.

Do you think this is a reasonable investment of your time?

Reminds me of Gatsby.

Doesn't supabase edge functions run on Deno? I presume this is huge setback for companies like that and their users.

But then again considering there's no barrier for entry to develop runtimes now, I guess these companies are just going to develop their own.

Congratulations to the Deno employees.

Edge functions use https://github.com/supabase/edge-runtime/ (which uses an older version of Deno), and run on Supabase-managed infra :)

I was wondering about Supabase as well.

It appears that they are well on thier way to supporting all possible runtimes.

https://supabase.com/compute

There is no barrier for entry to develop runtimes but there is one for maintaining it. Let's not forger that cost.

Whoever did it, decision maker was reckless and should his job should be reassessed. This is not surprise, similar will happen to Bun as well, just matter of time.

Those reckless decision makers are also responsible for Node’s popularity.

Only after Anthropic rebuilds Claude in Rust.

> So many companies went all-in on Deno in recent years.

I hate to cite xkcd 2347, but if those many companies are using a FLOSS project without contributing anything back them they need to put on their big boy pants and stop expecting others to do their work for free.

They can fork it.

Surely they could fork it and just continue it OSS?

Deno always felt like a "people pot", the kind of company whose sole (but unstated) purpose is to attract great engineers, which, not unlike soccer players, can then be "sold" to a different company who can actually utilize them. The actual product was secondary at best.

Keybase, Astral and Oven / Bun are other examples of this, I think Zed is on a similar path.

> Astral [...] The actual product was secondary at best.

No one who has tried ruff, uv and ty would agree with that.

Nor go back to any of the previous alternatives Astral's products replaced. (With the possible exception of ty since that's still pretty new)

> to attract great engineers, which, not unlike soccer players, can then be "sold" to a different company

this is so much bullshit I don't even.

even if they thought that could actually work : it could not unless by "great engineers" you mean "resume-pad masters".

Node was once the shiny new thing, so that argument is irrelevant. Deno got a lot of traction by promising to fix Node’s issues, some people trusted that promise, and Deno just didn’t deliver.

The yt-dlp project uses Deno as its default and preferred JavaScript runtime when downloading YouTube videos (this replaced their own handwritten JS interpreter). Fortunately yt-dlp also has support for Node and QuickJS as well as deprecated support for Bun, but I don’t think any of those were preferred by the project for various reasons such as portability, security and I think also speed.

See https://github.com/yt-dlp/yt-dlp/issues/14404, https://github.com/yt-dlp/yt-dlp/issues/15012, and https://github.com/yt-dlp/yt-dlp/wiki/EJS.

As I recall, they picked Deno over Bun during the whole vibecoding rewrite fiasco from six months ago, and there wasn't a ton of explanation given beyond the general vibe of "ai bad". They might reevaluate that in light of things being generally fine and losing their precious handcoded runtime choice.

The vibecoded rewrite led to the deprecation of support for Bun but I believe Deno was already the default. Also Bun had the note “No permission restrictions available. Scripts have full file system and network access.”

> there wasn't a ton of explanation given beyond the general vibe of "ai bad"

I'm very bullish on AI, but vibe-porting the piece of software you're the main maintainer over a few weeks without letting anyone in the community know and pushing that as a fait accompli to both your userbase and your open source community is definitely the kind of behavior that makes you not trustworthy enough to depend on.

as a counterpoint, your fears are hypothetical so far - nobody on earth cares as much about bun as the bun team and if it was good enough for them it is probably good enough for 99% of users

i think someone who has built their infra on top of bun and have bills to pay care much more about bun stability than the team who get paid by Anthropic to vibecode an entire rewrite to another lang

> someone who has built their infra on top of bun and have bills to pay

they were stupid to do this in the first place. bun has always been a one man show. what were their plans for when he got hit by a bus?

I totally thought the other guy had you in the argument, and your retort blew my mind. An excellent point, people really need to research their runtimes before placing the entirety of your infra on them. Then again, I suppose that’s partially the reasoning for the existence of support contracts. I’m just going to add this here, but: was this whole thing just an aquihire? The dude is a badass, so I can see buying deno just to get him… skillset matches the areas cloadflare has roadmapped out, but still needs to shore up (a lot)

If I remember correctly, Deno was always priority number 1 due to having a permissions system. Bun's removal due to the rewrite had people complaining using Deno as the focus as Deno's development shifted towards being LLM heavy. Node now supporting permissions would likely be the priority now.

There was a ton of criticism beyond "ai bad". A complete rewrite, in a different language, is a brand new project. It doesn't have any where near the hardening as the previous version thousands of deployments. If they had done that exact same thing but without AI people still would have been upset.

> As I recall, they picked Deno over Bun during the whole vibecoding rewrite fiasco from six months ago, and there wasn't a ton of explanation given beyond the general vibe of "ai bad".

Your comment is baffling. Either you lost track of the story or you've opted to post a very simplistic take on the whole Bun fiasco. Bun's ill-advised rewrite had zero technical grounds and the radical drop in release cadence in spite of all the AI backing suggests the project's foundation lays on shaky ground.

I don't think that's a good interpretation of what happened.

Bun's release cadence dropped because they had just ported to a new language and they weren't about to release that to their community without letting it settle in for a couple of months first - which they did, by running it in Claude Code on millions of computers.

> (...) they had just ported to a new language and they weren't about to release that to their community without letting it settle (...)

Nonsense. If that was remotely true we would have seen a wealth of maintenance releases immediately following the rewrite, along with feature work.

However, development completely stalled, even though they can throw ungodly amounts of AI compute at the problem.

Don't you notice an incongruence in your remarks?

Development stalled? Here are the stats on commits to Bun in the past six months:

(If it had stalled for a year then yeah, you'd have a point. I've seen projects stall for a year or more due to a rewrite.)

  +------------+--------------+
  | Week of    | Main commits |
  +------------+--------------+
  | 2026-04-13 |           88 |
  | 2026-04-20 |           95 |
  | 2026-04-27 |          200 |
  | 2026-05-04 |           25 |
  | 2026-05-11 |           50 |
  | 2026-05-18 |          148 |
  | 2026-05-25 |           77 |
  | 2026-06-01 |           70 |
  | 2026-06-08 |           37 |
  | 2026-06-15 |           60 |
  | 2026-06-22 |          153 |
  | 2026-06-29 |          102 |
  | 2026-07-06 |          137 |
  | 2026-07-13 |          213 |
  | 2026-07-20 |          210 |
  | 2026-07-27 |          185 |
  | 2026-08-03 |          164 |
  | 2026-08-10 |          316 |
  | 2026-08-17 |          284 |
  | 2026-08-24 |          196 |
  | 2026-08-31 |          157 |
  | 2026-09-07 |          119 |
  | 2026-09-14 |          154 |
  | 2026-09-21 |          123 |
  | 2026-09-28 |           68 |
  | 2026-10-05 |           21 |
  +------------+--------------+
  | Total      |        3,452 |
  +------------+--------------+

For context, the Rust rewrite started May 4th, landed on main May 14th, the last remaining Zig code was deleted June 24th, and the first stable Rust release was cut on August 19th. Prior to that people had to test the daily unstable releases.

I think it takes quite severe motivated reasoning to look at a project that ported from one language to another and shipped to millions of end users without incident (Claude Code users didn't even realize they were running the new version) and conclude it was a "fiasco".

The fiasco was that a lot of people were unhappy about it. I'd be interested in seeing a Venn diagram of people who complained about the Bun rewrite and people who don't like AI-assisted programming. I suspect the overlap is heavy.

Actually, to be fair, the real fiasco was project governance.

If I had built my own project on Bun specifically because it used Zed, and had my own custom Zed extensions, I would be justifiably angry that the project ditched Zed without any community input at all.

If that's your complaint than I think it's credible.

For asynchronous downloading of huge media files, speed should not be a priority?

Afaik it's used more for circumventing anti-bot measures and solving challenges than the download handling itself.

This is accurate (maintainer of downstream project that depends on yt-dlp for archiving operations).

Yes, that's what I meant; if the download is going to take minutes, then a fem milliseconds spent doing the challenge don't matter much?

I believe the parent comment is saying the js runtime doesnt affect the speed of downloads, thats all c/c++/rust code

When downloading huge media files, the only speed you're being limited by is your bandwidth.

Everything else is completely negligible.

What makes Deno more suitable for this than any other runtime? It's just executing JS code right? I wouldn't think this would leave any meaningful fingerprint.

Sanboxing makes it more suitable.

yt-dlp executes code from the website to get the exact download URLs and header values. The websites obfuscate these to prevent downloading. Running arbitrary 3rd party code in Node or Bun might work, but is risky, especially when that code could potentially come from one of the many ads on that video website.

QuickJS works fine for yt-dlp and is way smaller: less than 1 MB vs 34 MB + its many dependencies for Deno.

See https://github.com/denoland/deno/discussions/9811

So "Deno" isn't joining Cloudflare, Deno is effectively defunkt and its former team is joining Cloudflare.

jsr is moving to cloudflare.

isn't that fairly irrelevant if Deno dies out? Does anything else use JSR?

I tried using JSR for about a week, but the restrictions were so tight I gave up.

It’s immutable npm, you can’t unpublish I believe but yeah it’s trick of allowing one to publish typescript packages rather than compiled js only applies to deno.

JSR packages can run on Node.js, Bun, Cloudflare Workers, etc. The maintainer uploading the package decides which runtimes are supported.

Ah, fair enough, makes the whole situation a bit more lame

‘Acquires’ is an interesting word, given they’re hiring people and sunsetting the product. They didn’t buy Deno, they hired the team that built it and that forces them to abandon the project.

Language really means nothing these days…

(Yeah I’m salty, I got all in on Deno a year ago.)

I don't like how that's in the Deno post but gets no mention in the Cloudflare post. Seems like a pretty important detail!

Definitely negative karma points for Cloudflare.

well I just don't get it -- why?

unless cloudflare's CEO is a friend of cloudflare people, so just want to financially them bail out...

...why acquire and kill? cloudflare can have more outreach and reputation by keeping deno alive

> why? unless cloudflare's CEO is a friend of cloudflare people, so just want to financially them bail out...why acquire and kill?

Aquihiring is a time-tested strategy to build out a team. The Deno folks likely have a bunch of experience that Cloudflare is well placed to make use of

Aquihiring also requires the personnel hired to... actually stay with the company....

Unless you dangle HEFTY stock options with incremental maturity dates, nothing is else is keeping them from leaving.

> Unless you dangle HEFTY stock options with incremental maturity dates

That is indeed how this whole thing works. I used to work with several folks who were kicking around FAANG for 4 years till their acquisition stock fully vested

When you consider how much time/money it takes to hire an experienced engineer, and how quickly they are liable to jump to the competition, acquiring an existing team of experienced engineers and tying them with the golden handcuffs is not a bad deal

> acquiring an existing team of experienced engineers and tying them with the golden handcuffs is not a bad deal

well... why not tie who's already inside the company (who you actually know about) instead of an external people (who you DON't know about)?

it's much difficult to get info about some external person, and most info is about external reputation ('the looks')

though... that's the reason job-ping-pongs work: someone outside looks better than someone inside, because of your lack of info

If the talent wanted to work at Cloudflair, they'd apply there. Being acquired is a loss of agency and the project you care about is shut down. Several public research papers say retention is hard.

Which also leads to considerable questions about if the thing being shut down in the acquirehire was the real purpose and any momentum of the team itself moving to new projects a bonus.

that just means they might not be actively looking to join cloudflare but are willing to do it if the price is right. nothing wrong with that, it's how employment works for the most part. likewise retention in these cases is typically solved via golden handcuffs, another "the price is right" thing.

I assume the logic is something like this:

- We want to do more work on our runtime and need people to do it

- Those developers for that company over are there working on another runtime

- Buying that company allows them to come work for us without any potential issues from investors in that other company

I think it’s covered appropriately for the audiences. The two posts are for different audiences and purposes. The Deno post by Ryan is for the Deno audience, which is mention at the top of his writing on the Cloudflare post that is for a broader audience of what this means for the Cloudflare audience: “For more on what's happening to the Deno runtime and our various efforts, see my post on the Deno blog.”

FWIW both Ryan and Kenton are very transparent in person, in public, and online over their professional careers. They will and do openly change their minds based on new information and opportunities as time goes along. Both are now founders of open source projects acquired by Cloudflare for the technical architecture talents seeing a future that they would like to build.

There's no need to excuse this behavior. People who write announcements like this are dishonest to their core.

Oof.

The writing had been on the wall though, ever since Bun's rapid success with their alternate strategy. Deno quickly started removing its opinionated stances and playing catch-up on Node compatibility.

I loved their original vision, and I'm glad they tried. They had some really cool ideas for a better world of JavaScript, and I do think they placed some pressure on Node and made it better in the process. I'm also glad they're getting a buyout for their hard effort, even though it's probably more about hiring a team of skilled JS runtime engineers than about acquiring the technology.

RIP Deno

I'm happy that the Deno team found a suitable home. Cloudflare is likely the best place for them to land. I believe they will do great things together. However, I'm a bit concerned that there are very few independent Node.js runtimes: Anthropic acquired Bun, and now Deno will not be developed further.

Somehow I don't believe that Cloudflare doubling down on their own runtime -workerd, which will be likely migrated to Rust soon [1]- is the right choice (since it push on semantics that can only be run on Cloudflare infrastructure). I strongly believe Node.js semantics are likely the right ones for agents.

If anyone is looking for a full-open source alternative to Node.js that can run everywhere (browsers, phones or servers), please be aware that you can rely and use Edge.js [2] (disclaimer: Edge.js is part of the company that I founded: Wasmer)

[1] https://x.com/KentonVarda/status/2108559594691690663

[2] https://edgejs.org/

Dumb question: Why do we need many independent Node.js runtimes?

Well it keeps all the node developers away from my shit so I'm happy :)

I believe it indicates a healthy market and pushes competition and better outcomes for customers. In this case, Deno pushed Web primitives for Node.js and Bun pushed forward on speed (and helped Node.js work on their numbers better).

This have a similar analogy with browsers. Back then when Internet Explorer was the only supported browser, the websites were not evolving as fast. When Firefox pushed it forward and then Chrome, customers won (better and faster sites).

We need them so you can pick and choose the one that works best for your current project.

But that points to an important aspect of the platforms-game: The interface between the runtime and everything else should be standardized, to support true pick-and-choose.

> now Deno will not be developed further.

that's an interesting reflection on the nature of open source - in theory the source is there and "the community" could conceivably continue development. especially in the case of something like deno where the people most motivated to keep it alive are already programmers. but the reality is that however distributed an open source project is in theory, in practice it needs a single entity to steward it, otherwise it will die.

hopefully that single entity can be a consortium of companies invested in using the runtime, sort of like opentofu recently.

> consortium of companies invested in using the runtime

I believe this is very unlikely to happen. If the founder (Ryan) was involved in it or it have strong market position, it would have strong chances.

Now, is a kingdom without a king and without strong companies to steward it forward. I hope to be wrong though!

Maybe in another decade he'll pop up again with a third runtime called something like "Edno" that tries to do things differently than both Node and Deno. There are plenty of permutations of those letters left!

From a quick search, it looks like they raised $21 million in funding half a decade ago (after an earlier seed round), so this seems less like a reflection on the nature of open source in general and more just a reflection of this one project. It was set up in a way where development was happening because people were being paid to do it, and this time next year, they won't be. Maybe the community would have come in to try to keep it going if there wasn't any funding, or maybe it would have just stopped seeing any real development, but we can't really say for sure either way.

the $21M was presumably not just to develop deno but to build a business around it, which is a much harder problem. this feels like more of a bystander effect problem; if as few as three large companies that benefited from deno were willing to form an "openedeno" foundation and assign one full time employee each to it i'm betting that would be enough to at least sustain the project in a usable state, but of course everyone is hoping someone else will do it.

Why Edge of Node.js?

> since it push on semantics that can only be run on Cloudflare infrastructure

No, workerd and its semantics are not exclusive to Cloudflare infrastructure. People really do run it in production without using Cloudflare at all (I really wish I was allowed to say who because one of the users is hilariously ironic...).

Ryan's and Bert's core focus at Cloudflare is going to be making the self-hosting story better.

This was emphasized in the blog post: https://blog.cloudflare.com/deno-joins-cloudflare/

Thanks for chiming in Kenton.

> workerd and its semantics are not exclusive to Cloudflare infrastructure

I believe they are. You may be able to run workerd, but you can't run D1 (Sqlite alternative), you can't run KV or Queues (please correct me if I'm wrong).

All those are primitives that already exist in the non CF world: KV can be easily redis/memcached. Queues, Kafka and so on. I believe that a system that reuses those would be stronger.

> I really wish I was allowed to say who because one of the users is hilariously ironic

Ok, this peaked my curiosity. Would be great if you could share it!

> You may be able to run workerd, but you can't run D1 (Sqlite alternative), you can't run KV or Queues (please correct me if I'm wrong).

Details remain to be worked out, but part of the goal of the project is to make all these interfaces plugable with reference implementations that can sit on common infrastructure.

In fact, celld has already done a lot of this.

> Ok, this peaked my curiosity. Would be great if you could share it!

You'll have to find me in person over drinks somehow. ;)

Is it the triangle ?

> the goal of the project is to make all these interfaces plugable with reference implementations that can sit on common infrastructure

That's great to hear.

> You'll have to find me in person over drinks somehow. ;)

Challenge accepted!

fwiw, from his previous comments it sounds like most might be better off using durable objects directly rather than D1 anyway https://news.ycombinator.com/item?id=48611834

So they don't want to buy Deno, they want to buy the team to work on something cloudflare specific.

I'd say it's durable object specific. Both team deno and cloudflare (and many others) have been won over by the paradigm. Cloudflare is just the primary implementers of it as a strong example of an actor-based programming model at infra layer, but others have been trying to push it (Rivet, and TerseAI's durable actors, celld)

EDIT: like the whole enthusiasm is that they are buying them because they are generalizing a thing to be NOT a cloudflare thing

Why is cloudflare even buying deno in that case? Is it an acquihire?

Why would they acquire them then shut it down? Is there a reason for that?

Acquihire - they’re acquiring it for the team behind it to eventually develop proprietary software

> develop proprietary software

This is a weird strategy to stake future IP value on in the age of AI. With competent and fully qualified team, anyone should be able to reverse engineer this idea and build a roadmap for their own implementation. Especially in the world of open source.

Do you really think someone off the street, armed with Opus 5.5 could recreate Deno? Or would you pull Cloudflare people off what they were doing (meaning it's a very inefficient company) to work on this?

At the end of the day, great engineers armed with great tools are going to outperform anyone who just has the great tools.

1. They can gain at least a temporary advantage by using a proprietary version. They'll have the original devs who can continue where they were before. 2. I wouldn't be surprised if we end up with a situation where LLM-based copyright laundering becomes illegal/enforced, but only in favor of large corporations' copyright, in which case they could maintain the advantage

What would they miss out on? A bunch of PRslop? The "open source community" is now dead.

acqui-hire

Fundamentally this acquisition is not about Deno the open source project. It’s about buying an amazing team that has built a self-hosted version of Cloudflare Workers that actually doesn’t suck. And that is all about commoditizing the complement.

Deno built celld, which implements the Workers and Durable Objects programming model with self-hosting in mind. Cloudflare says its own distributed infrastructure is too complicated for straightforward self-hosting, and it hadn’t successfully solved that problem. For customers who might be reluctant to commit to being locked in to Cloudflare’s infrastructure, having a rock solid self-hosted alternative reduces that reluctance.

I wonder how easily could you port celld to Node.js?

Hopefully not to stop celld, the cloudflare Durable Object compatible impl. https://github.com/denoland/celld https://news.ycombinator.com/item?id=49185430

Phrased as it being merged into the existing, but I can't help but fret a bit. Is cloudflare willing to let their own core compute product be something available to the world? Absolutely sick wins if so. But I worry celld pretty reasonably seen as a threat.

read the Cloudflare post, basically the opposite of that: https://blog.cloudflare.com/deno-joins-cloudflare/

Why would they buy something just to potentially kill it?

Funny that with Bun being acquired by Anthropic, if this big bet on AI doesn't work out we'll end up right back where we started; Node. Obviously Deno will still be OSS, Bun would likely end up that way too, but you get the idea

but even in that scenario, the node competitors absolutely spurred new energy and innovation in node, as node themselves have acknowledged

This is the real headline... and more so that it has been hidden away.

So why cloudflare buys them? Just to do the MS thing?

The CloudFlare blog concludes with:

"By bringing celld and workerd together, we want it to be radically easy to build and operate distributed applications on your own infrastructure."

It does not appear they are close sourcing it. He mentions workerd is open source. Roadmap needs better communication but it appears people will be able to switch to new merged OSS version. It's just not well defined what it looks like yet.

We don't completely know what it will look like yet either, but it will absolutely be open source -- as workerd and celld are both already.

The fate of many forks, while reference implementation keeps chugging along adopting the most relevant features.

Deno is decidedly not a fork for Node.

Did they replace V8? Nope.

Is Node a fork of Chrome? They didn't replace V8 either.

It is Chrome on the backend, so yeah, kind of.

What is in this for Cloudflare? Just the employees? I can't imagine hiring these days is that hard that it's worth creating this much ill will.

This is just normal open source. The software is provided AS IS, WITHOUT ANY WARRANTY.

As a community we've gotten so used to getting things for free and then getting mad when they go away. That's a fine attitude if it's your hobby dependency, but if you're making $100k off that dependency what did you actually expect?

Genuine question, is this legal under US anti-monipoly laws?

I don't really know anything about that area, but didn't Facebook get in some trouble for purchasing Instagram in part due to them being competition.

Surely buying a company out only to close their main offering is defined as anti-competitive?

I'm not sure if it is legal or not, but it happens all the time, and nothing is done about it.

IMHO, it shouldn't be allowed.

US level anti-trust laws don't touch on a lot of anti-competitive behavior, mostly specifically it almost solely concerns just trusts and monopolies. I don't think I've heard of a court case ever before simply on the death of a product.

But also US anti-trust laws at the federal level have always relied on a strong FCC, FTC, and US Attorney General's Office to execute, all of which are currently neutered and/or understaffed under the current administration (and may take years to recover even in the best case scenarios). The US has decided it is a season for trusts and monopolies.

(See the mergers of Paramount and WB into Skydance consolidating 200+ combined years of movie history into a single monopoly under the Oracle nepobaby and almost directly undoing/mocking one of the largest and oldest anti-trust cases which was US v. Paramount Studios which set precedents for how large a movie studio could grow that lasted almost 100 years.)

(There might be something the state of California could do, but I don't know how much they want to get involved.)

California has chosen not to get involved - they threatened to then backed down.

US v. Paramount separated movie studios from movie theaters.

Sumner Redstone came from a movie theater family and formed modern Paramount by buying Viacom (which was spun out of CBS due to antitrust), Paramount, and then later CBS itself. He was able to buy Paramount as a cinema owner because the government abandoned the rule that you couldn't own both the studio and the theater in the 80s.

The corporate history of Hollywood is long and complicated. Skydance is obviously a big topic this month, but Paramount was owned by the Redstone family's National Amusements theater for as long as many of the adults on this site have been alive.

National Amusements wasn't considered an official breach of the Paramount decree because it was "the other around", a theater chain owning a studio rather than a studio owning the theaters. It also got a lot of weird exceptions because National Amusements was entirely private at the time.

But the current issue is right now streaming services dwarf theaters today. The Paramount decree was officially suspended by this administration and its courts on this matter stating it isn't a monopolistic oversight for studios to own and entirely control their streaming services (despite doing the exact same things with "originals" and "exclusives" that led to the original Paramount decree). This administration and its courts not only said the current streaming situation is fine, but that it also means the original Paramount decree no longer applies and studios may own theater chains again, because theaters now compete with streaming.

Skydance having both Paramount+ and HBO Max gives them a huge amount of leverage in the streaming space that is going to get stranger with this consolidation, and gets back to why that 200+ years of combined film history is important and relevant.

Do you think Deno was real competition for Cloudflare, and now that they've merged we don't have alternative options for goods/services that are mostly essential?

I think if Cloudflare and Google merged, it still wouldn't be a monopoly because of AWS (and many others).

In what sense did deno compete with cloudflare? It is a niche runtime and cloudflare is a cloud platform

Workers against Deno Deploy? And even if you don't count Deno as a whole in the same market as Cloudflare it's still shady as hell. They had plans to buy out a company with the explicit intent to shut down their main product.

You would expect them to integrate Deno with Workers, make a new official managed service that would probably become profitable in no time with Cloudflare's cost optimized infra, or at least commit to basic security fixes until the community finds new maintainers.

What they pulled off instead is the most toxic form of acqui hire ever invented.

> They had plans to buy out a company with the explicit intent to shut down their main product.

I understand why it looks that way, and we knew it would be hard to combat this perception.

But it's simply not true.

The actual story is simply this: The Deno team made a strategic decision to refocus on celld, and we (Cloudflare) are excited to support this work, for the reasons I explained in the blog post: https://blog.cloudflare.com/deno-joins-cloudflare/

See Ryan's own comment here: https://news.ycombinator.com/item?id=50023277

> but didn't Facebook get in some trouble for purchasing Instagram

They got scrutiny over it, sure. But trouble? No, I would say that they did not get into trouble.

this is SO SAD. i've spent months on my deno tui

https://github.com/ubernaut/exotui

https://ubernaut.github.io/exotui/

Pretty cool looking project you made though. Sorry.

Damn that sucks. I love Deno. It really should have ‘won’ the runtime race. Oh well.

It's more honest than other silently unmaintained project.

Thats really upsetting ngl.

What's the business logic behind buying and sunsetting?

You get a skilled team who have been thinking about and working on the problems you want to solve for years.

Hiring an entire team that works well together is a big accelerant compared to finding and hiring the right individuals and trying to form that team.

See also Ryan Dahl's comment here: https://news.ycombinator.com/item?id=50019911#50023277

It's good for everyone but the community, unless I'm looking at it wrong

Yeah, the only losers here are people who have a heavy investment in Deno for their own projects :/

I missed this when I skimmed the post. Sad stuff. I'm a big fan of deno.

Interesting. I guess open source is not as dependable as it used to be

Why buy it then? The staff?

Hmm ... so why would they acquire it to let it die?

Classic acquihire? They allow customers to run javascript in their end nodes, surely the competence is useful.

Competitors use it as their serverless JS runtime, likely as simple as that.

Isn't that underselling the opportunity?

I'm sure they'll have a migration path to the cloudflare platform in 12 month.

This is exactly what I was wondering.

Fuck me! We’re going to have to start our migration as soon as possible. I knew we were in a precarious spot after the layoffs, but this is a truly sad outcome.

i guess bun won

> So unless someone else picks up development, Deno will no longer be supported.

Isn't that what FLOSS is all about?

I'm saddened by this, and will now need to plan for some migration work in a couple of production projects. Sigh.

Shame- it is my favorite Markdown formatter.

I mean we already have a winner (Bun) and it just means that Deno has admitted defeat.

From what is likely going to happen is that Deno will be donated to the Linux Foundation to avoid this.

Bun admitted defeat and sold themselves even before Deno. Node.js is and always was the winner.

Bun being acquired was not an admission of defeat. They are still actively developing.

Kinda feels like a rug pull, similar to Bun.

Not even close as Bun is still being actively developed, albeit with less fervor.

Which any existing user can just do?

Reply on news.ycombinator.com