6 ms·

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

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 https://github.com/denoland/deno/discussions/9811 which mean Deno is worse than Node.js's pkg solution by a decent margin.

ijustlovemath 3y ago
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 https://github.com/ijustlovemath/jescx
- dns_snek 3y ago
  Isn't QuickJS order(s) of magnitude slower than V8? That doesn't seem like a practical tradeoff to make outside of embedded.
  - ijustlovemath 3y ago
    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.
    - factormeta 3y ago
      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.
  - tracker1 3y ago
    Depends on what you are doing and what your needs are .. the gp comment was about the size.
littlestymaar 3y ago
> 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.
- tracker1 3y ago
  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.
ecmascript 3y ago
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.
- atraac 3y ago
  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.
  - ecmascript 3y ago
    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.
- surajrmal 3y ago
  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.
  - ecmascript 3y ago
    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.
brundolf 3y ago
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)
- tracker1 3y ago
  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.
bartlomieju 3y ago
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.
- dingdingdang 3y ago
  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 https://github.com/webui-dev/deno-webui and others.
wvh 3y ago
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).

ijustlovemath 3y ago

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 https://github.com/ijustlovemath/jescx

dns_snek 3y ago
Isn't QuickJS order(s) of magnitude slower than V8? That doesn't seem like a practical tradeoff to make outside of embedded.
- ijustlovemath 3y ago
  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.
  - factormeta 3y ago
    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.
- tracker1 3y ago
  Depends on what you are doing and what your needs are .. the gp comment was about the size.

littlestymaar 3y ago

> 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.

tracker1 3y ago
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.

ecmascript 3y ago

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.

atraac 3y ago
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.
- ecmascript 3y ago
  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.
surajrmal 3y ago
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.
- ecmascript 3y ago
  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.

brundolf 3y ago

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)

tracker1 3y ago
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.

bartlomieju 3y ago

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.

dingdingdang 3y ago
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 https://github.com/webui-dev/deno-webui and others.

wvh 3y ago

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).