[yashap]

Even server side, not everyone uses Docker. If you’re deploying to EC2, in house hardware, whatever, a single executable is simpler. And even if you’re building a Docker image, building the image itself is still a bit simpler - just pop the executable in there, and have the Docker entry point execute it, that’s it.

Then obviously for CLI tools, this is SUPER nice.

[205g0]

Yes and no, these are amenities but they are really small and IDK if they justify hiding/abstracting way an import build step.

> Even server side, not everyone uses Docker.

IDK, tried to find alternatives the last years but for a bit more sophisticated app you can't ignore images and container orchestrators like k8s. And latter is still easier than anything I've seen and has by far the biggest ecosystem. If I want to host some minimal app, I just push an SSG to netlify/surge/vercel, it's not an integrated build step which makes my life easier.

> just pop the executable in there

Otherwise you would just need one more line in your build file (npm install).

> Then obviously for CLI tools, this is SUPER nice

Also, yes no, Deno "binaries" have huge file sizes compared to an npm install -g and rarely used CLI tools can be fired off with npx, so which problem is exactly solved? That I can offer CLI tools to folks who won't have node installed? Then I rather write my CLI tool in Go and offer an appropriate package size.

I welcome competition and hence Deno but think this feature doesn't fulfill any (relevant) use case. Only beginners who struggle with the build step (which can indeed get hairy) profit from this design decision but a bit more advanced users will miss the control they had before.

[yashap]

I like K8s too, especially for a service oriented architecture, but there’s tonnes of other deployment targets out there. I’d bet the overall percentage of server side software running on K8s is in the single digits, thought that’s a pure wild ass guess. Hours ago I just finished debugging an outage where requests to one K8s service, through K8s ingress, slowed down 10x after an insignificant deploy, and then we cycled the pods (without changing the code) and it sped up again. No idea why - K8s is complex, and many ppl choose not to take on that complexity. TONNES of people like being able to deploy a single executable to their servers, it’s part of Go’s popularity, part of the popularity of fat jars in Java land (and those still need a JVM!), etc.

As for CLIs, the Deno executable overhead is about 47 MBs. Not nothing, but also ... that’s like a few extra seconds of download time for the tool, and insignificant disk space when people have hundreds of GBs on their laptops. If I’m writing some sort of command line tool, the tool being 50 MBs bigger probably does nothing to hurt adoption. But it having zero external dependencies WILL help adoption, vs. npx and screwing around with proper node versions and whatnot.