New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expected app bundle size? #2003

Closed
mattotodd opened this Issue Jun 18, 2015 · 82 comments

Comments

Projects
None yet
@mattotodd

mattotodd commented Jun 18, 2015

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

This comment has been minimized.

Contributor

zcbenz commented Jun 19, 2015

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

@zcbenz zcbenz closed this Jun 19, 2015

@carlosperate

This comment has been minimized.

carlosperate commented Jun 19, 2015

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:

Contents\Frameworks\Electron Framework.framework
Contents\Frameworks\Electron Framework.framework\Versions\A
Contents\Frameworks\Electron Framework.framework\Versions\Current

Are these supposed to be symbolic links?

@erezcohen

This comment has been minimized.

erezcohen commented Jul 2, 2015

How small are the Windows and Linux builds?

@davefedele

This comment has been minimized.

davefedele commented Aug 28, 2015

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

This comment has been minimized.

znation commented Aug 28, 2015

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

This comment has been minimized.

carlosperate commented Sep 4, 2015

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

@jlord

This comment has been minimized.

Member

jlord commented Sep 4, 2015

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.

@paulcbetts

This comment has been minimized.

Contributor

paulcbetts commented Sep 4, 2015

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

This comment has been minimized.

carlosperate commented Sep 4, 2015

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).

@paulcbetts

This comment has been minimized.

Contributor

paulcbetts commented Sep 5, 2015

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

This comment has been minimized.

carlosperate commented Sep 8, 2015

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

This comment has been minimized.

Kadrian commented Sep 16, 2015

@carlosperate Can you describe how you fixed your symlinks?

@carlosperate

This comment has been minimized.

carlosperate commented Sep 16, 2015

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

This comment has been minimized.

smhg commented Nov 17, 2015

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

This comment has been minimized.

iamnewspecies commented Apr 15, 2016

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

@carlosperate

This comment has been minimized.

carlosperate commented Apr 15, 2016

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

This comment has been minimized.

mattotodd commented Apr 15, 2016

Last I checked slack were using MacGap for the mac side

@iamnewspecies

This comment has been minimized.

iamnewspecies commented Apr 15, 2016

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

@joshaber

This comment has been minimized.

Contributor

joshaber commented Apr 15, 2016

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

@sgarbesi

This comment has been minimized.

sgarbesi commented May 10, 2016

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

seckie pushed a commit to seckie/jsmetronome that referenced this issue Jul 2, 2016

@leonelcbraz

This comment has been minimized.

leonelcbraz commented Jul 26, 2016

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

@baconbrad

This comment has been minimized.

Contributor

baconbrad commented Jul 26, 2016

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

This comment has been minimized.

leonelcbraz commented Jul 26, 2016

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.

@eladnava

This comment has been minimized.

eladnava commented Feb 23, 2018

@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.

@spaceywolfi

This comment has been minimized.

spaceywolfi commented Feb 23, 2018

@eladnava thank you for explaining!

@baconbrad

This comment has been minimized.

Contributor

baconbrad commented Feb 26, 2018

@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

This comment has been minimized.

eladnava commented Feb 26, 2018

@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

This comment has been minimized.

Contributor

baconbrad commented Feb 27, 2018

@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

This comment has been minimized.

eladnava commented Feb 28, 2018

@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

This comment has been minimized.

Contributor

baconbrad commented Feb 28, 2018

@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

This comment has been minimized.

eladnava commented Mar 1, 2018

@baconbrad

Cheers for the tips mate!

@rkyoku

This comment has been minimized.

rkyoku commented Mar 9, 2018

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.

@yasinaydin

This comment has been minimized.

yasinaydin commented Mar 9, 2018

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

@rkyoku

This comment has been minimized.

rkyoku commented Mar 9, 2018

@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

This comment has been minimized.

Contributor

timfish commented Mar 9, 2018

@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!

@yasinaydin

This comment has been minimized.

yasinaydin commented Mar 9, 2018

@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

This comment has been minimized.

rkyoku commented Mar 9, 2018

@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

This comment has been minimized.

mvladic commented Mar 9, 2018

@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.

@yasinaydin

This comment has been minimized.

yasinaydin commented Mar 9, 2018

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

This comment has been minimized.

Contributor

fab1an commented Mar 9, 2018

Electron just isn't the best framework.

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

@mvladic

This comment has been minimized.

mvladic commented Mar 9, 2018

@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

This comment has been minimized.

rkyoku commented Mar 9, 2018

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

This comment has been minimized.

rkyoku commented Mar 9, 2018

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

This comment has been minimized.

Contributor

baconbrad commented Mar 9, 2018

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

This comment has been minimized.

rkyoku commented Mar 9, 2018

@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

This comment has been minimized.

karimhossenbux commented Mar 10, 2018

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

This comment has been minimized.

Contributor

baconbrad commented Mar 12, 2018

@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

This comment has been minimized.

karimhossenbux commented Mar 13, 2018

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

@Rafi993

This comment has been minimized.

Rafi993 commented Mar 25, 2018

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

This comment has been minimized.

lukepighetti commented May 25, 2018

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

This comment has been minimized.

rkyoku commented May 25, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment