Hacker News Reader

Comment by dingdingdang | Hacker News Reader

Would love to see the compile situation fixed - the generated executables are ~90MB+ at this stage and do now allow compression without erroring out. Deploying ala Golang is not feasible at that level but could well be down the line if this dev branch is picked up again!

The exe output grew from from ~50MB to plus ~90MB from 2021 to 2024: https://github.com/denoland/deno/discussions/9811 which mean Deno is worse than Node.js's pkg solution by a decent margin.

View on HN

Hi, Bartek from the Deno team here. We are actively looking into improving this situation and from initial investigations we were able to shave off roughly 40% of the baseline size, with more improvements possible in the future. Stay tuned for upcoming releases.

Tuned I am, happy to hear this is getting attention. Improvements in this domain would also enable Deno to be a more serious contender in the App space opened up via https://github.com/webui-dev/deno-webui and others.

Currently the generated binary is not static anyway, so you still need some parts of the system installed to run code. To be more precise, you can't use a "from scratch" container image base, but need to use something that at the very least has libgcc installed, such as the distroless "cc" image (gcr.io/distroless/cc).

I'm not sure using deno compile as a way of deploying to a controlled environment has much benefit anyway. Unlike some other languages/runtimes, only a single system dependency is really needed (a new-enough deno installation) to run your code

In my view, deno compile is more about shipping command line tools to people with all sorts of personal environments (which may not have deno at all)

I've been really happy with using Deno as a general scripting runtime... A shebang at the top and external dependencies are loaded to a shared path on run.

I do wish there was support for Linux distributions based on musl (Alpine) directly for smaller containers.

In general I like the Deno approach better than Node. Would be cool to see the UI tooling flushed out. A material or fluent based component library where Deno can be used like Flutter would be very cool indeed.

I'm not sure what your requirements are, but I've had a good amount of success with converting Node.js libraries to native libraries by embedding a CommonJS module into the binary, then running the actual code through QuickJS. Much smaller binaries.

If you really are pressed for space, you could use upx, or store 7z compressed code and embed the 7z library to decompress before passing it along to QuickJS.

Here's a proof of concept: https://github.com/ijustlovemath/jescx

Isn't QuickJS order(s) of magnitude slower than V8? That doesn't seem like a practical tradeoff to make outside of embedded.

Like I said, I wasn't sure of their requirements. I can say QuickJS is orders of magnitude easier to embed and understand than V8, which is why I adopted it for my use case.

Thanks for sharing that info!

Would like to see more runtime independent JS project such Hono. Although I'm not sure if it supports QuickJS.

Depends on what you are doing and what your needs are .. the gp comment was about the size.

> Deploying ala Golang is not feasible at that level but could well be down the line if this dev branch is picked up again!

While I agree with you that it's not optimal and should get fixed, 90MB doesn't sounds like it can stop you from deploying it either.

It adds up though... Personally, I'm fine with Deno in the path and scripts with a shebang in practice.

If reach one of my scripts was a separate build output from Deno that would be several GB of space.

When I download a modern game it's like 700GB so I donno why people complain about 100mb self contained deploys for javascript. Most of it is the international libraries anyway so.

I find it pretty ridicolous since I go to a website today and it's at least 15MB each time I refresh but 100MB on the server is a problem? Dude cmon.

So the fact that everything around is poorly made, forbids him from whining that a certain solution is as bad as everything else? Shouldn't we criticize and point out stuff that is bad, no matter whether it's as bad as something else? It's because of attitude like yours that we get 15mb of javascript on every website, 500gb games and UIs that take seconds to load.

Well my point is that it isn't that bad and there's a reason for it being ~100mb. You can throw out the Intl stuff and remove a large portion of that for example.

Modern games aren't 700Gb, there are a very few very large games. One of them is large on purpose to make to delete other games.

Updates for games are large because they aren't "just updated files", but a giant blob that can't be rearranged since it's optimized for loading order later.

Giant self-contained deploys like that are bad because their use case is CLI/GUI tools shipped to the end user. To give you context: my /usr/bin is ~900 binaries and total size is 109mb.

100MB at 1Gbps is ~0.8s to load. This especially sucks for FaaS and CI/CDs. This makes it difficult to use for on-demand use cases that are latency sensitive.

That and that's likely 100MB that's going to be competing for memory now* , in FaaS environments especially that's a ton of resources and you increase latency to load that especially over network storage. This also inflates container sizes and just becomes a pain in general.

*Server environments you often don't want to be using swap, and the OS will likely consider it high priority anyway.

I could only agree with you if you have a single monolithic server, don't use containers, don't need to distribute it to others, and don't frequently need to run a CI/CD pipeline. Only then are there not a ton of downsides to a 10mb vs 100mb executable.

> When I download a modern game it's like 700GB so I donno why people complain about 100mb self contained deploys for javascript.

People have been complaining about game sizes for years. "You complain about a 100GB game, I don't know why you also complain about a 100mb self-executable for a javascript runtime" doesn't really make sense.

Could be worse, could be Java. At least in terms of container size, cold start times and overhead at runtime. And I know there are options for AOT, etc. that are all more complex to configure than Deno build.

You download it to you game rig, not some cloud solution with limited resources to be paid for. Plus you may want to have more than one instance of service running.

Pretty much all cloud services offers way more than that for free and besides, maybe don't use javascript if 100mb is such big of a deal?

I'm not using js, but that's not the point of a discussion.

And we were not talking about js, we were talking about Deno specifically. And about binary growing year to year notably.

>Pretty much all cloud services offers way more than that for free

More than what? The question is always about difference in %. The number of services\instances can grow faster than you can rewrite your conde in go\c++\rust of whatever (not to mention you will have to hire people for the task). And all of a sudden this x3-x4 difference matters.

This is whataboutism. Different sizes are acceptable for different people based on context. I worry about 10s of kilobytes for things I work on for instance.

Yes but there is a reason for it being 100mb. You get a self-contained app where you can get to write in javascript. You don't have to spend 100x the time in order to get the same app working in Rust.

If size is such a big deal, then don't use Deno, Node or Bun.

My issue is that most people that are working in restricted environments would never touch javascript since it's not well suited for those kinds of environments. People that complain tend to be haters that just want something to hate upon.

It used to be about php, now it's about javascript.

Your argument seems to be that those 100 Mb include the necessary libraries. The problem with this assertion is that much richer runtimes don't require that much. For example, a .NET Core console app published as self-contained is ~65 Mb, and it comes with more libraries than Deno.

Well what is the size of .NET that I assume you need installed?

You don't - that's the size of a completely self-contained binary, with .NET effectively baked in. A "hello world" .NET app that uses external runtime would be measured in kilobytes.

There are size limits when deploying on serverless or edge infrastructure so developers have to care about that. The providers also typically charge by compute seconds * memory consumed so a larger executable costs real money as well.

The compiled option isn’t intended for serverless or edge uses, you just deploy the source files and the platform takes over.

Some serverless use cases work like you say, but Docker-based options such as AWS ECS, Docker-based Lambda functions, or Kubernetes would all commonly make use of compiled options

No, you won't use compiled option in k8s or any other container based deployment.

You would use deno as base layer, your dependencies in another layer, your code is in the last layer.

Reply on news.ycombinator.com