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.

Makes sense.

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

Yep, it's hard to say what the right move was.

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.

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.

But the point of Deno was to try to avoid pitfalls that became apparent in NodeJS, so some over-correction was bound to happen.