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)
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.
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
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..
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.
If anyone is put off by it being an Electron app and are running Windows, here's an AHK[0] script to get the hex code of the pixel color under your cursor and copy it to your clipboard:
---
#h::
MouseGetPos, MouseX, MouseY
PixelGetColor, color, %MouseX%, %MouseY%
StringLower, color, color
clipboard := SubStr(color, 3)
---
It's bound to Win+h (hex color) by default.
It's not fancy, but it works. You just run it in the background and hit the hot key to copy the color whenever you want to. There is no UI.
AutoHotkey is amazing. It's a little gem of a Windows app. I only wish I discovered it earlier, when I was still using Windows as my main OS.
AHK can be used to trivially fix many usability warts you have with random software, and is powerful enough that someone implemented a clone of dwm tiling window manager in it (bug.n, [0], I used it for more than a year and can attest it works very well).
AutoHotKey is great and the kind of thing that should just be built in to desktop OSs. Why shouldn't I just be able to assign any key combo to anything, contextually? Why do we have to rely on applications supporting hotkeys at all?
That isn't the problem. The problem is the community, and the effect Electron is having on it.
Cross platform application development is considered a "solved problem" with Electron, and it's developed a cult that leads people to disparage native applications and native development as inferior in all cases, as if Electron were already the best possible solution rather than a hack around webdev that blew up because of the SV hype machine.
Because of this commoditization around a single language and a single framework (mostly by corporate interests, mind you,) curiosity and innovation are halted in favor of developer time efficiency and resume visibility. No one is even going to bother trying to create the next cross-platform application solution after Electron, because they would only be able to do so in Electron.
> A dev missed some feature of their usual OS and so wrote a cross platform version open source in their spare time.
So what matters is the "why" and the "what", and we can just forget about the "how"? Engineering is all about the how we do things, and HN tends to have more engineers than your typical online community. What's wrong with that?
Also, xmag, you already have it installed if you use the X Window System. It's 41kb, extremely lightweight (always starts instantly) and also magnifies a screen portion which is helpful for picking colours.
I had become so used to just grabbing color values from any old pixel on the screen..., but on Windows the best way I came up with was to take a screenshot, wait for Photoshop to open, then get the color value through the PS eyedropper tool. That took probably 30 seconds to get a single color, since Adobe software is somehow still dog slow on brand new hardware.
You can do the same thing in MS Paint and save yourself 15 seconds.
Yes, this 450 line program could have been written in whatever native language you want with probably 3x the code and time spent, but why would you? Developer time has been more expensive than hardware for a decade now.
Everyone here loves to virtue signal about how horrible programs that take 0.01% of the space of a normal SSD and 1% of the RAM are, but the fact is that it does not matter at all, and you wouldn't even have noticed if you hadn't intentionally looked at the size of it.
I know some people think Electron is cancer[1], but it is the fastest way to write cross-platform applications. I've been trying to learn to make apps for macOS, and it feels like even Apple doesn't want me write apps for the Mac.
I'd like for people to drop the whole 'x is cancer' thing since aside from the actual fuckery of cancer most things aren't that bad. A little too flippant imo :)
Is it actually faster to develop in Electron than with QT and C++?
It has been over a decade, but I remember it being both straight-forward and pleasant to support Linux, Windows, and MacOS. I vaguely recall supporting Solaris too.
> it is the fastest way to write cross-platform applications.
I disagree. Maybe that's true if you're a webdev unwilling to learn anything else, but Lazarus is the fastest way I've found to write cross-platform GUI software, and as a bonus it compiles to native code in a single executable.
[+] [-] est31|7 years ago|reply
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.
[+] [-] lioeters|7 years ago|reply
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
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..
[+] [-] solarkraft|7 years ago|reply
I don't hate web technology, I just hate electron's distribution model. There are so many frameworks to get around this.
[+] [-] Polarity|7 years ago|reply
[+] [-] kgraves|7 years ago|reply
Color Picker for Windows (500KB) (1.6MB unzipped): http://instant-eyedropper.com
Significantly smaller than the Electron app and works across Windows XP to 10.
[+] [-] altcognito|7 years ago|reply
http://www.mirekw.com/winfreeware/mwsnap.html
[+] [-] allwynpfr|7 years ago|reply
[+] [-] fxfan|7 years ago|reply
[+] [-] nickjj|7 years ago|reply
---
#h::
MouseGetPos, MouseX, MouseY
PixelGetColor, color, %MouseX%, %MouseY%
StringLower, color, color
clipboard := SubStr(color, 3)
---
It's bound to Win+h (hex color) by default.
It's not fancy, but it works. You just run it in the background and hit the hot key to copy the color whenever you want to. There is no UI.
What's neat about it is the entire source code fits in a tweet: https://twitter.com/nickjanetakis/status/1108825825116332032
And it uses 0.6MB of RAM when running.
[0]: https://www.autohotkey.com/
[+] [-] TeMPOraL|7 years ago|reply
AHK can be used to trivially fix many usability warts you have with random software, and is powerful enough that someone implemented a clone of dwm tiling window manager in it (bug.n, [0], I used it for more than a year and can attest it works very well).
--
[0] - https://github.com/fuhsjr00/bug.n
[+] [-] AnIdiotOnTheNet|7 years ago|reply
[+] [-] fxfan|7 years ago|reply
Excuse me, this is one of the tiniest and most useful things i've seen in my life as a budding designer.
[+] [-] misnome|7 years ago|reply
Who cares that they used the “wrong” language or framework, or could have solved it another way or “who need this functionality anyway”.
Isn’t this supposed to be what the dev spirit is about?
[+] [-] krapp|7 years ago|reply
Cross platform application development is considered a "solved problem" with Electron, and it's developed a cult that leads people to disparage native applications and native development as inferior in all cases, as if Electron were already the best possible solution rather than a hack around webdev that blew up because of the SV hype machine.
Because of this commoditization around a single language and a single framework (mostly by corporate interests, mind you,) curiosity and innovation are halted in favor of developer time efficiency and resume visibility. No one is even going to bother trying to create the next cross-platform application solution after Electron, because they would only be able to do so in Electron.
It's getting kind of ridiculous.
[+] [-] ekianjo|7 years ago|reply
So what matters is the "why" and the "what", and we can just forget about the "how"? Engineering is all about the how we do things, and HN tends to have more engineers than your typical online community. What's wrong with that?
[+] [-] theNextEpisode|7 years ago|reply
Someone spent their free time to give the world something free, shame on them it's not perfect.
[+] [-] number6|7 years ago|reply
[deleted]
[+] [-] Drup|7 years ago|reply
And for size fetishists: it weights 42KB.
[+] [-] spookylukey|7 years ago|reply
[+] [-] detaro|7 years ago|reply
[+] [-] Hendrikto|7 years ago|reply
[+] [-] booleandilemma|7 years ago|reply
You can do the same thing in MS Paint and save yourself 15 seconds.
[+] [-] Scrantonicity|7 years ago|reply
[+] [-] happyweasel|7 years ago|reply
[+] [-] stephc_int13|7 years ago|reply
I'm absolutely sure it is possible to write the same cross-platform app for less than 500KBytes and no dependencies.
[+] [-] drivingmenuts|7 years ago|reply
This is an answer without a real problem, for Mac users anyway.
[+] [-] phiresky|7 years ago|reply
Everyone here loves to virtue signal about how horrible programs that take 0.01% of the space of a normal SSD and 1% of the RAM are, but the fact is that it does not matter at all, and you wouldn't even have noticed if you hadn't intentionally looked at the size of it.
[+] [-] pooya72|7 years ago|reply
[1]:https://medium.com/commitlog/electron-is-cancer-b066108e6c32
[+] [-] mizaru|7 years ago|reply
[+] [-] jacobedawson|7 years ago|reply
[+] [-] nieksand|7 years ago|reply
It has been over a decade, but I remember it being both straight-forward and pleasant to support Linux, Windows, and MacOS. I vaguely recall supporting Solaris too.
[+] [-] Waterluvian|7 years ago|reply
It isn't replacing app dev. It's adding more app developers.
[+] [-] happyweasel|7 years ago|reply
[+] [-] AnIdiotOnTheNet|7 years ago|reply
I disagree. Maybe that's true if you're a webdev unwilling to learn anything else, but Lazarus is the fastest way I've found to write cross-platform GUI software, and as a bonus it compiles to native code in a single executable.
[+] [-] arendtio|7 years ago|reply
https://kde.org/announcements/plasma-5.5/plasma-5.5-colorpic...
https://userbase.kde.org/Plasma/ColorPicker
[+] [-] _noise_|7 years ago|reply
On Linux it seems confused with a muti-monitor setup, the orbit button does nothing.
On Windows, in a VM, the orbit button opens a web browser to https://www.tonymccoy.me/orbit/#ffffff and gets a 404 Not Found
[+] [-] _noise_|7 years ago|reply
https://doc.qt.io/qt-5/qcolordialog.html
KDE's KColorChooser is simply a wrapper around this and is less than 100 lines of code, mostly setting up the about box.
https://kde.org/applications/graphics/kcolorchooser/
This could have trivially been made into a cross-platform color chooser that uses significantly less resources.
On my Linux box Fucking Color Chooser spawns 4 fucking processes uses 128 MB of RAM and 4% CPU.
KColorChooser uses 15 MB in one process and near zero CPU.
Please stop making everything a web application.
[+] [-] Piisamirotta|7 years ago|reply
[+] [-] mehrdadn|7 years ago|reply
[+] [-] kakarot|7 years ago|reply
A color picker is a tantamount example of an application that does not belong on the Electron platform.
[+] [-] lousken|7 years ago|reply
[+] [-] tenryuu|7 years ago|reply
but I also overrode the tooltip text on the screenshot cursor to display the RGB hex, as a ctrl+c will copy whatever is in this box
[+] [-] boot13|7 years ago|reply
[+] [-] pooya72|7 years ago|reply
[+] [-] aeonflux|7 years ago|reply
[+] [-] gokhan|7 years ago|reply
http://colorcop.net/
http://www.iconico.com/download.aspx?app=ColorPic&type=free
http://www.youngsmarts.com/download.htm
... and so on.
[+] [-] astura|7 years ago|reply
Also, opening up Photoshop for the color picker? Paint opens faster than I can blink and has a color picker.
[1] https://electronjs.org/apps/colorpicker
[+] [-] signal11|7 years ago|reply
[1] http://www.nattyware.com/pixie.php
[+] [-] montroser|7 years ago|reply
[+] [-] VitoVan|7 years ago|reply