[HN Gopher] Nexe: Create a single executable out of your Node.js...
___________________________________________________________________
Nexe: Create a single executable out of your Node.js apps
Author : thunderbong
Score : 44 points
Date : 2022-04-18 09:51 UTC (13 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pixel_tracing wrote:
| 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.
| evan_ wrote:
| 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)
| stewbrew wrote:
| 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.
| encryptluks2 wrote:
| So computer science is wrong and you are right?
| chrisseaton wrote:
| 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'.
| encryptluks2 wrote:
| But the difference between compiled vs interpreted
| languages is correct as stated.
| chrisseaton wrote:
| The point is no language is inherently compiled - people
| just choose to compile it. Any language that can be
| compiled can also be interpreted.
| heavyset_go wrote:
| 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.
| tenebrisalietum wrote:
| This is like bundling the Python interpreter with a Python
| script into a single executable file that runs without needing
| Python locally installed.
| SOLAR_FIELDS wrote:
| 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.
| ruffrey wrote:
| 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?
| ISV_Damocles wrote:
| 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
| holoduke wrote:
| 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.
| calebboyd wrote:
| (Nexe maintainer here) The project I made before maintaining
| nexe did this (sort of, from the browser)
| https://calebboyd.github.io/xbin/
| daxelrod wrote:
| 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 .
___________________________________________________________________
(page generated 2022-04-18 23:01 UTC)