4 ms·

To be honest, Deno was cool in the past (I even somewhat promoted it on HN in some comments), but nowadays I'm disappointed in their lackluster approach to stab

To be honest, Deno was cool in the past (I even somewhat promoted it on HN in some comments), but nowadays I'm disappointed in their lackluster approach to stability and testing (specifically in Node compat). I recently hit multiple Node compatibility regressions in Deno that were hard to debug, and it doesn't help that they use Claude for everything now, from actual fixes to writing blog posts (even this one). For example, those two issues recently directly affected my projects: - https://github.com/denoland/deno/issues/34297 https://github.com/denoland/deno/issues/34297 - https://github.com/denoland/deno/issues/35289 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 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.

ch4s3 4mo ago
Time for someone to spin up Endo, but this time no cute ideas for real.
MoonWalk 4mo ago
Well if Node compatibility is your big deal then yeah, why not just use it? I started a new project on Deno to avoid the NPM mess. Node compatibility was a distraction for the product. I'm tired of everything depending on Node. Assuming that everybody uses it is lazy.
- Tiberium 4mo ago
  Because I wanted native TypeScript support which Node only gained relatively recently and only partially, plus the issues I showed are regressions - they worked fine in earlier Deno versions.
  - MoonWalk 4mo ago
    Makes sense.
- deleted 4mo ago
  [deleted]
- someguyiguess 4mo ago
  To be fair, you can't blame a person for thinking that a runtime created by the same guy who created Node would work with Node.
  - timw4mail 4mo ago
    But the point of Deno was to try to avoid pitfalls that became apparent in NodeJS, so some over-correction was bound to happen.
  - MoonWalk 4mo ago
    I never thought that, and I know very little about the space. In attempting to learn about the available options as fast as possible (along with TS and JS), I learned that the same guy launched a total re-do to address the shortcomings he realized through years of experience with his original product. I didn't imagine he could do that without breaking compatibility.
- pier25 4mo ago
  > Node compatibility was a distraction for the product I've gone back and forth on this point over the years. Yeah, Node compat has probably affected the rest of the product. I imagine at some point they (or their investors) freaked out because adoption wasn't happening. And the reality is it really doesn't matter if your product is better when nobody is using it. In retrospect I think it would have been a better decision to target Node compat from the start like Bun did. An impossible option at the time given Deno started trying to make something different from Node. Or maybe the problem was simply they couldn't afford low adoption after having investors on board.
  - MoonWalk 4mo ago
    Yep, it's hard to say what the right move was.
Recursing 4mo ago
node randomly broke production for us last week https://github.com/nodejs/node/issues/63989 https://github.com/nodejs/node/issues/63989 not sure it can be considered "stable and won't break things like this between minor releases"
- Tiberium 4mo ago
  Welp, guess the only option is to stay on some single version then and hope it doesn't get critical security issues...
  - Recursing 4mo ago
    That node release was to fix security issues...
dismalaf 4mo ago
Deno went downhill as soon as they introduced Node compatibility. It promised a better way of doing things, then stooped back down to Node fuckery.
bartlomieju 4mo ago
> Seems like the core of these issues was a Claude-coauthored PR: https://github.com/denoland/deno/pull/33208 https://github.com/denoland/deno/pull/33208 Disclaimer: I'm the author of the linked PR. Using AI here is not really at fault here - it was just a giant rewrite that replaced how we do `node:http` in Deno. Replacing the engine while driving is never easy and we did the best we could. While we have a lot of test coverage and we use tests directly from Node.js codebase, we just don't catch everything. We're constantly working on improving the situation and I'm sorry you hit a problem. I can assure you that we are fixing all Node compat bugs as quickly as possible.
- conartist6 4mo ago
  Of course the AI is not at fault, you were responsible as an engineer and you abdicated your responsibility
  - bartlomieju 4mo ago
    Sure, we also managed to close ~30 outstanding issues with this rewrite and set us up to reach ~90% node:http compatibility, so overall I consider it a success.
    - conartist6 4mo ago
      AI lets people be reaaaaaaally "productive" when leaning into entirely the wrong work. Deno has no future if all it wants to be is a clone of node, so it just seems to me like your work is to speed the collapse
      - undefined_void 4mo ago
        > A "node:http" regression caused by a PR fixing many of outstanding issue. Author explains and apologizes. > "Deno has no future" I think there may be other things bothering you? These comments aren't really productive and discourage maintainers to even continue replying. Disclaimer: I am a maintainer.

