7 ms·

In total, the app is 122 MiB large. Of which the runtime is about 120.3 MiB. There is even a copy of ffmpeg (2 MB) for the rare occasion when you want to play

by est31 8y ago

In total, the app is 122 MiB large. Of which the runtime is about 120.3 MiB. There is even a copy of ffmpeg (2 MB) for the rare occasion when you want to play back an mp4 video in your color picker. The actual app itself is in the resources directory which is 1.8 MiB large. This directory contains files electron.asar (214 KiB), app.js (1.7 KiB), package.json (727B), and directories static (152 KiB) and node_modules (1.4 MiB). The actual content created by the author is in app.js, package.json and static, which together take 160 KiB, of which 52 KiB is the logo (would have been much smaller as SVG) and 68.8 KiB a bundled font. In the node_modules directory major contributors for size that I see are: * node_modules/tinycolor2/demo (288 KiB; largest contributor here is a jquery copy) * node_modules/tinycolor2/docs (228 KiB) * node_modules/tinycolor2/test (116 KiB) * node_modules/electron-settings/node_modules/fs-extra/docs (96 KiB) * node_modules/electron-settings/node_modules/fs-extra/CHANGELOG.md (56 KiB) * node_modules/user-media-screenshot/.idea/ (44 KiB) All of the stuff I listed above is quite redundant for the users who just want to run the app. If you remove them, the 1.8 MiB become 764 KiB for the entire app and I'm pretty sure that minifiers, bundlers etc. could make it even smaller. The runtime could be provided by the OS. I think it's definitely possible to create apps < 500 KiB with web technology, it's just the deployment patterns that turn this into a major download of 122 MiB. As for the RAM usage, idk about that. I guess if the runtime is provided by the OS, it would be the same electron binary so the OS could share that one at least.

solarkraft 8y ago
Thanks for the wonderfully detailed breakdown. I wish every electron app could get this. I don't hate web technology, I just hate electron's distribution model. There are so many frameworks to get around this.
Polarity 8y ago
What´s the problem with this? I have enough space on my drive. Sure the app is bigger but it´s platform independent and works flawlessly. Native apps crash often, use big os dependent frameworks (you have to install sometimes) and only to have a smaller bundle? I don't get it.
- ekianjo 8y ago
  > What´s the problem with this? The problem? When you start to have 5-6 apps running with Electron in the backend and start to take 10% of your CPU time and 2 Gigs of RAM, you will start to feel how it impacts your working environment, battery life and all.
  - johnisgood 8y ago
    Just download more RAM! On a serious note: I never understood why people tell me to buy better hardware to compensate for the shitty performance of their software. No, fix your software!
    - AnIdiotOnTheNet 8y ago
      Because there are few people on earth more entitled than the modern web developer?
- sergiotapia 8y ago
  Nah dude this line of thinking got us here. We need to reach back to what the OG's in computing thought about. Small size, fast performance. Limit ourselves. I read about this dude who purposely writes software on a shitheap laptop just so that "if it's fast here, it's fast on modern mobile phones." Even my app written in Elixir and uses 160MB of RAM after letting it run for a week; I've been thinking: "Maybe I could bring it lower to what nzbget uses (around 59MB)". I've been exploring Nim for that. We need a return to small-footprint as a feature.
  - arendtio 8y ago
    Hehe, kinda funny when an application comes with more security vulnerabilities than it has lines of code for its own logic ;-) EDIT: edited to make it less ambiguous
    - monetus 8y ago
      Sorry, is this a comment on elixer or Nim?
lioeters 8y ago
Nice breakdown of wasted resources.. It's frustrated me for a long time how people are carelessly bundling unused code, which is unfortunately common in JavaScript-land. Including only the bundled/minified app is possible, leaving no node_modules folder at all - or, at least, just the native binaries needed. As for bundling the whole Electron runtime on every app: technically it's possible to have a shared runtime - as this 3-year old issue shows, many people have attempted various approaches: https://github.com/electron/electron/issues/673 https://github.com/electron/electron/issues/673 However, sadly no one has stepped up to come up with a general solution. While there are disadvantages and some reasonable arguments for bundling the exact version of the runtime required by an app, it seems efficent use of resources isn't enough of a priority..
- ehnto 8y ago
  I'm not sure what it is about the node development environment but you are right. I haven't seen such wildly complicated dependency trees in any other language. Literally hundreds of modules can come together to make even simple applications. Is there an idiom or ethos in node land that aims for tiny re-usable packages? I am not criticising if there is, just genuinely curious. I have been writing JS applications for years and it's only since node and npm hit the scene that this has occured.
  - Lowkeyloki 8y ago
    It might be the Unix philosophy taken to its logical extreme. Everything should do one thing and do it well. So now we have libraries that are literally a single function.
  - shittyadmin 8y ago
    Here's the thing though: You could build this in pure Node and call Windows APIs, Qt, etc and it'd be much, much smaller. But everyone just goes ahead and pulls in Chrome. It's shameful, and the worst part is that I get it - at this point I'm suggesting we go to Electron for a new application at work because it seems like the best maintained UI frameworks with readily available 3rd party components are all web based.

by est31 8y ago

solarkraft 8y ago

Thanks for the wonderfully detailed breakdown. I wish every electron app could get this. I don't hate web technology, I just hate electron's distribution model. There are so many frameworks to get around this.

Polarity 8y ago

What´s the problem with this? I have enough space on my drive. Sure the app is bigger but it´s platform independent and works flawlessly. Native apps crash often, use big os dependent frameworks (you have to install sometimes) and only to have a smaller bundle? I don't get it.

ekianjo 8y ago
> What´s the problem with this? The problem? When you start to have 5-6 apps running with Electron in the backend and start to take 10% of your CPU time and 2 Gigs of RAM, you will start to feel how it impacts your working environment, battery life and all.
- johnisgood 8y ago
  Just download more RAM! On a serious note: I never understood why people tell me to buy better hardware to compensate for the shitty performance of their software. No, fix your software!
  - AnIdiotOnTheNet 8y ago
    Because there are few people on earth more entitled than the modern web developer?
sergiotapia 8y ago
Nah dude this line of thinking got us here. We need to reach back to what the OG's in computing thought about. Small size, fast performance. Limit ourselves. I read about this dude who purposely writes software on a shitheap laptop just so that "if it's fast here, it's fast on modern mobile phones." Even my app written in Elixir and uses 160MB of RAM after letting it run for a week; I've been thinking: "Maybe I could bring it lower to what nzbget uses (around 59MB)". I've been exploring Nim for that. We need a return to small-footprint as a feature.
- arendtio 8y ago
  Hehe, kinda funny when an application comes with more security vulnerabilities than it has lines of code for its own logic ;-) EDIT: edited to make it less ambiguous
  - monetus 8y ago
    Sorry, is this a comment on elixer or Nim?

lioeters 8y ago

Nice breakdown of wasted resources.. It's frustrated me for a long time how people are carelessly bundling unused code, which is unfortunately common in JavaScript-land. Including only the bundled/minified app is possible, leaving no node_modules folder at all - or, at least, just the native binaries needed. As for bundling the whole Electron runtime on every app: technically it's possible to have a shared runtime - as this 3-year old issue shows, many people have attempted various approaches: https://github.com/electron/electron/issues/673 https://github.com/electron/electron/issues/673 However, sadly no one has stepped up to come up with a general solution. While there are disadvantages and some reasonable arguments for bundling the exact version of the runtime required by an app, it seems efficent use of resources isn't enough of a priority..

ehnto 8y ago
I'm not sure what it is about the node development environment but you are right. I haven't seen such wildly complicated dependency trees in any other language. Literally hundreds of modules can come together to make even simple applications. Is there an idiom or ethos in node land that aims for tiny re-usable packages? I am not criticising if there is, just genuinely curious. I have been writing JS applications for years and it's only since node and npm hit the scene that this has occured.
- Lowkeyloki 8y ago
  It might be the Unix philosophy taken to its logical extreme. Everything should do one thing and do it well. So now we have libraries that are literally a single function.
- shittyadmin 8y ago
  Here's the thing though: You could build this in pure Node and call Windows APIs, Qt, etc and it'd be much, much smaller. But everyone just goes ahead and pulls in Chrome. It's shameful, and the worst part is that I get it - at this point I'm suggesting we go to Electron for a new application at work because it seems like the best maintained UI frameworks with readily available 3rd party components are all web based.