Is that honestly a problem? Most Java applications I encounter is much larger than that.

50MB is nothing and if it enables you do have a single standalone binary that you're easily able to deploy I'd say it's worth the extra disk use.

Depends, really. If the target is a common OS then having people install Node.js itself plus grabbing your application as a zip file that has the code and a few different files to act as soft executable (myapp.bat, myapp.app, etc) can be significantly smaller. 50MB is not "nothing" when it comes to asking people to download it (because someone still has to download that application, and way fewer people than you think have as nice an internet connection as you). It also means people have to download a _new_ 50MB executable when the app updates, so from an "on disk size", it's nothing only if this is the only node application someone will ever run. Otherwise this becomes bloat very fast. Like bundling a full JVM with every individual application instead of going "or download this much, much smaller thing when you already have java installed". I don't need eight copies of the JRE, in the same way I don't need eight compiled apps if I already have node.js -- but that's a consideration for people who make applications and are thinking of packaged distribution. Just because you can, doesn't mean you should. Or even "should only".

You need to download the runtime at least once. If that 50MB is a problem, you can't use it in the first place.

Who likes to download Java on desktop anyway? It's absolutely the wrong way to distribute Electron apps.

It's so annoying for App developers that they have to ask what version of shared Electron the user has and install that for themselves and debug instead of just be done with it with the exact version developers tested and distributed.

I thought that was a totally reasonable file size too, until I looked up Docker image sizes for node:

https://hub.docker.com/r/library/node/tags/

Regular images are ~260MB and "slim" images are 85MB, but Alpine-based images are a paltry 18MB.

So it seems something in the Node.js compiler is ballooning up the size of the code, by a factor of about three. I wonder what.

It really depends on version of node, and the modules used. I'm more inclined to want to see what can be done as a minimal electron... or seeing electron go the adobe air route, and have a shared (continuous updating) base, but that could prove problematic as binary modules (namely sqlite) are common.

AFAIK Alpine Linux is using musl which would explain the low binary size.

There are quite a few minimalize Blink efforts. Like this one:

https://github.com/bloomberg/chromium.bb

https://github.com/weolar/miniblink49

The latter is around 9MB. The author is working on a electron wrapper.

Does this project include Blink? Looks like not.

It contains a stripped version of Blink with most of functions.

Blink is a rendering engine, V8 is a JavaScript engine. Node.js contains V8, but not Blink.

It's a naming thing, it does include v8 to execute js.

Blink is a fork of webkit, by your logic, most softwares based on webkit can not execute javascript???

No, Blink doesn't include V8, it's a separate project. WebKit consists of WebCore — layout engine, and JavaScriptCore — JavaScript engine. Google forked WebCore part of WebKit to create Blink. Before the fork it used a combination of WebCore and V8.

This information is readily available on, e.g. Wikipedia, so I'm not sure why you even try to argue about it.

Node.js doesn't include Blink, it only includes V8. Node.js Compiler doesn't include Blink into the build result — it includes Node.js.