Nexe: Create a single executable out of your Node.js apps | Hacker News Reader

Nexe: Create a single executable out of your Node.js apps

github.com

60 pointsthunderbong19 comments

I've personally used `nexe` before and ended up swapping it out for Vercel's `pkg`[1]. `pkg` worked better with building ARM binaries and with less gotchas with multiplatform builds, in my experience.

[1]: https://github.com/vercel/pkg

The Node world has many tools to solve this problem. The docs for caxa have the best comparison between them I've seen https://github.com/leafac/caxa#prior-art .

Nexe has been around for a really long time. There have been several approaches to bundling Node apps into single executables. Native Addons always presented a problem. Same with dynamic imports. With better bundlers like weppack, improvements by Electron in cross platform code signing, and Vercel’s approach to executable bundling, I think Nexe has mostly become a second tier tool, right?

I've used nexe once or twice for some use cases. It worked reasonably well. If I remember, my one complaint was with the output binary size. I was using this circa late 2015 though, so I suspect there's been substantial improvement in that regard.

Would be cool to provide exe-it,bin-it as a service. Where your exe file is simply doing a network tcp request. The app is simply a service somewhere listening to those incoming requests. Can be anything. Not only node.

(Nexe maintainer here) The project I made before maintaining nexe did this (sort of, from the browser) https://calebboyd.github.io/xbin/

Tried nexe but had better experiences with pkg.

Not taking away from the work here I think it’s very cool, but this feels a little off. This has been around since Day 1 if you are building your service applications in C++, Rust, Zig, Swift, or Kotlin. Essentially because those languages are compiled whereas most node apps are transpiled. Someone correct me if I’m mistaken.

The difference is that JavaScript is an interpreted language, rather than a compiled language.

Interpreted languages are distributed as source code, and an interpreter evaluates each line of code to transform it into machine language for execution on the CPU. This allows the same code to run on any CPU for which an interpreter is available.

Compiled language source is transformed into machine language once, at compile time, using a compiler that understands how to turn the source code into machine language for a given environment. Once it's been compiled it generally will only work on the CPU/OS for which it was compiled. If you're going to distribute the work, you will have to compile many different versions.

There are volumes written on the differences and advantages of each method. JavaScript was created as an interpreted language so that developers could write code which can be executed on any browser with a JavaScript interpreter- important for a language that is used on web pages which can be viewed on a very wide variety of devices and machine architectures.

https://en.wikipedia.org/wiki/Interpreter_(computing)

Interpreted languages don't necessarily have to be distributed as source code, as a few of them support being compiled into byte code, which can then be distributed and interpreted.

There is no such thing like an interpreted/compiled language - even with some kind of eval functionality. It's implementations that work as interpreters or compilers. Also, a compiler doesn't necessarily emit machine code. It could also emit byte code that is later on intepreted or compiled to something else.

So computer science is wrong and you are right?

No they're right - languages can be implemented with an interpreter or with a compiler or with something in between. Some require at least something in between as they have dynamic code execution. Saying 'interpreted language' is just short for 'a language that is usually interpreted'.

But the difference between compiled vs interpreted languages is correct as stated.

The point is no language is inherently compiled - people just choose to compile it. Any language that can be compiled can also be interpreted.

No. The language per se is neither interpreted nor compiled.

It's a shortcut that often isn't really useful. Also the statement about compiled languages is wrong the way it's written.

The OP states:

1. Interpreted language (whatever that is) are necessarily distributed as source code and an interpreter evaluates the source code line by line.

2. Compiled languages (whatever that is) are not distributed as source code and they are necessarily transformed to machine code.

Both statements are wrong as they are.

This is like bundling the Python interpreter with a Python script into a single executable file that runs without needing Python locally installed.

Basically—but at the same time, for an end user sometimes it’s nice just running a binary and not needing to be like “alright so in order to use this application I’m going to need to install pyenv because if I install another Python app maybe it’ll blow up my other Python apps” or something along those lines. I realize there are solutions to this, but for the average person just wanting to ship a utility without much headache, self contained is pretty compelling.

Reply on news.ycombinator.com