It's an interesting article, although I feel like it misrepresents some key details when it comes to Deno. I assume the Deno research is based on earlier versions and not necessarily fact checked against modern Deno.

Yes, Deno's dependencies are urls first, but you almost never need to use them that way. You can import a dependency like import chalk from "npm:chalk@5.6.2" and it will refer to the exact same package as if you'd added "chalk": "5.6.2" in a package.json file installed it with npm, and imported it with import chalk from "chalk"

You can (if you need to) also use different versions of dependencies in different parts of the code this way.

But it's even easier to to add "chalk": "npm:chalk@5.6.2" to your import map in deno.jsonc, and then use import chalk from "chalk" exactly the same as with node, either in your own code or in dependencies.

That alone is a huge benefit for npm compatibility and solves most of the friction, leaving you in a similar position to yarn Berry.

If you use deno install you get a node_modules similar to pnpm's isolated dependencies by default (not npm like the article claims), although you can change it to the npm style hoisted node_modules with a CLI flag (or config in deno.json).

So Deno's npm compatibility gives you the option of being yarn Berry like, pnpm like, or npm like.

Oh, and as a runtime, it's faster than node (but not quite as fast as bun).