You are still not thinking of it as a browser. Consider a use case where Deno is the client, not the server. One example is a replacement for piping random curls into bash:
I mean that's a neat feature and all, but my primary use for Javascript/Typescript is to write frontend and backend code using the tens of millions of lines of useful library code available in the existing JS/npm ecosystem.
It's strange to me that Deno seems as if it could decide overnight to be a drop-in replacement, but there's deliberate friction designed into the system here to try and push people away from node_modules? The upshot of that choice is that I'm unlikely to switch to Deno until that's changed (and I suspect that's the case for many other companies as well).
I love the direction the node compatibility layer is going in though https://deno.land/std@0.80.0/node, now I just wish it supported normal import statements from node_modules (not just require()). I'm quite excited about Deno overall, just waiting for it to get to drop-in point.
> It's strange to me that Deno seems as if it could decide overnight to be a drop-in replacement
The 1.0 announcement post the team mentioned:
> For some applications Deno may be a good choice today, for others not yet. It will depend on the requirements. We want to be transparent about these limitations to help people make informed decisions when considering to use Deno.
and:
> Over time, we expect Deno to be able to run more and more Node programs out-of-the-box.
I don't think they've ever claimed to be an immediate drop-in replacement.
I know I sound like a broken record at this point, but wouldn't it be helpful if Deno just built something like this in automatically to make those import maps given a lockfile:
This way you'd get both the benefits of web standards compliance with the generated explicit import maps, and backward compatibility and ease-of-migration for npm/yarn users.
deno run --allow-write=~/.myapp https://myapp.io/install.ts
It works quite well as secure scripting runtime.