4 ms·

Fwiw, Deno can do this too: https://deno.com/manual@v1.33.3/tools/compiler https://deno.com/manual@v1.33.3/tools/compiler

petetnt 3y ago
And NodeJS too https://nodejs.org/api/single-executable-applications.html https://nodejs.org/api/single-executable-applications.html
- vdfs 3y ago
  There is also https://github.com/vercel/pkg https://github.com/vercel/pkg
  - JonathonW 3y ago
    Produces smaller binaries than bun too-- one of my applications, packaged by pkg for Windows, is about 70 MB (and actually does things; this isn't a Hello World). And it compresses well (must be including library sources in the binary as plain text); in a ZIP it's about 25 MB. Still not small, but I'm not sure what Bun's doing to come out 20 MB larger than an app with actual functionality and dependencies (this one has express, sqlite, passport, bcrypt, and a bunch of others-- essentially everything you'd need for a web service).
  - iansinnott 3y ago
    Perhaps it's specific to the applications i've built, but pkg has _ALWAYS_ given me issues. The ideal is the packaged code Just Works as if you ran it with node, and in my experience pkg does not deliver in that regard. Glad others are finding value there, but i wish it was more of a drop-in replacement for `node <script.js>`. Feels similar to `ts-node` (always having issues) and `tsx` (just works).
  - freeatnet 3y ago
    Does anyone know of a good comparison of these bundling methods?
- RedShift1 3y ago
  Experimental, so probably at least 5 years before it's considered "stable"
  - g_delgado14 3y ago
    As if bun isn't experimental
    - brundolf 3y ago
      Node moves pretty slow these days, I wouldn't be surprised if Bun's version gets stabilized before Node's
      - re-thc 3y ago
        Has it ever moved fast? It's been at a steady pace for a long time.
      - Aeolun 3y ago
        Which is probably a good thing. Node is starting to get firmly in the boring technology camp these days.
kbenson 3y ago
Yeah, I used Deno to build a simple URL switch case utility in late 2021 to handle sending different URLs to different browsers, and that was ~56MB compiled at the time. I don't know if it's changed in the base size since then, but if bun is resulting in 90MB binaries (as reported here), then Deno may yield a significant reduction in size (if it hasn't gotten much worse in that time).
- brundolf 3y ago
  I'm sure it'll get better (I'm sure both will); there's probably a lot of potential optimization to be done, dropping unused parts of the standard library and platform APIs and such (the way Deno loads most of the standard library as remote modules might actually be helping it here at the beginning), and Jarred is a stickler for hyper-optimization
  - kbenson 3y ago
    Interestingly, I'm sure a lot of people that want to compile to a binary would love an option that had trade-offs for the size even if it greatly hurt performance. For example, my case was ~100 lines of code not including the parseArgs and parseIni modules I used, and is meant to be run with an argument and then it exits with an action. If I could have chosen a dead simple and dumb JS interpreter without JIT but that was < 10MB, I would have. It might even have resulted in a faster runtime as well, since it wouldn't need to load nearly as much of the binary into memory, and also wouldn't need to initialize as many special purpose data structures to deal with advanced performance cases.

petetnt 3y ago

And NodeJS too https://nodejs.org/api/single-executable-applications.html https://nodejs.org/api/single-executable-applications.html

vdfs 3y ago
There is also https://github.com/vercel/pkg https://github.com/vercel/pkg
- JonathonW 3y ago
  Produces smaller binaries than bun too-- one of my applications, packaged by pkg for Windows, is about 70 MB (and actually does things; this isn't a Hello World). And it compresses well (must be including library sources in the binary as plain text); in a ZIP it's about 25 MB. Still not small, but I'm not sure what Bun's doing to come out 20 MB larger than an app with actual functionality and dependencies (this one has express, sqlite, passport, bcrypt, and a bunch of others-- essentially everything you'd need for a web service).
- iansinnott 3y ago
  Perhaps it's specific to the applications i've built, but pkg has _ALWAYS_ given me issues. The ideal is the packaged code Just Works as if you ran it with node, and in my experience pkg does not deliver in that regard. Glad others are finding value there, but i wish it was more of a drop-in replacement for `node <script.js>`. Feels similar to `ts-node` (always having issues) and `tsx` (just works).
- freeatnet 3y ago
  Does anyone know of a good comparison of these bundling methods?
RedShift1 3y ago
Experimental, so probably at least 5 years before it's considered "stable"
- g_delgado14 3y ago
  As if bun isn't experimental
  - brundolf 3y ago
    Node moves pretty slow these days, I wouldn't be surprised if Bun's version gets stabilized before Node's
    - re-thc 3y ago
      Has it ever moved fast? It's been at a steady pace for a long time.
    - Aeolun 3y ago
      Which is probably a good thing. Node is starting to get firmly in the boring technology camp these days.

kbenson 3y ago

Yeah, I used Deno to build a simple URL switch case utility in late 2021 to handle sending different URLs to different browsers, and that was ~56MB compiled at the time. I don't know if it's changed in the base size since then, but if bun is resulting in 90MB binaries (as reported here), then Deno may yield a significant reduction in size (if it hasn't gotten much worse in that time).

brundolf 3y ago
I'm sure it'll get better (I'm sure both will); there's probably a lot of potential optimization to be done, dropping unused parts of the standard library and platform APIs and such (the way Deno loads most of the standard library as remote modules might actually be helping it here at the beginning), and Jarred is a stickler for hyper-optimization
- kbenson 3y ago
  Interestingly, I'm sure a lot of people that want to compile to a binary would love an option that had trade-offs for the size even if it greatly hurt performance. For example, my case was ~100 lines of code not including the parseArgs and parseIni modules I used, and is meant to be run with an argument and then it exits with an action. If I could have chosen a dead simple and dumb JS interpreter without JIT but that was < 10MB, I would have. It might even have resulted in a faster runtime as well, since it wouldn't need to load nearly as much of the binary into memory, and also wouldn't need to initialize as many special purpose data structures to deal with advanced performance cases.