ch4s3 4mo ago

Time for someone to spin up Endo, but this time no cute ideas for real.

MoonWalk 4mo ago

Well if Node compatibility is your big deal then yeah, why not just use it? I started a new project on Deno to avoid the NPM mess. Node compatibility was a distraction for the product. I'm tired of everything depending on Node. Assuming that everybody uses it is lazy.

Tiberium 4mo ago
Because I wanted native TypeScript support which Node only gained relatively recently and only partially, plus the issues I showed are regressions - they worked fine in earlier Deno versions.
- MoonWalk 4mo ago
  Makes sense.
deleted 4mo ago
[deleted]
someguyiguess 4mo ago
To be fair, you can't blame a person for thinking that a runtime created by the same guy who created Node would work with Node.
- timw4mail 4mo ago
  But the point of Deno was to try to avoid pitfalls that became apparent in NodeJS, so some over-correction was bound to happen.
- MoonWalk 4mo ago
  I never thought that, and I know very little about the space. In attempting to learn about the available options as fast as possible (along with TS and JS), I learned that the same guy launched a total re-do to address the shortcomings he realized through years of experience with his original product. I didn't imagine he could do that without breaking compatibility.
pier25 4mo ago
> Node compatibility was a distraction for the product I've gone back and forth on this point over the years. Yeah, Node compat has probably affected the rest of the product. I imagine at some point they (or their investors) freaked out because adoption wasn't happening. And the reality is it really doesn't matter if your product is better when nobody is using it. In retrospect I think it would have been a better decision to target Node compat from the start like Bun did. An impossible option at the time given Deno started trying to make something different from Node. Or maybe the problem was simply they couldn't afford low adoption after having investors on board.
- MoonWalk 4mo ago
  Yep, it's hard to say what the right move was.

Recursing 4mo ago

node randomly broke production for us last week https://github.com/nodejs/node/issues/63989 https://github.com/nodejs/node/issues/63989 not sure it can be considered "stable and won't break things like this between minor releases"

Tiberium 4mo ago
Welp, guess the only option is to stay on some single version then and hope it doesn't get critical security issues...
- Recursing 4mo ago
  That node release was to fix security issues...

dismalaf 4mo ago

Deno went downhill as soon as they introduced Node compatibility. It promised a better way of doing things, then stooped back down to Node fuckery.

bartlomieju 4mo ago

> Seems like the core of these issues was a Claude-coauthored PR: https://github.com/denoland/deno/pull/33208 https://github.com/denoland/deno/pull/33208 Disclaimer: I'm the author of the linked PR. Using AI here is not really at fault here - it was just a giant rewrite that replaced how we do `node:http` in Deno. Replacing the engine while driving is never easy and we did the best we could. While we have a lot of test coverage and we use tests directly from Node.js codebase, we just don't catch everything. We're constantly working on improving the situation and I'm sorry you hit a problem. I can assure you that we are fixing all Node compat bugs as quickly as possible.

conartist6 4mo ago
Of course the AI is not at fault, you were responsible as an engineer and you abdicated your responsibility
- bartlomieju 4mo ago
  Sure, we also managed to close ~30 outstanding issues with this rewrite and set us up to reach ~90% node:http compatibility, so overall I consider it a success.
  - conartist6 4mo ago
    AI lets people be reaaaaaaally "productive" when leaning into entirely the wrong work. Deno has no future if all it wants to be is a clone of node, so it just seems to me like your work is to speed the collapse
    - undefined_void 4mo ago
      > A "node:http" regression caused by a PR fixing many of outstanding issue. Author explains and apologizes. > "Deno has no future" I think there may be other things bothering you? These comments aren't really productive and discourage maintainers to even continue replying. Disclaimer: I am a maintainer.