Python has lots of its own problems. Specifically, its type system, performance, and package management are all awful.
> Why would you ship with node_modules? ALWAYS use npm install. If you don't trust npm, the use something like CodeArtifact, but oh my, don't compress dependencies.
You've certainly convinced me that Deno's single binary deployment is a useful feature.
As a frontend dev, I use node tooling every day that has nothing to do with server code.
> Python is much better as 'general purpose'
Node is just fine for general purpose. I use it for shell scripting without any difficulty. Working with async in JS is a dream compared to most languages, and although I rarely use dependencies, when you need `em, node has a great ecosystem.
That said, I am 100% sold on Deno. Secure by default might not matter for server code that is going to have a couple of instances of it running, but the need to enable explicit flags for insecure APIs means that people who don't know how (or care) to read the code can use your program knowing that it literally can't access their filesystem or whatever.
Beyond that, Deno uses Promises for async. Node was built before promises and many APIs rely on callbacks vs promises. It also has the ability to compile to an executable.
But the number one for me is that the APIs mirror the browser APIs. This makes it much easier to extend frontend knowledge to building my own tooling.
3. I have a few internal CLIs for use in scenarios that don't have npm available by default. It's very nice to be able to ship a single runtime and not have the folks downstream from me need to worry about node version + npm version + package installs from untrusty sources, etc. I can do that work so they don't need to, and give them a single runtime. I happen to not use Deno at the moment, but it's an appealing feature. Python has a comparable problem: I run into issues with some frequency around python versions and python environments. There are solutions, yes, but there are also scenarios where you want to bring your own dependencies.
I haven't used CodeArtifact, but is it something you can deploy on-premise?
You could only ship the source code and package-lock file and run `npm ci` or `npm install --production`, which would only install dependencies you're actually using on your production machine, rather than including testing libraries or build frameworks.
Even better, you could set up a build and take advantage of tree-shaking (to some extent at least), then ship less code in fewer files.