I'm not pathologizing deno, and I have (and will continue to) consistently tried to migrate my projects to deno, first from npm, then from pnpm, and now from bun. But every single time I've tried, there has been some kind of stupid "edge case", "simple fix" issue like this that stops me in my tracks. It's not a huge deal, but the simple fact is, when I run the project using bun, it runs. When I try it using deno, it doesn't. That has been a consistent pattern every single time I've tried. Last time, deno blew up because it wasn't able to work out the IndexedDB api calls I was using without some kind of bridge/shim/environment config. These are terribly minor issues, but it's the lack of care for the details that really sours me on this stuff.

Obviously, deno should have used the version of vite that bun did which would have worked with the version of node on this machine. But even barring that, they could have dropped a little note around the instructions that says "if some packages need updates, you can run X command to do that". Even that would have allowed me to just move on, instead of forcing me to query the solution and hope for the best. Like I said, none of this is damning. It's just the exact kind of friction that prevents immediate adoption. At least for me.

IMO, Deno has always been more methodical, more focused (maybe too focused?) on standards. But now the Deno team is on the right track: using Claude extensively to improve the node.js compat which was absolutely herculean if not impossible before AI. [+]

On the other hand, Bun has always played a bit fast and loose, chasing metrics at the cost of stability. Access to abundant AI has sent that project off the rails.

Disclaimer: Former Deno engineer - I'm obviously going to have some biases. All IMO of course, but if you ask me I'd still bet on Deno in the long term, and I personally still use it for any .ts projects.

[+] There might be a dozen people in the world that know how sensitive and subtle the timing and ordering in the JS event loop is and how meticulous just this single part needs to be for major node.js projects not to completely crap themselves.

My city builder game, Microlandia[1], runs on Deno. The game's graphics and UI is a Three.js/React app, but the guts of the game are in a "sidecar" process that is a `deno compile` typescript executable.

On Mac, there's a Tauri shell that runs both client and server, and for Linux and Windows we use Electron, (Tauri proved to be quite problematic except when in macOS)

Why on earth did I choose this cursed stack instead of a "proper" game engine? Well,

Turns out developing the simulation in typescript with a performant sqlite driver hot reloads very fast and with a light code editor and my browser open on a second window I see the stuff updating live as I make it.

Deno has a good VSCode extension with test helpers and a fast language server. WebGPU is good enough for me to write any cool shader I can think of and I don't miss any capability of a game engine.

More importantly, not using Unity/Unreal brought back to me the joy of game development that I had lost due to and horrendous UI-driven workflow that takes me back to Macromedia Flash (yes, I am that old). Oh, and the licensing.

And I know I could switch to Bun with small changes in code but Deno has never got in my way. Maybe it's because I avoid using libraries at all costs (and don't need much).

Also, Typescript/React is such an amazing language for building a complex tycoon/simulation type of game that deals with a lot of data and displays it. Anyone who's worked on Unity knows it's the dark ages for UI over there.

I'm unsure if i'll port the game to Deno Desktop anytime soon but if I start a game again I will use this stack again, as my game engine, this time without Electron or Tauri.

1. https://microlandia.city

For example, those two issues recently directly affected my projects:

- https://github.com/denoland/deno/issues/34297

- https://github.com/denoland/deno/issues/35289

Seems like the core of these issues was a Claude-coauthored PR: https://github.com/denoland/deno/pull/33208

I think I'll probably just go back to normal Node because it's stable and won't break things like this between minor releases, plus it's not full-on vibe-developed like Deno and Bun.

P.S.: Deno does genuinely have good parts: built-in type checking, LSP server, formatter with sane defaults, and so on. I'm just very disappointed that they seem to be focusing less on the actual core runtime.

Ryan Dahl is assuredly a poor steward of open source software if these are the results. Node is popular because of the massive, inclusive community behind it; not because of a few rock star individuals, but for the VC mindset it's much easier to control an individual programmer than a community of them.

Only wonders are what other communities VC will try to rat fuck next, how fast do we think Evan You will speed run this exact same arc (which has already happened a dozen times in lived memory), and why does Bryan Cantrill feel like the only smart tech executive that doesn't fall into these traps?