I helped Deno bring the Standard Library to v1 [as a contractor] and have always loved the team and philosophy. But these days I’m saddened by what seems to be their slow decline into obscurity. After the layoffs, there seems to be no roadmap, no comms, etc. I’m just so curious as to where they’re heading and still hope the best for it. I’ve always liked Deno more than Node and Bun.

I've read OP blog and writings for a time. The one takeaway - for me - is how negative/defensive the writing is. And, I'm not sure why it has to be that way.

---

Node kept doing its thing when Bun, Deno, etc. was all the rage. And I do respect Node team for trying to improve little by little. It's not an ideal runtime but, it is _trying_... and that's a positive story.

Deno is still an easy pick for me because of its built-in test-runner (deno test), linter (deno lint), and type checker (deno check). I've used many different npm packages for these things in previous projects and I have no idea what the new hotness and proper configuration is for all of these things in a new node project, so I really value the simplicity of Deno for it all. Also JSR and Deno for publishing Typescript libraries is still so much easier than setting up a Typescript node project and configuring it to publish compiled code, and it gets you documentation pages generated from your tsdoc comments too, which I never knew how to do outside of JSR.

> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem.

Bad news (well not news, this happened a while ago): https://www.cnbc.com/amp/2020/03/16/microsoft-github-agrees-...

With LLMs becoming prevalent, it seems people are “quitting” their projects more quickly. Not necessarily a bad thing, but just shows that the opportunity cost is too high right now if you’re building the wrong thing. Deno isn’t the wrong thing, but LLMs don’t reach for it and that’s a huge blow right now.

I'm concerned about the Deno team's lack of comms and opaque roadmap, but this post mostly demonstrates the author's lack of awareness of what Deno brings to the table and why it's still a compelling runtime in ways Node is still not.

There are valid reasons to choose both, valid reasons to be concerned about the direction of both, but most of the criticism here doesn't seem worthy of a blog post, let alone making it onto the front page of HN.

> vibe-coding Temu Cloudflare.

this is not fair. given the amount of work going into cell-d which will make an open source self host-able workers platform.

cz at the moment there's nothing comparable to Cloudflare workers.

I'm building on Deno for the past 2 years and I have no regrets. It still delivers me why I picked it over node. Less config, less packages to install, good DX.

I know Bun is kinda not the fan favorite right now with the Anthropic acquisition and the Rust re-write drama and such, but on every one of the dimensions listed in this article, I like Bun better than either Node or Deno.

Turns out the 'boring enterprise runtime' spent its time actually shipping stability while everyone else was chasing the next shiny runtime hype cycle.

> even surpassing Deno in places

If you’re trashing Deno, it would be nice to give some examples of where node surpasses it and has not just caught up.

Node has felt fine to me for quite awhile. There was a brief time where it felt a little slow comparatively but it's been mostly ironed out. They tend to address their problems decently fast.

The Internet loves to adopt a new shiny thing, try to convince everybody else it's the right decision because it's the decision they made, and then get quiet about it. (i.e. they went back.)

As a casual both Bun and Deno user, I have generally preferred Bun to Deno unless sandboxing is a concern.

I'm not quite sure I've seen a runtime, JavaScript or otherwise, that has the same network-level gating that deno enforces. Making an allowlist of addresses the default seems like it needs to be table stakes in the agentic era.

OP, if you are here, here's how the website looks in an older Firefox: https://i.imgur.com/hYh7Gat.png

