And people do work at that intersection.
IMO Deno is the worst option of all new JS runtimes and taking on this fight kind of makes sense that way. If you can’t win mindshare, start a fight. I guess. (In my opinion they should have simply designed Deno to be NPM compatible, but here we are.)
`is:issue is:open npm` 467 open
https://github.com/denoland/deno/issues?q=is%3Aissue+is%3Aop...
`is:issue is:open label:bug npm` 199 open
https://github.com/denoland/deno/issues?q=is%3Aopen+is%3Aiss...
For the record, "NPM compat" probably does include many feature requests (legitimately), not just bugs.
However, the point that deno is npm compatible is still true, contrary to what you originally said.
Aside from that, Node compliance is a much larger ball of wax than simple NPM compliance, and as far as I know Deno is not there and will not be there for some time.
My gripe with Deno is the choice to hard-fork. That is core to the idea; so, we will disagree. No big deal. As a result of Deno's choice, people now have many runtimes to choose from: Bun, LLRT, and the one I have written on top of GraalJs, Elide. Many others, too.
Most of these runtimes shoot for as full NPM / Node compat as they can muster without intolerable contortions in the code. Why? Because a ton of software out there runs on NPM, or on Node APIs. Users think of server-side JavaScript and Node as the same thing -- this is not true, Node is both the "Node APIs" and the V8-based engine underneath it.
But this is exactly what I mean: for Deno to claim that Oracle does not "use" the JavaScript trademark requires a completely ignorant stance about technologies like GraalJs. Last we benched, Elide (on top of GraalJs) outperformed Deno by a wide margin. Oracle has invested years of engineering work into it. Enough that it outperforms Node (by a long shot) and Deno, and typically ties with Bun. So why does Deno get to say what happens with the trademark? It makes no sense to me.
I might even agree that Oracle should not own it or control it the way they do. I don't know. But I do know that Deno's demands are Node-centric, and the JavaScript ecosystem is simply way bigger than that.
Node compatibility is interesting because it's only useful until it's not. If all these other runtimes eat away enough at node's share, it won't make sense to be compatible with node anymore.
Just to finish the original discussion, as much as I love talking about the current state of js (heh) runtimes: the mention of graaljs supports deno's argument. Oracle, for whatever reason, used "js" rather than "JavaScript".
> Ryan has been outspoken about what he thinks he did wrong with Node and why he decided to make Deno
Yes, I explained that we disagree. Clearly he also feels he was wrong about Deno’s NPM choices since he reversed course and added NPM support. So Ryan agrees with me, I guess.
> If all these runtimes eat away enough at node’s share
WinterCG and other efforts are formalizing APIs that can be shared across runtimes. Which is great. Many of these APIs are at least informed by, if not outright standardized versions of, Node APIs. They are here to stay.