- The first thing on the "features" list should be something that other compilers cannot do. Esthetics (maybe just say "DX"?) is a nice to have - sometimes VERY nice to have - but should not be positioned as the most important item.
As the original post says the alternatives have poor ESM support - that's a good differentiator.
- Even though ES Modules are part of the ECMAScript standard, having a header stating "(Partial) Support for ECMAScript"- to me, at least - indicates the project does not support base JS features, not that ESM imports have problems. Maybe say "improved ESM support"?
- Docs seem a little bare. For example, the Usage section says:
# Preinstall Node.js on the target machine
astra install
Which machine is the "target" machine? I would assume, in the context of compiling, that the target would be the machine you are compiling for... but installing software remotely seems out of scope. Does it install it locally, or swap the bundled installation in the .exe?
Also, no mention of binary limitations in actual docs, despite mention in post.
Hopefully this does not come off as discouraging - this looks like a good project.
Thanks for the feedback! I'm constantly working on the project. It's hard to do bc node sea is still an experimental feaurte and there's no much documentation about it, and i want to make it highest quality possible. And it's my first open-source project what's actually getting attention.
I would really appreciate any help with this project!
This is not a compiler. It is doing no program translation. No register allocation. No parsing. No linking. It in no way resembles a compiler. Not every program that produces an executable file is a compiler just because some programs you may have heard of, like gcc, are in fact compilers.
I wish the JS universe would stop inventing new and wrong names for things.
(That said, this thing is at least using postject for actual insertion of the payload blob into the target executable, and based on its README, postjecth as the good taste to embed data as PE/ELF/Mach-O sections instead (as Bun does) of just YOLOing the attachment with cat.)
I totally understand your point - Astra doesn’t do register allocation or full parsing, so strictly speaking, it’s not a compiler in the traditional sense.
I used the term "compiler" because for many developers, it’s strongly associated with "turning source code into a single binary."
That’s what Astra does at a practical level - even if it's technically just bundling and embedding into a node executable using SEA and postject.
This whole thread was uncalled for honestly. It takes source, it makes an exe, that meets the definition for compiler to me. Your pedantry is not useful.
To understand the underlying architecture- is my understanding correct that this runs esbuild to bundle then bundles that with node runtime and creates a binary that executes "node index.js"?
Very interesting. The readme notes "Different than the others - Astra is a new approach to compiling JavaScript/TypeScript applications. It uses a different method than other compilers like pkg or nexe." but never really explains what the difference is. Is it just that the code is run through esbuild before the SEA step or is there some other "magic sauce"?
Yes it's just esbuild and SEA BUT that's actually the point.
SEA is officialy supported by node.js and it constantly improves.
Remember pkg and nexe supports only the older versions of node.js (~14) and astra supports the latest ones.
So in a way, the "magic sauce" it that it doesn't try to do anything fancy.
I made astra beacuse i needed to compile js to exe for latest versions.
I wanted astra to be simple, built on official tools, and be future-proof.
You probably want to put that information in your README.md, because there is barely any information in the readme, and the docs look to be a placeholder atm =)
This is really interesting, got it up and running very quickly.
I'm not sure what the use case is and it doesn't auto-load chromium with its own web server from what I can tell. Is it just for creating javascript CLI utilities?
Thanks for the feedback! You're right - Astra is technically a bundler-to-executable tool, not a source-level compiler like Babel or TypeScript.
I called it a “compiler” in the sense that it transforms a JS project into a standalone .exe, similar to how tools like pkg or nexe are often described. That said, I’ll consider clarifying that in the description to avoid confusion. Appreciate the comment!
Sometimes the term "packager" is used instead of "bundler". Honestly though, "compiler" is the term most likely to cause any confusion. Even if one is not familiar with packagers/bundlers "js to exe ${unknown phrase}" still conveys things more clearly than "js to exe ${misleading phrase}".
> Average exe is ~70-80MB (depends on your code) so it's lighter than most compilers
I know it's JS not actually a compiler but a bundler that just packs node in with your code, but I still had a nice laugh at 80mb being light. I suppose that's where the overton window is in a world of 1gb node_modules folders.
I wish there was a middle ground between this sort of thing and QuickJS (which is actually light, but has a lot of rough edges when it comes to its filesystem and network interfaces)
Bun also supports this out of the box, and the overhead is likely a bit less (reportedly 30-40MB for a single `console.log` call with no further dependencies - I didn't verify that myself though).
I suspect a large portion of the executable size in both cases is for the ICU library for localization support (Note QuickJS has its own, much smaller l10n library.) It's possible to download a Node binary without ICU, which could trim ~30MB.
> reportedly 30-40MB for a single `console.log` call with no further dependencies - I didn't verify that myself though
I got a 110 MB exe for "console.log('test')" in "test.ts" using "bun build .\test.ts --compile --outfile test.exe". Pretty compressible though, on the order of 1/4th the size pretty easily. Considering it has zstd compression for sourcemaps that'd be an interesting option to add in.
The amount of functionality an application provides should be the benchmark for the size rather than one's available disk space. I'm sitting on 20TB+ of available storage and anything over 1MB for a simple "Hello World" is excessive.
Cheap laptops with a Celeron, 4 GB RAM, and 64 GB storage have been incredibly popular since that formula became popular a handful of years ago. As are base-model MacBook Airs.
Well, if we already could make something in 1 MB, why do we want to achieve the same thing with 100 MB? It is as if there is a mentality of "somehow the higher the size the better".
Looks like a good start. A few notes:
- The first thing on the "features" list should be something that other compilers cannot do. Esthetics (maybe just say "DX"?) is a nice to have - sometimes VERY nice to have - but should not be positioned as the most important item.
As the original post says the alternatives have poor ESM support - that's a good differentiator.
- Even though ES Modules are part of the ECMAScript standard, having a header stating "(Partial) Support for ECMAScript"- to me, at least - indicates the project does not support base JS features, not that ESM imports have problems. Maybe say "improved ESM support"?
- Docs seem a little bare. For example, the Usage section says:
Which machine is the "target" machine? I would assume, in the context of compiling, that the target would be the machine you are compiling for... but installing software remotely seems out of scope. Does it install it locally, or swap the bundled installation in the .exe?Also, no mention of binary limitations in actual docs, despite mention in post.
Hopefully this does not come off as discouraging - this looks like a good project.
Thanks for the feedback! I'm constantly working on the project. It's hard to do bc node sea is still an experimental feaurte and there's no much documentation about it, and i want to make it highest quality possible. And it's my first open-source project what's actually getting attention. I would really appreciate any help with this project!
This is not a compiler. It is doing no program translation. No register allocation. No parsing. No linking. It in no way resembles a compiler. Not every program that produces an executable file is a compiler just because some programs you may have heard of, like gcc, are in fact compilers.
I wish the JS universe would stop inventing new and wrong names for things.
(That said, this thing is at least using postject for actual insertion of the payload blob into the target executable, and based on its README, postjecth as the good taste to embed data as PE/ELF/Mach-O sections instead (as Bun does) of just YOLOing the attachment with cat.)
I totally understand your point - Astra doesn’t do register allocation or full parsing, so strictly speaking, it’s not a compiler in the traditional sense.
I used the term "compiler" because for many developers, it’s strongly associated with "turning source code into a single binary." That’s what Astra does at a practical level - even if it's technically just bundling and embedding into a node executable using SEA and postject.
> it’s strongly associated with "turning source code into a single binary."
Using things because they sound nice without thinking about whether they make sense is pretty much the whole JavaScript community. :)
This whole thread was uncalled for honestly. It takes source, it makes an exe, that meets the definition for compiler to me. Your pedantry is not useful.
How would you define the difference between a compiler and a linker?
To understand the underlying architecture- is my understanding correct that this runs esbuild to bundle then bundles that with node runtime and creates a binary that executes "node index.js"?
yes but it uses node SEA you can read about it here: https://nodejs.org/api/single-executable-applications.html
Very interesting. The readme notes "Different than the others - Astra is a new approach to compiling JavaScript/TypeScript applications. It uses a different method than other compilers like pkg or nexe." but never really explains what the difference is. Is it just that the code is run through esbuild before the SEA step or is there some other "magic sauce"?
Yes it's just esbuild and SEA BUT that's actually the point. SEA is officialy supported by node.js and it constantly improves. Remember pkg and nexe supports only the older versions of node.js (~14) and astra supports the latest ones.
So in a way, the "magic sauce" it that it doesn't try to do anything fancy. I made astra beacuse i needed to compile js to exe for latest versions.
I wanted astra to be simple, built on official tools, and be future-proof.
You probably want to put that information in your README.md, because there is barely any information in the readme, and the docs look to be a placeholder atm =)
thanks :)
This is really interesting, got it up and running very quickly.
I'm not sure what the use case is and it doesn't auto-load chromium with its own web server from what I can tell. Is it just for creating javascript CLI utilities?
Yes, astra it's aiming to compile CLIs and servers (express, fastify etc.). It's not replacing electron.
I don't get it, does this project do anything other than embedding js and node in a single executable?
Nothing wrong with that, but why call it a compiler instead of bundler which would make the intension obvious
https://astra-js.netlify.app/cli/faq/#thats-not-a-compiler-t...
I clicked on this hoping for an actual compiler. However from what I can see this is a bundler. The name is confusing.
Thanks for the feedback! You're right - Astra is technically a bundler-to-executable tool, not a source-level compiler like Babel or TypeScript.
I called it a “compiler” in the sense that it transforms a JS project into a standalone .exe, similar to how tools like pkg or nexe are often described. That said, I’ll consider clarifying that in the description to avoid confusion. Appreciate the comment!
Honestly, I would drop calling compiler altogether -- it's just not a compiler. It doesn't make it any less cool though!
Blame bun's --compile flag: https://bun.sh/docs/bundler/executables
We're probably going to have to live with "compiler" meaning "bundler" as an ongoing JavaScript-world neologism.
yeah it's not but i don't know how to call it. if i say it's bundler it will be more confusing in my opinion. waiting for your suggestions!
Sometimes the term "packager" is used instead of "bundler". Honestly though, "compiler" is the term most likely to cause any confusion. Even if one is not familiar with packagers/bundlers "js to exe ${unknown phrase}" still conveys things more clearly than "js to exe ${misleading phrase}".
But it's definitely not a compiler! I think "Astra - a new js2exe bundler" is much less ambiguous because it's... a bundler!
https://astra-js.netlify.app/cli/faq/#thats-not-a-compiler-t...
> Average exe is ~70-80MB (depends on your code) so it's lighter than most compilers
I know it's JS not actually a compiler but a bundler that just packs node in with your code, but I still had a nice laugh at 80mb being light. I suppose that's where the overton window is in a world of 1gb node_modules folders.
I wish there was a middle ground between this sort of thing and QuickJS (which is actually light, but has a lot of rough edges when it comes to its filesystem and network interfaces)
Bun also supports this out of the box, and the overhead is likely a bit less (reportedly 30-40MB for a single `console.log` call with no further dependencies - I didn't verify that myself though).
https://bun.sh/docs/bundler/executables
I suspect a large portion of the executable size in both cases is for the ICU library for localization support (Note QuickJS has its own, much smaller l10n library.) It's possible to download a Node binary without ICU, which could trim ~30MB.
> reportedly 30-40MB for a single `console.log` call with no further dependencies - I didn't verify that myself though
I got a 110 MB exe for "console.log('test')" in "test.ts" using "bun build .\test.ts --compile --outfile test.exe". Pretty compressible though, on the order of 1/4th the size pretty easily. Considering it has zstd compression for sourcemaps that'd be an interesting option to add in.
What's light enough when the average user in the western hemisphere has +300gb of storage?
I'm just asking since a 512gb disk has become the standard when ordering a laptop.
The amount of functionality an application provides should be the benchmark for the size rather than one's available disk space. I'm sitting on 20TB+ of available storage and anything over 1MB for a simple "Hello World" is excessive.
In professional and enthusiast circles, yes, but I think you underestimate the popularity of cheap laptops.
e.g. currently only 2 of the top 10 selling laptops on Amazon have >=300GB storage.
https://www.amazon.com/Best-Sellers-Computers-Accessories-La...
Cheap laptops with a Celeron, 4 GB RAM, and 64 GB storage have been incredibly popular since that formula became popular a handful of years ago. As are base-model MacBook Airs.
Well, if we already could make something in 1 MB, why do we want to achieve the same thing with 100 MB? It is as if there is a mentality of "somehow the higher the size the better".