@Gaelan It isn't, because there is nothing about Electron that requires this, it's perfectly possible to use an OS-wide Electron runtime and it has been possible since its inception

@Gaelan (In fact the whole "ship an Electron runtime with the application" thing didn't even *exist* in the early days, this was a thing that came to exist later mainly because tech companies wanted to run code in a predictable environment and didn't care about shipping bigger files to end users)

@joepie91 fwiw I’ve never seen a macOS electron app that wasn’t several hundred megs

(are you thinking about Linux or Windows maybe? it’s a lot more common for apps to share libraries on those platforms, I think)

@Gaelan Nope, this holds true for all platforms, it's possible on all of them, it's just something tech companies don't want to do and so shipping an entire runtime has become de facto standard practice

@Gaelan Like, Electron functions like a language runtime in the exact same way that you can do `python script.py`, except instead of pointing it at a .py file, you do `electron /path/to/app/folder` or `electron /path/to/bundle.asar`.

And the actual folder/ASAR are just the JS files and whatever other assets are being used, just like, say, a Python application. Depending on whether you strip down non-code files from your dependencies and whether you make it an ASAR, that can be anywhere from 1MB to a few hundred.

But in practice the vast majority of filesize of "Electron applications" is literally just the whole Electron runtime that the publisher chooses to include, and not the application code itself, which has no reason for being bigger than any other application.

But people never actually look at *why* files are big, or what (non-technical) decisionmaking lies behind it, and that's how we got widespread (wrong) beliefs that "Electron applications are massive".

@joepie91 I mean it would be incredibly unusual for a macOS program to share a non-OS-provided library* with another program. Like yes technically there’s nothing stopping you from putting an electron binary somewhere common, but the ecosystem support doesn’t exist for other applications to know about it, or manage who’s responsible for updating it, etc etc. Obviously on Linux you have a package manager to handle this; macOS doesn’t have a package manager, outside things like Homebrew and Macports used to manage Unix software for (broadly) developers.

The earliest version of Atom I can find on GitHub Releases, which seems like as good a source as any for “how Electron was designed to be distributed”, contains 64 MB of libchromiumcontent.dylib, although actually in that case it’s dwarfed by node_modules lol

*using “library” loosely here - all the same concerns apply if it’s an interpreter

@Gaelan Frankly this sounds entirely like a macOS problem to me, and not something that is reasonable to blame on Electron (or any other runtime for that matter).