Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Looks like you could make a standalone executable with Bun and/or Deno:

https://bun.sh/docs/bundler/executables

https://docs.deno.com/runtime/reference/cli/compile/

Note, I haven't checked that this actually works, although if it's straightforward Node code without any weird extensions it should work in Bun at least. I'd be curious to see how the exe size compares to Go and Rust!



You can also do this natively with Node, since v18: https://nodejs.org/api/single-executable-applications.html#s...


I was going to say the same thing, but they couldn’t resist turning the project into a mess of build scripts that hop around all over the place manually executing node.


Oh, man!

I guess it needs to start various processes for the MCP servers and whatnot? Just spawning another Node is the easy way to do that, but a bit annoying, yeah.


A Bun "hello world" is 58Mb

Claude also requires npm, FWIW.


That is point not a line. An extra 2MB of source is probably a 60MB executable, as you are measuring the runtime size. Two "hello worlds" are 116MB? Who measures executables in Megabits?


> A Bun "hello world" is 58Mb

I've forgotten how to count that low.


What's a typical Go static binary size these days? Googling around, I'm seeing wildly different answers -- I think a lot of them are outdated.


It depends a lot on what the executable does. I don’t know the hello world size, but anecdotally I remember seeing several go binaries in the single digit megabyte range. I know the code size is somewhat larger than one might expect because go keeps some type info around for reflection whether you use it or not.


Ah, good point. I was just wondering about the fixed overhead of the runtime system -- mainly the garbage collector, I assume.


The Golang runtime is big enough by itself that it makes a real difference from some WASM applications, and people are using Rust instead purely because of that.


Yeah, this just seems like a pain in the ass that could've been easily avoided.


From my perspective, I'm totally happy to use pnpm to install and manage this. Even if it were a native tool, NPM might be a decent distribution mechanism (see e.g. esbuild).

Obviously everybody's requirements differ, but Node seems like a pretty reasonable platform for this.


Also throwing Volta (written in Rust, because of course it is) into the ring. It's the uv of the Node world.


It feels like you are creating a considerable fraction of the pain by taking offense with simply using npm.


As a longtime user of NPM but overall fan of JS and TS and even its runtimes, NPM is a dumpster fire and forcing end users to use it is brittle, lazy, and hostile. A small set of dependencies will easily result in thousands (if not tens of thousands) of transitive dependency files being installed.

If you have to run end point protection that will blast your CPU with load and it makes moving or even deleting that folder needlessly slow. It also makes the hosting burden of NPM (nusers) who must all install dependencies instead of (nCI instances), which isn't very nice to our hosts. Dealing with that once during your build phase and then packaging that mess up is the nicer way to go about distributing things depending on NPM to end users.


I ran the npm install command in their readme, it took a few seconds, then it worked. Subsequent runs don't have to redownload stuff. It's 127MB, which is big for an executable but not a real problem. Where is the painful part?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: