Electron: Expected app bundle size?

[mattotodd]

When building the latest 0.27.3 the mac app bundle is about 142MB of which 136MB come from the Electron Framework.

Is there any way to make this package smaller?

[zcbenz]

That's the expected size, there is no way to make it smaller.

[carlosperate]

Is it really expected to be that large? my bundled windows and linux builds are much smaller, and looking into the Electron Framework folder, there are three copies of the Electon Framework file, one on each:

ContentsFrameworksElectron Framework.framework
ContentsFrameworksElectron Framework.frameworkVersionsA
ContentsFrameworksElectron Framework.frameworkVersionsCurrent

Are these supposed to be symbolic links?

[erezcohen]

How small are the Windows and Linux builds?

[davefedele]

I am also wondering about this. Here are the sizes for my electron app:

      osx - 117.3 mb
  linux32 -  60.3 mb
  linux64 -  55.2 mb
 win ia32 -  47.8 mb
  win x64 -  66.2 mb

Thanks!

[znation]

Is there a plan to try to reduce the size of the framework in future releases? This makes it hard to justify using Electron for small apps (where the size of the app itself would be dwarfed by the size of Electron).

[carlosperate]

I can confirm that my electron app bundles are about the same size as @davefedele.

[jlord]

You can zip your app and if you're using electron-packager you can ignore some node modules that you don't need when the app is running, this makes it a bit smaller. For instance I have a 37MB zipped Electron app (Note Windows version is much larger as it contains a copy of Git).

But Electron will always have a large part of Chrome in it so there is only so much that can be done. Electron itself right now is ~33MB.

[anaisbetts]

OS X compressed is similarly sized to other platforms which probably means that the app you're using to measure sizes is perhaps misinterpreting symlinks?

[carlosperate]

In my case I am using an electron-boilerplate that does not use electron-packager and my electron app folder gets zipped with a python script and distributed via aws s3. So my first though was that the symlinks were not respected when compressing (rather than the file size being misinterpreted).

I'll have to look into it, is there anywhere a list of the symlinks present? I have very limited access to a mac computer (I use a CI server to pack my app for each platform).

[anaisbetts]

paul@psamathe:/Applications/Slack.app% find . -type l
./Contents/Frameworks/Electron Framework.framework/Electron Framework
./Contents/Frameworks/Electron Framework.framework/Libraries
./Contents/Frameworks/Electron Framework.framework/Resources
./Contents/Frameworks/Electron Framework.framework/Versions/Current
./Contents/Frameworks/Mantle.framework/Headers
./Contents/Frameworks/Mantle.framework/Mantle
./Contents/Frameworks/Mantle.framework/Modules
./Contents/Frameworks/Mantle.framework/Resources
./Contents/Frameworks/Mantle.framework/Versions/Current
./Contents/Frameworks/ReactiveCocoa.framework/Headers
./Contents/Frameworks/ReactiveCocoa.framework/Modules
./Contents/Frameworks/ReactiveCocoa.framework/ReactiveCocoa
./Contents/Frameworks/ReactiveCocoa.framework/Resources
./Contents/Frameworks/ReactiveCocoa.framework/Versions/Current
./Contents/Frameworks/Squirrel.framework/Headers
./Contents/Frameworks/Squirrel.framework/Modules
./Contents/Frameworks/Squirrel.framework/Resources
./Contents/Frameworks/Squirrel.framework/Squirrel
./Contents/Frameworks/Squirrel.framework/Versions/Current

[carlosperate]

I was finally able to look into this yesterday, and indeed my issue was caused by symlinks not being preserved. So my application size drastically shrunk from ~110Mbs, to ~45Mbs.

[Kadrian]

@carlosperate Can you describe how you fixed your symlinks?

[carlosperate]

Well, it is important to emphasise that I am not using electron-packager. I had a python "build script" (same script runs in windows, linux and os x) that would build other stuff independent to my electron app, then if running on mac it would copy everything into the general OS X app bundle directories, and finally zip everything into a single file.

So, in my specific case there were two issues with my script, I was copying the electron files without respecting symlinks (very easy to fix), and then the zipfile module in Python was not respecting the symlinks either, which was not as easy as I expected. If you google solutions to the problem you'll find a few articles with odd implementations that were closer to magic than a real explanation, so after some time unsuccessfully trying to get it to work I ended up just running a subprocess that executes the os x zip CLI command with the required flags for respecting symlinks.

[smhg]

FWIW, when creating a zip on Linux for distribution to OS X, you'll have to use the -y parameter to correctly handle symlinks:

$ zip -r -y app.zip app

[iamnewspecies]

What has #SLACK done? Why is their app so small?
The zip archive file is 24.6 MB.

[carlosperate]

The Windows and linux versions are more or less what I'd expect, I wonder how they've got their OSX version so small.

[mattotodd]

Last I checked slack were using MacGap for the mac side

[iamnewspecies]

http://electron.atom.io/#built-on-electron Slack is there in the list.

[joshaber]

Yes, Slack's Windows and Linux apps are built on Electron, but the Mac app uses MacGap.

[sgarbesi]

@joshaber I think you're correct. The Slack mac app is only ~36 MB.

[leonelcbraz]

Do you guys know if Electron has any plan for reducing the final bundle size? That'd be incredible.

[baconbrad]

Do you guys know if Electron has any plan for reducing the final bundle size? That'd be incredible.

There is only so much you can take out of Chromium, Node.js, V8, etc and still have a working product. Unfortunately since everything is patched in order to work it isn't as easy as making it use standalone versions of each to cut down on the size. I am sure the Electron team would like a smaller size. But you just can't plan and make it happen. It is just too caustic on the overall project to go in thinking you can remove even 10-20 megs of code and resources and expect everything to run stable.

[leonelcbraz]

So true @baconface... One thing though has helped me out here: I was putting modules like electron-prebuilt, electron-builder and electron-packager and all their dependencies in the "app" folder. Cutting them off from app's package.json and building again saved me a lot of size. I used the two-package.json structure from electron-builder.

[baconbrad]

@leonelcbraz Feel free to borrow or get ideas from my ignore regex for electron-packager. I create executable files in the bin directory, have a src directory for unminified source files, use Grunt for building, and have other stuff I didn't need in there. If I work on a project I don't need to use the node context I just set nodeIntegration to false and ignore the whole node_modules directory. This drastically reduced my distribution size.

(^(/bin|/src)$|[Gg]runt(.*)|node_modules/grunt-(.*)|node_modules/electron-(.*))

Additionally there is no need to use use the two-package.json structure. NPM supports developer dependencies. You can install one via npm install <package name> --save-dev. You will then notice in your package.json you have a dependencies and devDependencies with your dependencies separated neatly. Modifying the ignore regex for electron-packager like I did above you can completely isolate them from your app yet work in a normal node.js environment.

Edit: It is even easier than this!

[leonelcbraz]

That sounds nice. Thank you for sharing :)

[NelsonMinar]

Slack now has an Electron beta of the Mac client. The old Mac binary (using MacGap) was 36MB on disk. The new Mac binary (using Electron) is 175MB. 124MB of that is the Electron Framework.

[Andrey-Pavlov]

@NelsonMinar This sucks, fellows. Need to do something with app size.

[BonusPlay]

Agreed.

[pierreraii]

Using @baconface ignore regex helped a lot with reducing app size, I also did manually ignore more of the node_modules which were there and my app could run fine without, which got me to around 50MB of total Mac app size and around 60MB for Windows.

[baconbrad]

@pierreraii Glad it helped out. An important note is NPM3 changes the way the node_module directory works. As a result this trick might not work to your expectations. You can downgrade NPM to version 2 using npm i npm@2 -g though.

In the future our solution for our project at work is using NPM3 but putting everything we don't want shipped as a dev dependency. We install our Electron build tools globally opposed to the project level. Then doing an install of only needed modules with npm install --only=production. This however isn't ideal for open source projects but it works for our office. It is unfortunate we have to have a weird setup like this but it is doubtful NPM will ever be designed with Electron in mind since it is just a blip in the NPM ecosystem.

[catx23]

yeah, telling web devs to deal with electron in top turns out almost impossible. just thinking about an env which can be both... currently I base my electron apps on pre deployed servers, since they can before and for all others, ideally sharing the same dependencies. if asar could be a real user fs, then i would consider size and copy problems solved, especially with native extensions

[MarshallOfSound]

@baconface You don't need to worry about any of that. Simply install your dependencies like normal (prod deps in dependencies and dev deps in devDependencies) and then during the packaging phase (electron-packager does this for you) simply copy your app folder to a temp directory and run.

npm prune --production

That will destroy all dev dependencies regardless of your NPM version resulting the minimum size possible.

[catx23]

you can get another 40-80+ % more deleted than just with --production

[MarshallOfSound]

you can get another 40-80+ % more deleted than just with --production

If that is the case your dependencies are configured incorrectly, if you need to delete a module and prune --production is not deleting it it means it has been recognized as a production dependency. Moving it to devDependencies will result in it's deletion.

[catx23]

oh sorry, forgot to say: if you build a file mask which deletes readme, license, ... and node-gyp alone produces 100 folds more

[MarshallOfSound]

@xblox I can only imagine those readmes/licenses and such being like a few kilobytes tops, cool new trick is to run yarn clean which automatically wipes these things for you.

[anaisbetts]

@MarshallOfSound You'd be surprised, especially when you use native modules. Lots of garbage laying around. The yarn clean approach might be a good one

[catx23]

@MarshallOfSound doing your own file-mask worth every penny, its always surprising what's inside some packages. And its quite more than just a few kilobytes but I will check yarn clean. thanks for the pointer.

[catx23]

@MarshallOfSound , @paulcbetts : after playing with yarn clean: it cleans only around 70% of what is possible with the mentioned file mask

[changkun]

If we just want to write a hello world application without any node module dependencies, why the packager still warp everything? The state-of-the-art solution is to uses yarn clean, isn't it?

[fab1an]

My node_modules are 40 MB and electron is 140MB

[farfromrefug]

Using electron-builder and this files glob i gain around 80% on my desktop app

files:[
"**/*",
                "!**/.*",
                '!buildResources{,/**/*}',
                '!**/node_modules/**/{CONTRIBUTORS,License,CNAME,AUTHOR,TODO,CONTRIBUTING,COPYING,INSTALL,NEWS,PORTING,Makefile,license,LICENCE,LICENSE,htdocs,CHANGELOG,ChangeLog,changelog,README,Readme,readme,test,sample,example,demo,composer.json,tsconfig.json,jsdoc.json,tslint.json,typings.json,gulpfile,bower.json,package-lock,Gruntfile,CMakeLists,karma.conf,yarn.lock}*',
                "!**/node_modules/**/{man,benchmark,node_modules,spec,cmake,browser,vagrant,doxy*,bin,obj,obj.target,example,examples,test,tests,doc,docs,msvc,Xcode,CVS,RCS,SCCS}{,/**/*}",
                "!**/node_modules/**/*.{conf,png,pc,coffee,txt,spec.js,ts,js.flow,html,def,jst,xml,ico,in,ac,sln,dsp,dsw,cmd,vcproj,vcxproj,vcxproj.filters,pdb,exp,obj,lib,map,md,sh,gypi,gyp,h,cpp,yml,log,tlog,Makefile,mk,c,cc,rc,xcodeproj,xcconfig,d.ts,yaml,hpp}",
                "!**/node_modules/**!(dom-to-image).min.js",
                "!**/node_modules/!(serialport|xpc-connection|unix-dgram|mraa)/build{,/**/*}", //prevent duplicate .node
                "!**/node_modules/**/node-v*-x64{,/**/*}", //prevent duplicate .node
                "!**/node_modules/contextify{,/**/*}",
                "!**/node_modules/jsdom{,/**/*}",
                "!**/node_modules/babe-runtime{,/**/*}",
                "!**/node_modules/bluebird/js/browser{,/**/*}",
                "!**/node_modules/xterm/dist{,/**/*}",
                "!**/node_modules/source-map/dist{,/**/*}",
                "!**/node_modules/lodash/fp{,/**/*}",
                "!**/node_modules/moment/src{,/**/*}",
                "!**/node_modules/moment/min{,/**/*}",
                // "!**/node_modules/moment/locale/!(fr.js|en.js|ja.js)",
                "!**/node_modules/async/!(dist|package.json)",
                "!**/node_modules/async/internal{,/**/*}",
                "!**/node_modules/ajv/dist{,/**/*}",
                "!**/node_modules/ajv/scripts{,/**/*}",
                "!**/node_modules/asn1/tst{,/**/*}",
                "!**/node_modules/axios/lib{,/**/*}",
                "!**/node_modules/axios/!(index.js|package.json)",
                "!**/node_modules/axios/dist/axios.min.js",
                "!**/node_modules/bluebird/js/browser{,/**/*}",
                "!**/node_modules/dom-to-image/src{,/**/*}",
                "!**/node_modules/xterm/src{,/**/*}",
                "!**/node_modules/qs/dist{,/**/*}",
                "!**/node_moduleslog4js/logs{,/**/*}",
                "!**/node_modulesi18next/!(index.js|package.json|dist)",
                "!**/node_modulesi18next/dist/!(commonjs)",
                "!**/node_modules/viewport-dimensions/dist{,/**/*}",
                "!**/node_modules/validator/!(lib|index.js|package.json|validator.js)",
                "!**/node_modules/moment-timezone/builds{,/**/*}",
                "!**/node_modules/moment-timezone/data/meta{,/**/*}",
                "!**/node_modules/moment-timezone/data/unpacked{,/**/*}",
                "!**/node_modules/node-pre-gyp/!(lib|package.json)",
                "!**/node_modules/node-pre-gyp/lib/!(util|pre-binding.js|node-pre-gyp.js)",
                "!**/node_modules/node-pre-gyp/lib/util/!(versioning.js|abi_crosswalk.json)",
                "!**/node_modules/ssh2/util{,/**/*}",
                "!**/node_modules/source-map-support/browser-source-map-support.js",
                "!**/node_modules/usb/!(package.json|src)",
                "!**/node_modules/opencv/!(package.json|lib)",
                "!**/node_modules/json-schema/!(package.json|lib)",
                "!**/node_modules/hawk/dist/{,/**/*}",
                "!**/node_modules/hawk/lib/browser.js",
]

The thing is that it is really dependendant on the modules you use, which makes it a pain to maintain!

[OmgImAlexis]

@farfromrefug be careful shipping your app if you're using open source libs, there's a chance the libraries you're using require the license file to be shipped with all applications and you're blindly removing them all.

[farfromrefug]

@OmgImAlexis Actually you are right i should keep Licence files. Thanks!

[baconbrad]

Just a heads up. electron-packager is smart enough to purge dependencies listed in a devDependencies. So I moved most of my packages to that and bundle the scripts I use in a single JS file using Grunt. So now my regex for ignore looks something like this "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|build.js)". Gives me the same results but is much easier and I don't have to manually add dependency paths to my regex. Even works with the way Yarn stores dependencies.

[vaidyaanand]

I had recently cloned the example project for learning purpose from https://github.com/electron/simple-samples.git. I have created a win32 x64 app of activity-monitor which is inside the cloned folder by the following command:
electron-packager C:userlearningnodeclonedAppsimple-samplesactivity-monitor cpu --platform=win32 --arch=x64 --ignore="node_modules"

I wondered the bundle size is 132 Mb for just a simple app.
Is there any way to reduce the bundle size?

[silverkorn]

I would have suggested to use UPX on your executable, which is cross-platform, supports many architectures and is dead easy to use, but unfortunately it seems that Electron's team prefer not to bow on this.
(Already requested earlier: https://github.com/electron/electron/issues/5506)

Otherwise, my testing worked well by compressing NW.js with UPX (~60% lower in final size) although I did not tried if it still works with the latest version...
So if size matter, maybe you could focus on developing with this one instead?

[eladnava]

I was able to get my zipped OSX distribution size to 52MB by moving electron and pretty much any other non-runtime package to devDependencies in package.json, running rm -rf node_modules and then npm install --production.

When packaging the app, electron-packager would complain of a missing electron dependency in the project's node_modules. You can work around that by providing the following flag to electron-packager:

--electron-version=1.7.11

Substitute 1.7.11 with your desired electron-packager version.

[vaidyaanand]

@eladnava Thanks for providing information. I will check the steps provided by you. When I convert the application to dmg its size is 53 MB.

[yasinaydinnet]

I don't know/didn't read all the previous messages, so please tell me if it is already said.

Is it possible to separate Electron framework itself and just ship the apps?

As far as I understand, the way Electron apps ship is the fw is included. It sounds like shipping a Java app with JRE included in it.

Is it possible to install a Electron framework to the OS so all the apps that can use that version will use?

[fab1an]

@eladnava You do realise that your App won't run if electron isn't installed on the target-machine?

[js-choi]

@fab1an: I think that @yasinaydin understands that. He wants an Electron common runtime that users can install for all their Electron-using applications. This is already being discussed in electron/electron#673, currently with no resolution.

[eladnava]

@js-choi @fab1an I'm not entirely sure how it works, but I have a feeling Electron comes pre-bundled in electron-packager, within the Electron Framework.framework that is included within the packaged app.

Therefore, there is no reason to also bundle electron within your app's node_modules. Also, there is no need for the npm electron package to be installed on the target machine for my approach to work.

[waotzi]

electrino was able to make a 115 MB Electron app to only 167 kB using their technology. I think this technology must be integrated into electron, a 100MB hello world app is just not a normal size to display "Hello World" :+1:

[eladnava]

@spaceywolfi Since Electrino is not actually running Chrome / V8 engine to render your app, but using OSX's native web browser engine (WebKit), you can't really just take your Electron app and build it with Electrino, especially if you make use of Electron APIs, as they aren't available there. At least not yet.

You can try to go with the trick I mentioned to get the base binary size down to ~50MB.

[waotzi]

@eladnava thank you for explaining!

[baconbrad]

@eladnava

I'm not entirely sure how it works, but I have a feeling Electron comes pre-bundled in electron-packager, within the Electron Framework.framework that is included within the packaged app.

Therefore, there is no reason to also bundle electron within your app's node_modules. approach to work.

I have electron and electron-packager in my devDependencies. This way I can assign electron ./dist/js/main.js to a script in my package.json. So running npm run launch for example will quickly launch a unpackaged ready to test instance of my Electron app. Additionally electron-packager will use the version listed for electron so your packaged version is the same as your test version of Electron. It should also strip electron and electron-packager from the output automatically as well.

[eladnava]

@baconbrad

Thanks for your tip. I ended up installing electron and electron-packager globally to avoid them from being packaged into the final binary's node_modules folder. I found that electron-packager did not strip out these dependencies automatically from the final binary, which resulted in a binary size of ~100MB for me. After installing these two packages globally, binary size dropped to ~50MB.

[baconbrad]

@eladnava This likely happened because you had them as a dependency and not as a dev dependency. If you use npm install packagename --save-dev this will save it in the proper area of your package.json. It will show up in your node_modules folder but will be removed once packaged.

[eladnava]

@baconbrad

This is quite indeed possible. But I do think that since newer versions of npm install all your dependencies' dependencies in the root project node_modules/ folder, these may have been getting bundled by electron-packager into the final binary.

Do you know if electron-packager is smart enough to omit those devDependencies' dependencies?

[baconbrad]

@eladnava

Do you know if electron-packager is smart enough to omit those devDependencies' dependencies?

Can confirm it omits devDependencies dependencies. Even if you are using the latest version of NPM or Yarn.

Also you should use a build system like Gulp or Grunt to bundle up front end dependencies and make those be listed in devDependencies as well. This is because they might be shipped with extra source files or their devDependencies. The only time I have something in my dependencies is because I absolutely need to ship it. Your scripts will still want to run in the node context so you will need to call window.module = module; module = undefined; before you load in your bundled scripts in the browser context. I then make sure I my packager has this in the ignore option "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|buildscript.js)". Doing all these steps basically eliminates excessive dependency bulking or mistakenly including source files or build folders.

[eladnava]

@baconbrad

Cheers for the tips mate!

[rkyoku]

Hi guys,

In order to drastically reduce the app size for everyone, save bandwidth for everyone, make the build process easier for everyone, etc. the optimization/thinking has to be done differently than just ignoring some node_modules.

How about using the same idea that Java and Java apps have been successfully using for decades: have a dependency on a "JRE" (which would be a "ERE" in our case).

That way, the ERE would be installed globally on the machine for the first app needing it (the process of requiring the ERE could be automated by the app installer for each platform), and then every new app would only be using this existing this ERE.

The ERE would need an auto-update feature and backward-compatibility (no bcb!) for this to work, but I'm pretty sure this is trivial-ish.

Then, every Electron app would then weight like a couple MB only. Saving users time. Saving developers time and bandwidth and build complexity.

Has it been proposed before? If so, how about it then? I think this is the only and best way to go.

[yasinaydinnet]

@RenaudParis I proposed it before and maybe few more, but I've heard no serious works so far.

[rkyoku]

@yasinaydin I figured as much, people must have thought about that before.

Well, any input from the dev team then? @zcbenz This would make so many people happy, and would make Electron future-proof big time (because let's face it: embedding two frameworks inside each and every app is seriously limiting usage for smaller apps, this is a regular rant that has been going on for years)

Isn't the JRE a great example to follow here?

[timfish]

@RenaudParis and @yasinaydin, there are so many reasons having a global install of electron will never happen.

Firstly, of all the production electron apps out there in the wild, there are maybe 20+ different versions of electron in use. Which version would you chose to have globally? It's fragmented like this because electron has a fast release cycle and developers want access to the latest Chrome features.

Our apps are only tested with a single version of electron and for the sake of a 40MB download why would we run the risk and support costs of allowing it to run on any other random untested version?

make the build process easier for everyone

Many electron apps use native modules which in most cases have to be built against the specific version of electron in use. How would you solve this issue?

Feel free to create a global version of electron that developers can use but I think you'd find that barely anybody would use it for the above reasons!

[yasinaydinnet]

@timfish
there are so many reasons having a global install of electron will never happen.
That sounds like one of these: https://www.pcworld.com/article/155984/worst_tech_predictions.html

Since Node/v8 or electron binaries are not that big, a global ERE can download missing components for using once, if needed. Also some bundle logic can be implemented for these global ERE's, like Node.js 9.x instead of separate Node.js 9.0, 9.1 etc..

I don't know but I don't think that's the attitude to do stuff... "Oh it can't be done. Oh it's impossible. Doesn't make any sense." Instead it should be "How can we accomplish/workaround this x?"

[rkyoku]

@timfish this is sad news... I personally don't care much about a 40MB file, but 120MB (as I heard) however is a bit too much for a hello world.

Firstly, of all the production electron apps out there in the wild, there are maybe 20+ different versions of electron in use. Which version would you chose to have globally?

As I said, backward-compatibility would be required.

developers want access to the latest Chrome features

Hence progressive enhancement... Right? In any case, even progressive enhancement is not mandatory if an app can require a specific version of the ERE, which would trigger an update of the global ERE.

How would you solve this issue?

If some people need specifically compiled modules, they are free to embed their own custom version of the modules (which would in any case not be available inside the ERE anyway) and specify a minimum version of the ERE. If the ERE is updated to a newer version, I guess there are 2 obvious solutions: either they update their modules (same as with dependencies in Node today) or we could also allow multiple global versions of the ERE (same as the JRE). I think this is a non-issue.

electron has a fast release cycle

This is great, no doubt here. But maybe people could survive with a monthly release, hence limiting the amount of ERE versions.

Feel free to create a global version

Yeah... Not gonna do that. I don't have the skills, but I would if I had.

I can merely offer suggestions which I deem relevant, and let the experts do their job: either they tell me I'm being an idiot with my suggestions (which may very well be the case), or they reckon it might lead to something nice. Whatever :)

I still think a global ERE would be the best solution, even if it means having multiple EREs for the various needs of the different apps out there. But, again, this is just an idea I had from comparing to the JRE.

[mvladic]

@RenaudParis

this is sad news... I personally don't care much about a 40MB file, but 120MB (as I heard) however is a bit too much for a hello world.

120MB is uncompressed, if you compress it it is around 40MB. For example, VSCode 64-bit for Windows installation EXE is around 42.8 MB.

Personally, as a user, I would always rather have self contained application without the need to manage global JRE (or ERE) even if I have to download 200MB instead of 10MB.

[yasinaydinnet]

It's not just 120mb, I created a simple web application which was ~1mb on web server but ~300mb as an Electron app on OS X

Plus, this is becomes more important when there are many Electron apps running on the same machine.
Then it will be 10 times, 20 times bigger.
There are now multiple standard apps on a computer built with Electron like Slack, VSCode etc. And there are even bigger projects like NodeOS.

Node.js has >500k modules. If Electron would get better & faster & more popular & smaller, there would be many more apps on a desktop, with GBs of unnecessary Electron files.

[fab1an]

Electron just isn't the best framework.

I would rather look into splitting out unneeded parts of the Chrome framework like Flash etc.

[mvladic]

@yasinaydin

1mb on web server but ~300mb as an Electron app on OS X

You need to cleanup your application before distribution (hint: check your node_modules). For example, VSCode on Windows is 228MB after installation (downloadable installation is only 42.8MB).

But, installation size is only one problem, Other problem is how much RAM application is using and launch time. In my experience, once application is launched the speed of application isn't a problem.

Electron is not a good match for small applications, but for big applications like VSCode it works.

[rkyoku]

Other problem is how much RAM application is using and launch time

@mvladic don't you think that precisely that's two more issues that an ERE would fix? Being already loaded and shared among apps, and all.

Okay, maybe people don't have 10 Electron apps running at the same time... But maybe they will! Factorizing dependencies as much as possible is important.

I get that Electron was first launched as a POC, and then needed very frequent releases to please the devs. But maybe now that Electron is more mature, some measures have to be taken to ensure the best possible {load time, ram usage, download size}.

Again, I am just proposing a (naive maybe, I don't know) solution to issues that Electron users seem to be ranting about since the beginning. But as far as I am concerned, I really don't mind the current state of Electron for my own little needs. Electron is great, I am just thinking of ways to make it even better.

[rkyoku]

Electron just isn't the best framework.

@fab1an , depends what people need. For me, it is perfectly suited to my needs, because I'm not sure that PWAs are mature enough. But again maybe for other people Qt would be better suited, you are right about that.

[baconbrad]

A runtime has been proposed and discussed before and is still an open discussion. But this is one of those things that is easier said than done. As you can see not everyone has been able to get on the same page or figure out how to properly get it off the ground where it will work in reliably in production. If you think you can contribute to the discussion or help get it started I don't think anyone would mind the extra help.

A lot of devs including myself are pretty happy with putting out a 40 meg download and updating it using smaller delta updates. People today have no problem downloading a 40 meg program. And even small programs out there that are a couple meg file might downloads and install 40 megs - 2 gigs and no one seems to have an issue. with it. Even if a runtime option was available chances are a user won't have it and will have to download 40+ megs to run your project anyways.

If this caveat isn't your cup of tea look into another option if needed. I don't mean that bluntly, sometimes you have to eliminate technologies to meet the goal and conditions you wish to meet. But this doesn't make Electron a bad technology or make it unusable for many others. Electron isn't meant to solve every solution. And it realistically never will.

[rkyoku]

@baconbrad if your comment is targetting me, I do not understand why, as I explicitely said several times that I was pretty happy as it is, and that Electron was precisely the technology suited for my (specific) needs.

I only said that I saw many people complaining everywhere about the package size and I was merely offering a (again naive) solution to that problem, that seemed ideal to me. But I may very well be mistaken and in any case it will absolutely not prevent me from using Electron for my future needs :)

Even if a runtime option was available chances are a user won't have it and will have to download 40+ megs to run your project anyways.

Yeah but I know plenty of people, even here in central Paris, who only have a 5Mbps internet connection, and for those people, saving 40MB (i.e. 320Mb) for each app means saving a couple minutes every time the app updates (don't forget that the 40MB will be for each update, not just the first install), given that their internet connection is not used.

It's not even taking into account the RAM savings, especially for notebooks. Again, I don't feel personally concerned as I have a relatively good machine with 32GB RAM, but I'm not thinking about myself here, but rather about the people complaining, and hoping to find a solution for them.

Last but not least, you may have a good connection, and so do I (a lightning fast one if you please! :) ), and we may both have 16 or 32 or 64GB of RAM, that's why you (yourself) don't mind downloading the 40MB for each update, but what about your users (given that you distribute your app to people)?

Anyway, I won't fight about this, I was only seeking to help, and as I said I'm pretty happy as it is, and I have plenty of things to attend to.

If some people think I can help them think of a solution, I'd be happy to lend a hand, but otherwise I'll go back to work :)

Cheers,

[karimhossenbux]

One thing I saw when moving more dependencies to devDependencies, the more time it needs to build it.

````
✔ building main process

• building renderer process
  ````

It spent a lot more time on "building renderer process", and the animated icon stop like it crashes but it didn't. Then it show 203778ms from the renderer report.

Moving devDependencies back to dependencies, build time is normal again but app is big.

If I'm not having any error during build, it means it's all good right?

[baconbrad]

@karimhossenbux This is normal for me. There is a walk function in electron-packager that goes through all the dependencies to determine if they should be there or not. With the new flat style dependencies instead of the nested it will take a lot longer to determine unneeded dependencies. As far as I know there is no way to get around the extra build time.

[karimhossenbux]

@baconbrad Thank you! I'm using electron-builder but I guess it works the same way.

[Rafi993]

Is there any electron package builder that includes only your source and download others (only necessary for the current operating system user runs on) when the user runs your app for the first time ?. It would make it easy for distribution and should reduce your app size considerably.

[lukepighetti]

Electron, please do not go the "ERE" route. Yes, I know you are bloated, but I love how people can download my application and it just runs great without having to screw around with installing deps, updating the runtime environment, or any of that nonsense that I thought we got rid of circa 2003.

[rkyoku]

Well, downloading a bundle would still be an option. Nothing to complain
about here :)

Le ven. 25 mai 2018 à 21:03, Luke Pighetti [e-mail] a
écrit :

Electron, please do not go the "ERE" route. Yes, I know you are bloated,
but I love how people can download my application and it just runs great
without having to screw around with installing deps, updating the runtime
environment, or any of that nonsense that I thought we got rid of circa
2003.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/electron/electron/issues/2003#issuecomment-392151709,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AApUIBjAeVZ7T4SKo8LyW6RT65XnpiKgks5t2FWfgaJpZM4FGGer
.

[zcmgyu]

I'm just waiting for Microsoft engineers to improve Electron.
https://news.ycombinator.com/item?id=17229973

[baconbrad]

I'm just waiting for Microsoft engineers to improve Electron.
https://news.ycombinator.com/item?id=17229973

@zcmgyu Microsoft has employed developers to work on Electron for a few years now since they started using it for VS Code. And they are some of the biggest contributors and have improved it quite a bit.

[stephanebouget]

If your application is more than 100MB,
it may be that your exe includes a good part of your node_modules folder.
Note that everything declared in package.json in dependencies is imported back into the final executable.
(Very simple to verify: it is enough to decompile the executable)
So remember to define only the essential libs in dependencies (electron-log, electron-updater) and add all the other libs in devDependencies.

Your app will then "only" 50MB ...

[dragonDScript]

My app is little- here's the repo. The latest experimental version weights about 700mb
https://github.com/DeltaStudioApp/Delta-Studio/tree/experimental

[gzx-miller]

I am also wondering about this. Here are the sizes for my electron app:

  osx - 117.3 mb

linux32 - 60.3 mb
linux64 - 55.2 mb
win ia32 - 47.8 mb
win x64 - 66.2 mb
Thanks!

Amazing! Could you share about how to reduce electron app to so small size.