I am not sure about deno not being innovative - I've recently started using deno for it's new desktop app support only (https://docs.deno.com/runtime/desktop/)

I never left node.

The thing with being around for a while is the ability to seat on the porch, watching the adventurers' caravans pass by, once upon a traveller in one of those, now only the ones that actually make the way back into town matter to actually have a second look and talk to the strangers.

Oh, I always thought this was the blog of someone that had spent a lot of time developing using DBUS

I was impressed by bun from the very beginning, and that continued until I needed to use native GPU calls. I had to switch to Node.js subprocesses.

When comparing Bun and Node.js for my tasks, I keep finding more advantages in Bun’s optimizations. I'll handle GPU processes through BFFI. Node.js is also prone to unstable memory behavior with native processes, so it doesn’t make sense to use it as an extra layer.

For those looking for stability, Node.js is definitely the better choice.

>My (ancient) experience with NVM and NPM hasn’t been stellar. I heard Fast Node Manager (FNM) was better to switch Node versions. Obviously I roll bleeding-edge but I have client projects that demand stability.

Why would just switching the binary version in path be something deep enough to have a preference?

Honest question, I'm trying to think how can the experience be good or bad in a command that's just "use 3.2". Isn't the whole thing a switch, a state variable and maybe handling the download if there required version isn't available?

Oh look, we’re consolidating again. My only gripe with it was that it wouldn’t directly run Typescript. Other than that it just felt a little ... antiquated.

Bun seems popular too, what would be reasons to choose it?

I wanted Deno to succeed to have a single standardised toolchain, but with Deno having its own APIs you'd effectively have to architect your application to be a "Deno app" and it created two different ecosystems. The best way to make your app portable would be to use the provided Node APIs, cutting a lot of the value from Deno.

> Why? Just strip the types bro, I know you can! Let me sign a deal with the devil!

> This restriction is philosophical rather than technical. I get it though. TypeScript is a Microsoft product. Opening that floodgate would pollute the entire ecosystem. Nobody wants more Microsoft.

The reason Node disallows this has nothing to do with TypeScript being owned by Microsoft, it's because there's no guarantee the TSConfig settings used in the library you're pulling in match the ones in your project. A mismatch would mean you would get type errors inside the library code (assuming you're doing some form of type-checking in your application, otherwise what's the point of even using TypeScript).

> No TypeScript packages mean I need to find the latest churnware slop to bundle my stuff.

The TypeScript compiler itself comes with everything you need for this. See: https://www.typescriptlang.org/tsconfig/#declaration

There are other advantages to bundling, but it's not strictly necessary if all you care about is publishing TS on NPM. Declaration files solve the problem by supplying the resolved types of the publicly exposed identifiers. Also has the added advantage of not locking out plain JS consumers.

If I remember correctly, using nvm on Debian to install the newest version of node silently appended lines to my bashrc. Friends don't silently append lines to my bashrc.

This is making me feel 1337 for being too lazy to even consider leaving Node. Same thing with Log4j vs System.out.println.

I _still_ prefer Deno over Node but I can't say that will be the reality in the near future. Once TypeScript _just works_ (instead of striping types) and the security improvements land by default, I'll probably switch back.

Alarms started ringing for me when they went for backwards support and focused heavily on that, when Bun was already on that route.

Sad but true.

node is a big part of what is wrong in the JS ecosystem, is literally the example of "LLMs actually write better code than the average programmer". Deno on the other hand is striving to make better decisions and try as much as they can to make the right contribution to the ecosystem. I can agree that lately as a company it has lost a bit of direction, but I would rather see NodeJS die than Deno.

Literally left when deno 2.9 is at its best place it has ever been.

Now just deno install everything and even desktop works amazingly well.

Upvoting because of meme reference.

I'm curious though: for people still choosing Deno today, what is the one thing Node still doesn't give you?

There are good reasons to stay positive about deno. Some of them: https://lobste.rs/s/a9kwzv/friendship_ended_with_deno_now_no...

I want to run my node project on Deno for performance testing, but Deno has problems when executing OpenSSL in a child process.

Why do either?

There are better, much better, choices.

A poster child for popularity!= quality

I have more than one friend.

If I had to guess Deno has found a nice little hosting business and is trying to be cash flow positive with a skeleton crew. It missed its venture scale opportunity. Similar fate to Meteor, which was purchased by a private equity group and is basically just a hosting business now.

Nothing says “mature ecosystem” like migrating to a different runtime every few years.

anything but bun?

> There is no reason to use the Deno runtime today.

LMAO okay bro.

With Deno I get TypeScript by default, security, a package manager that isn't riddled with nonsense and a dated UI, and I can compile my APIs to a single executable. No way am I going back to Node but then again, this ain't my blog post.

I wonder what the future of all three is mode bun and deno, their original goal has always been to be able to code in one language across frontend and backend, and typescript itself is a hell of a good language too.

But now that people seldom even look at the code, does it even matter? Our shared language now is English - across tests, frontend, backend, product briefs and design systems.

I have written a crap ton of node code before, because I liked it, but now I do everything in specialized stacks where each tech is chosen to best fit its environment. Backend - use Go, frontend - react/svelte/custom ,game simulation code - C#.

I just debate what would be best fit with an agent, do a few pilots to prove it and just go. Languages I’ve never coded in are super fast to execute - just insist on following best practice, modern conventions and do some spot checks against o(n) problems, architecture and parallelism - and it works, and vibe coded codebase with strict linting rules vastly outperforms fine tuned code in a shared language (node).

I honestly don’t see a bright future for them, and tbh I was surprised at Claude’s migration _to_ bun - why not just make the jump to something like ocamel that would let their agents have even more performance, context and linting tools, but I guess if they did it once the will do it again when they feel like it.

It's great that we now have 3 major JS server environments: Node.js, Deno and Bun. The competition keeps them all in check.

Although I was keen to get involved in Deno in the beginning and I'm a fan of Ryan Dahl, I just couldn't shake my preference for vanilla JavaScript; it was already the case before LLMs took over, but now even more so after LLMs. But I like that Deno is an option which users of my open source projects can use.

That said, Deno deserves the credit for making TypeScript as painless as possible. Juggling different Node.js and tsc versions and tsconfig versions was a major pain in the neck. I like how Deno forces a specific TypeScript version. None of that nonsense.

nvm? fnm? what is this? 1998 ?

get with the program and be awesome with mise

I never found Deno compelling enough compared to Node.

Bun was promising, but as long as they don't fix their http GET implementation to accept the request body, its broken for me.

Note: Many real world tools like Elasticsearch's GET /_search with a JSON query DSL is one example. It breaks Axios. Many custom infrastructure tools expect it.

Advertising as node compatible and having this breaking change is undesirable. Hope it gets fixed soon.

No Typescript

> Why? Just strip the types bro, I know you can!

Since when is it acceptable to make everyone else un-pollute his code?

I'm hoping now this is the end of this guys constant hate posting about Deno. What a negativity fountain.

Side note: I parse this domain name as "D-Bus hell", and I expect a rant about how Linux IPC is completely broken, then I remember that this is somebody's blog.

Title origin: https://knowyourmeme.com/memes/friendship-ended-with-mudasir

oh wait, Node.Js finally removed 'Black Lives Matter' banner?

You need better friends

Node is really good, and whatever thing that comes out outside of it will eventually be engulfed by it. Node is the safe bet :).

Love the site!

if you want to try a new runtime oam.js is focused on TypeScript & MCP servers.

"Just strip the types bro"

In my opinion TypeScript is not a feature. Why? 90% of the benefit of TypeScript can be obtained by using `foo({duck, clock})` pattern. And at 90% of the cost and time. TypeScript, like Java, is beneficial in situations where an error is catastrophic. That is not my situation nor the situation of what 90% of programmers?

So to the bro who wrote the otherwise interesting article I say "Just strip the types bro". You can do it!! You like it? You do it!

[Rant of course, but if you had wasted as much of your life writing types in Java you would probably rant as well. Recipe thinking sigh.]

> "what’s left are tweeting AI fantasies and vibe-coding Temu Cloudflare"

sick burn. can't say i disagree though.